Re: [infinispan-dev] Semaphore vs Lock
On Tue, Mar 13, 2012 at 3:57 PM, Sanne Grinovero <sanne(a)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