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!
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