speculative locking

An interesting talk from the folks at Azul systems who talked through optimizations in parallel processing and locking scenarios ( mostly using java but I guess just as easily applicable elsewhere). Taking a simple example of a hashtable that had data contention between threads, they demonstrated the performance benefits they could get by taking advantage of data collision detection in hardware as well as optmization sin their JVM that allows them to (as I understood it) do the equivalent of pessimistic locking with rollbacks for data collisions between threads. so they ultimately end up locking a lot less as a lot of potentially 'synchronized' data structures don't actually result in data collisions in practice - just as a large relational database table doesn't need to be locked if only a few rows need to be updated. That is effectively what synchronized blocks on data structures actaully end up doing.
They have an example of how this works at http://www.jaoo.dk/articles/syncadv.jsp including results.
Very interesting though clearly currently this needs specialised hardware and the azul JVM to take advantage of it. I wonder if we will see similar advancements in .NET. There alredy are , for example, a hashtable and a synchronized hashtable implementation within .NET but looking at the sample implementation in Rotor, it doesn't look like they are doing anything particularly non trivial in implementing this - though of course the production implementation could well be different. Their assesment was that widespread availability of low end hardware supporting this was at least 2 years away. All in all an interesting to see some fairly hard core engineering in action at a software conference.