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). I think a bigger problem is our reliance on AbstractQueuedSynchronizer (used by Semaphore as well, btw), which forces us to use a thread-local internally. >> 2. Could lock striping become lock pooling with a simple object pool based >> on a Semaphore? In theory, we'd avoid the current issue with lock striping >> where two diff locks hash to the same segment and we have deadlocks. We >> could use, as the current lock striping logic does, the concurrency level to >> decide the number of semaphore permits. > Pooling is definitely not free, you'll have extra contention on the pool. But it would be interesting to see how it compares to normal locking, especially with multi-socket machines. BTW, the current striping logic works fine with optimistic transactions, because optimistic transactions always acquire the striped locks in the same order. > Concurrency level -> number of permits ? > I don't get that, the way I'm reading it, it sounds like the more > efficient version would be to remove the semaphore ;) > Actually Galder does mention binary semaphores above, so the number of permits must be fixed at 1. He probably meant concurrency level == number of semaphores in the pool. _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
