On 13 Mar 2012, at 15:17, Dan Berindei wrote: > 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. I'm not sure we even need reentrant locks for transactions: ATM the tx helds a collection with all the locks it already acquired and reentrancy can be avoided by just not trying re-lock again a key on which we already have a lock. This would simplify the lock impl considerably.
_______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
