[infinispan-dev] Semaphore vs Lock

[Sanne Grinovero]

As it already came up during other design discussions, we should make
a very clear split between a logical lock (something owned by a
transaction) and an internal entry lock.
A logical lock needs to be addressable uniquely, striping or
semaphores are not a viable option as these are
 - long lived (definitely more than 1 RPC)
 - defeats any attempt from end users / intermediate patterns to avoid deadlocks
 - likely a small ration of overall keys, so should not be too
expensive to store

Internal entry locks are very short lived (never live across multiple
RPCs) and are essentially matching what we have as segments locks in
the CHM (which is already striping == concurrency level), just that
the CHM model isn't fitting well our needs: we need excplicit control
of these, for example for when a value is being moved from the
DataContainer to a CacheLoader.

In conclusion, I'd not spend time arguing on small improvements of the
existing design - at least it's serving well for now.
Sanne



On 13 March 2012 12:53, Galder Zamarreño <galder at redhat.com> wrote:
>
> 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).
>
> True, but reentrant is only needed for non-transactional scenarios. For pessimistric transactions, we have ownable locks where they're owned by transactions.
>
>>
>> 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
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev