Cliff Click Jr: Experiences with Hardware Transactional Memory for Java
blogs.azulsystems.com
blogs.azulsystems.com
Transactional memory sounds appealing to programmers who've worked hard on making lock-based systems scale because the grass is always greener. Locks sound easy, too, until you try to build a huge system with them. It sounds like Azul has built the first industrial scale TM implementation, and done it with some of the best and brightest, but has not found the going significantly easier or faster than with traditional methods.
http://en.wikipedia.org/wiki/Software_transactional_memory
So, as a Java guy, here's what I take this stuff to mean:
Synchronization blocks are implicitly pessimistic locking. Even if the probability of a collision is close to zero, we still make threads line up for admittance to critical sections.
Transactional memory allows us to employ optimistic concurrency. If any other thread modified stuff that is encompassed in your transaction, you get an exception.
This sounds much like the scheme employed by Hibernate to do optimistic locking for DB stuff. Am I thinking about this correctly?