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
