[infinispan-dev] JGroupsDistSync and ISPN-83

[Dan Berindei]

On Wed, May 11, 2011 at 11:25 AM, Vladimir Blagojevic
<vblagoje at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>