[infinispan-dev] Semaphore vs Lock

[Galder Zamarreño]

On Mar 8, 2012, at 12:42 PM, Dan Berindei wrote:

> On Wed, Mar 7, 2012 at 2:39 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
>> On 7 March 2012 12:05, Galder Zamarreño <galder.zamarreno at redhat.com> 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.

^ - Hmmm, interesting. This might be something we can control inside? IOW, change the default lock striping setting depending on the locking mode? Definitely worth testing it out.

> 
>> 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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache