Re: [infinispan-dev] JGroupsDistSync and ISPN-83
Manik (and others),
Can you run this code on your laptops and let me know what happened!
Vladimir
public static void main (String [] arg) throws Exception {
final JGroupsDistSync ds = new JGroupsDistSync();
ds.acquireProcessingLock(false, 3, TimeUnit.SECONDS);
System.out.println("Got read lock");
Thread t = new Thread(){
public void run (){
try {
ds.acquireProcessingLock(true, 3, TimeUnit.SECONDS);
System.out.println("Got write lock");
} catch (TimeoutException e) {
System.out.println(e);
}
}
};
t.start();
}
On 11-05-13 4:53 PM, Manik Surtani wrote:
Yes, please have a look. If we are relying on lock upgrades then
that's really bad. I am aware of the inability to (safely) upgrade a RWL and I'm
pretty sure we don't try, but the dist sync codebase has evolved a lot and could do
with some careful analysis.
Sent from my mobile phone
On 12 May 2011, at 09:24, Vladimir Blagojevic<vblagoje(a)redhat.com> wrote:
> On 11-05-11 11:23 AM, Dan Berindei wrote:
>> 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?
>>
> Not sure and it sounds counter intuitive that a thread holding a read
> lock from cluster invocation is doing state generation for state
> transfer as well. But this lock business is fishy and I plan to get to
> the bottom of it...
>
> _______________________________________________
> 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