Re: [infinispan-dev] Per-entry lock container
On Oct 16, 2012, at 10:33 AM, Sanne Grinovero <sanne(a)infinispan.org> wrote:
> 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.
are you sure that adding + creating + acquiring needs to be atomic?
I see several solutions by using the standard CHM; assuming you
already checked for Lock existence:
- create a Lock, use a putIfAbsent to store it, then *try* to acquire it
- create a Lock, acquire it, putIfAbsent to store it, throw your
instance away if you failed to store it and try again by starting over
from _get_ to lock on an eventually created new instance.
Yes if you get the ordering right, it can certainly be done. You might have to introduce a
state-based CAS or secondary lock though for some scenarios (I haven't thought through
them all) I think Manik's point though was just that getting it right is harder than
just making the whole thing atomic.
What I don't like of this is that you need to get/put on the same
key
multiple times, hashing the key over and over, looking up the same
segment again and potentially traversing segment locks for each of
these steps: the V8 solution from Jason looks like far more efficient.
V8 also has some other advantages. It does not use segments, so you don't have to tune
it. It also uses less memory, and it can deal with collisions much better.