[concurrency-interest] Performance of ReentrantReadWriteLock
martinrb at google.com
Sun Nov 22 22:53:51 EST 2009
RRWL has a bunch of overhead related to
keeping track of read hold state, that could
be removed to get something faster but less
debuggable. I've wanted to do something
in this area.
I'd be interested in perf results when you have
lots of writes. What's the overhead of RRWL
over RL when only the writelock is ever acquired?
Do you actually have enough processors to keep
your 5 threads busy?
writing micro-benchmarks is known to be hard,
and for concurrency primitives especially so.
Perhaps you could share your micro-benchmark?
RRWL has seen some implementation improvements
post-JDK6. Try the JDK7, JDK6, JDK5 implementations
with a jdk7 hotspot, perhaps.
On Wed, Nov 18, 2009 at 20:46, Norman Elton <normelton at gmail.com> wrote:
> I've done some very basic testing of a ReentrantReadWriteLock vs.
> synchronized. I fired up five threads, each of which is accessing a
> shared Map<Integer,Integer>. At first, I did 99% read operations, then
> 100% read operations. Initial testing, with no locking or
> synchronization, proved about 8M operations per second per thread.
> Then I tested synchronizing the get() and put() methods. Performance
> dropped to about 700K operations per second. Synchronization obviously
> has a large overhead.
> Strange thing is, the ReentrantReadWriteLock performed just about as
> well. Even in a 100% read environment, where I would think threads
> would never have to block for one another.
> Am I missing something here? Shouldn't I be seeing significantly
> better numbers for the ReentrantReadWriteLock? Presumably, it's
> allowing multiple threads to hit the hash at the same time. I would
> expect numbers somewhere between the synchronizing hash and the
> completely untouched HashMap.
> Thoughts? Thanks!
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
More information about the Concurrency-interest