[concurrency-interest] Performance of ReentrantReadWriteLock
Brian S O'Neill
bronee at gmail.com
Thu Nov 19 00:09:17 EST 2009
Lock implementations have a quick check step to see if there's no
contention. Since you have only one thread in both tests, there is no
contention at all. The "synchronized" monitor and the read write lock
both need to do the same work for this quick check. The read write lock
is not designed to be /necessarily/ faster at lock acquisition, but it
is designed to allow multiple reads without the lock being released. For
applications which hold the lock only briefly, use of "synchronized"
will do fine.
Norman Elton 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