In programming with transactions, you just declare what you want to be atomic. In this example, the programmer declares that they want to maintain atomicity over this region of code. The transactional memory system will then detect if there are conflicts between the atomic regions and will ensure that the correct thing happens. How the atomicity is implemented is separate from this purely declarative step.

I think this slide really shows the appeal of transactions. You, the programmer, tells the system what needs to be done atomically and the system does it for you. By not having to use locks etc, e.g. in fine-grained lock, the programmer can make less errors and focus more on how the program should behavior.

Are there any widespread use of transactional memory via atomic block in modern programming languages (Java, C++, etc.)? The closest thing I found in Java to transactional memory was synchronized method, but it guarantees single execution (non-interleaving) of the block, instead of atomic memory access.

If I had to guess, synchronized block probably has slightly worse performance because it doesn't allow any interleaving at all, whereas transactional memory still allows interleaving as long as the memory access are independent.

Besides API usability, transactional memory abstractions allows concurrent transactions as long as they don't have commit conflict; whereas locks allow only one thread at a time, even if threads visit a critical section in a non-conflict way.

@sirah the synchronized feature in Java is similar to the code example on the left - locking down a critical section of code. So you are correct that there is no interleaving allowed even if the memory accesses are independent.

A tricky thing about the atomic declaration abstraction here is that the programmer still needs to know what regions of the code to make atomic, and which ones not to, and so the compiler gets some permission to do optimization here but the risk of correctness still falls heavily on the programmer