| 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
org.apache.tapestry.internal.annotations.Concurrent aspect (which used a
java.util.concurrent.locks.ReentrantReadWriteLock under the covers)
is about 4x as expensive as just using the 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
ConcurrentBarrier utility.
| 