He's not correct. In fact the post is full of goobledock he only partly understands.
>It creates a “memory barrier” CPU are usually free to >shuffle around the stream of instructions that flow through >them and it is done all the time as the CPU constantly >optimizes the instruction stream to keep all its resources >busy. A lock creates a barrier and the CPU is not allowed >to move stuff past this barrier. Branch prediction across >memory barriers is also something I don’t think is doable.
He's confusing instruction retiring with memory ordering. On modern fast CPUs they are only vaguely related.
>Cache coherency. The address line that stores the lock gets >invalidated and the content in that cache gets thrown out.
That's not how a modern CPU with MESI protocol operate. As long as the cache line stays EXCLUSIVE to that core it does not get invalidated.
Transactional memory is useful for using a coarse lock to access a wide set of data most of which is not accessed concurrently. You are having the hardware doing the work of lock elision/splitting for you.
This saves you from having the unnecessary mutual exclusion of a regular coarse lock. Or alternatively it saves you from the unnatural acts necessary to get lock splitting or eliminate shared state.
For write mostly counters where performance is an issue you want to have a thread local counters or striped counters.
See http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/src/jsr1... for an example of how that is done. This counter demonstrates lock splitting as well as an attempt at mechanical sympathy by trying to pick the right stripe based on CAS failures.