[infinispan-dev] Semaphore vs Lock

[Manik Surtani]

On 8 Mar 2012, at 05:42, 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.

Yes.  I did try and not implement Lock, and pass in the lock owner directly, but a lot of AQS is private or package-protected and as such can only access an "owner" via a thread local.  The other, other way is to completely re-implement AQS, but that (a) is non-trivial and error-prone and (b) would need to access JDK unsafe constructs which will hamper portability.

> 
>>> 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.

Well, lock striping is effectively an Object pool.  Except that the objects being pooled are Locks.  What am I missing here?

> 
>> 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.

Which is the same as concurrency level setting the number of Locks in the pool, as per current design?  :)

Cheers
Manik

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org