Counters aren't a good use case for transactional memory because the contention is over very specific sets of memory. Transactional memory is useful for using

Counters aren't a good use case for transactional memory because the contention is over very specific sets of memory. 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/jsr166e/Striped64.java 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.