Re: [infinispan-dev] Per-entry lock container

On Oct 16, 2012, at 10:33 AM, Sanne Grinovero <sanne(a)infinispan.org&gt; 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. _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev