Guys, after investigating https://issues.jboss.org/browse/ISPN-2381 and 
https://github.com/infinispan/infinispan/pull/1382, I've discovered a pretty 
nasty race condition in our per-entry lock containers (whether 
OwnableReentrantLocks or JDK locks for non-transactional caches).

The problem is that we maintain a lock map, and any given request can acquire a 
lock, if a lock doesn't exist for a given key, create the lock and acquire it, 
and when done, release the lock and remove it from the lock map.  There's lots 
of room for races to occur.  The current impl uses a ConcurrentMap, where 
concurrent operations on the map are used to make sure locks are not 
overwritten.  But still, since the process of creating, acquiring and adding 
the lock to the lock map needs to be atomic, and not just atomic but also safe 
with regards to competing threads (say, an old owner) releasing the lock and 
removing it from the map (also atomic), I think a concurrent map isn't good 
enough anymore.

The sledgehammer approach is to synchronise on this map for these two 
operations, but that causes all sorts of suckage.  Ideally, I'd just hold on to 
the segment lock for the duration of these operations, but these aren't 
exposed.  Extending CHM to expose methods like acquireLockAndGet() and 
unlockAndRemove() would work perfectly, but again a lot of CHM internals are 
private or package protected.

So my options are: completely re-implement a CHM-like structure, like we've 
done for BCHM, or perhaps think of a new, specialised structure to contain 
locks.  In terms of contract, I just need a fast way to look up a value under 
given a key, efficient put and remove as well.  It should be thread-safe 
(naturally), and allow for an atomic operation (like "get, do work, put").

Any interesting new data structures on peoples' minds?

Cheers
Manik
--
Manik Surtani
[email protected]
twitter.com/maniksurtani

Platform Architect, JBoss Data Grid
http://red.ht/data-grid

_______________________________________________
infinispan-dev mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/infinispan-dev

Reply via email to