[infinispan-dev] JGroupsDistSync and ISPN-83

Vladimir Blagojevic vblagoje at redhat.com
Wed May 11 04:25:26 EDT 2011


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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev



More information about the infinispan-dev mailing list