Re: [infinispan-dev] JGroupsDistSync and ISPN-83
On Wed, May 11, 2011 at 11:25 AM, Vladimir Blagojevic
<vblagoje(a)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-ho...
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev