On Tue, Mar 13, 2012 at 2:53 PM, Galder Zamarreño <[email protected]> wrote: > > On Mar 8, 2012, at 12:42 PM, Dan Berindei wrote: > >> On Wed, Mar 7, 2012 at 2:39 PM, Sanne Grinovero <[email protected]> wrote: >>> On 7 March 2012 12:05, Galder Zamarreño <[email protected]> wrote: >>>> Hi, >>>> >>>> I was reading up about Java's Semaphores >>>> (http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Semaphore.html) >>>> and a couple of ideas came to my mind: >>>> >>>> 1. Wouldn't it make sense to use binary semaphores instead of locks in >>>> Infinispan? We're already having to override ReentrantLock in order to >>>> have locks owned by Transactions rather than threads. Initially I thought >>>> it might make easier for deadlock detection, but not so sure right now cos >>>> we're already changing things to avoid thread ownership of locks. >>>> >> >> We don't support most of the Lock operations, so I think it would be >> fair to remove 'implements Lock' from the OwnableReentrantLock >> declaration. But we can't remove the reentrant part, as we acquire the >> lock when we put a value in L1 in DistributionInterceptor - after we >> have already acquired the lock once in LockInterceptor (that's before >> we even consider a pessimistic transaction doing multiple puts on the >> same key). > > True, but reentrant is only needed for non-transactional scenarios. For > pessimistric transactions, we have ownable locks where they're owned by > transactions. >
I meant reentrant in a more general sense - OwnableReentrantLock is reentrant because it allows the same transaction to lock the same key twice, even if it happens on different threads. In the pessimistic case you could even have a transaction doing lock + read + write + unlock + commit and I believe the key should stay locked until the commit (because the update command implicitly acquired the lock a second time). I'm not sure about optimistic transactions - we might get away without reentrant locks there. But I think there's no point adding a non-reentrant lock for optimistic transactions if we still need reentrant locks in the other cases. Cheers Dan _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
