Tests single-thread synchronization overhead using different techniques. Note that we're fudging things a bit by getting a read lock for a write operation .... it's just that I'm more concerned about read locks (which will be very common) than about write locks (very rare). Another concern is that hotspot is going to mess up our synchronization when it see we're not really doing anything multi-threaded.
The results show that using the {@link org.apache.tapestry5.internal.annotations.Concurrent} aspect (which used a{@link java.util.concurrent.locks.ReentrantReadWriteLock} under the covers) is about 4x as expensive as just usingthe synchronized keyword. There are some anomolous results ... for example, ReadWriteLockRunner is consistently slower than ReadWriteLockAspectRunner (one would expect it to be the other way around ... must be something about how AspectJ weaves the code ... and it's use of static methods in many cases).
Well, the Concurrent aspect is gone, replaced with the {@link ConcurrentBarrier} utility.