On Wed, May 11, 2011 at 11:25 AM, Vladimir Blagojevic <vblag...@redhat.com> wrote: > The more I research ReentrantReadWriteLock the more shocked I am. Not > only that a thread wanting to acquire write lock first has to release > read lock, but we can block forever even if we release the read lock if > we have acquired that read lock reentrantly. Each call to unlock just > reduces the hold count, and the lock is only actually released when the > hold count hits zero. Surreal! >
If ReentrantReadWriteLock would allow upgrades then you would get a deadlock when two threads both hold the read lock and try to upgrade to a write lock at the same time. There's always a trade-off... I'm not familiar with the code, but are you sure the read lock is being held by the same thread that is trying to acquire the write lock? Dan > People have already debated this issue: > http://stackoverflow.com/questions/464784/java-reentrantreadwritelocks-how-to-safely-acquire-write-lock > > In conlusion we have to seriously revisit all our uses of > ReentrantReadWriteLock! > > Vladimir > > > On 11-05-10 11:31 AM, Vladimir Blagojevic wrote: >> Hi, >> >> Would you please confirm my understanding and reading of javadoc for >> ReentrantReadWriteLock under section for "lock downgrading". It says: >> "Reentrancy also allows downgrading from the write lock to a read lock, >> by acquiring the write lock, then the read lock and then releasing the >> write lock. However, upgrading from a read lock to the write lock is not >> possible." ReentrantReadWriteLock javadoc code example with class >> CacheData also shows how a thread owning a read lock first has to >> release it in order to obtain a write lock! So a thread owning a read >> lock first has to release a read lock in order to obtain a write lock? >> >> This is very symptomatic in logs of ISPN-83 such as this one >> https://issues.jboss.org/secure/attachment/12341409/server1.log >> >> Recall how FLUSH stops all invocations on cluster and therefore all read >> lock acquisitions in JGroupsDistSync ultimately enabling smooth write >> lock acquisitions for state transfer and what not. In conclusion this >> leads me wondering if the culprit of all this FLUSH mess is rooted in >> read/write lock semantics from above? >> >> Regards, >> Vladimir >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev > _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev