In the tests above, it would also be interesting to measure overall throughput, and to look at how this changes with concurrency (number of accessing threads). Also, unless I missed it, you don’t mention what platform you’re running the tests on. The relative speed of processor instructions (and hence of the different locking mechanisms) almost certainly varies.

In case you’re interested, I’ve actually published some related test results looking e.g. at the performance of ConcurrentHashMap,
some timings of comparing locking mechanisms for concurrent array access,
plus some other information on volatile and synchronization that readers may find interesting.

Java Volatile is Powerful « Pit Falls in Java Development…

I think its good to inform people of the tricks, but best to advise them to use the library implementations instead. Otherwise, you’ll find more people implement counters using volatile and other such incorrect abuses because they only half understood your post.

I havent used term piggybacking explicitly but i have tried to explain the same concept. As when volatile write will happen it will execute a memory flush and all writes on other variables before volatile write will also get flushed. And due to ordering guarantees on volatile these other variable (non-volatile) writes wont jump over this volatile write. So thats nothing but piggybacking synchronization as explained by Brian in JCIP.