[infinispan-dev] Semaphore vs Lock

[Dan Berindei]

On Tue, Mar 13, 2012 at 3:57 PM, Sanne Grinovero <sanne at infinispan.org> wrote:
> 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
>

While the locks may not be very expensive to store, they are complex
objects and creating them over and over again can get quite expensive.
For instance, if 10 tx threads wait for a key lock, the lock will keep
a queue with the 10 waiting threads. When the tx that owned the key
unlocks it, the key is removed, and all 10 threads wake up and try to
create a new lock. Only one of them succeeds, the others add
themselves to the queue once again.

This may not be a problem in our perf tests because we update keys
randomly using a uniform distribution, but regular application will
almost certainly have a non-uniform distribution and a few keys will
be highly contended compared to the rest. This makes me think that
LIRS could be a nice fit for a LockContainer implementation.


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

Sanne, I'm not sure about surfacing the DataContainer's locking, as
ConcurrentHashMapV8 doesn't have segment locks any more and we'll
probably want to move our BCHM towards that model as well in the
future.

For the situation you mentioned I would prefer making the CacheLoader
a participant in cache transactions and holding the logical lock while
passivating the entry.


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

The discussion may be a bit premature, but it's a nice change from
thinking about NBST ;-)


Cheers
Dan