[infinispan-dev] Per-entry lock container

[Manik Surtani]

Just re-read this and this explanation isn't clear at all.

Essentially, step 1.3 cannot commence until the lock is released in the closure passed to computeIfPresent() in code path 2.  This ensures that the process to remove the lock from the map has commenced, even if it isn't finished.  Step 1.4 now cannot proceed until the closure to remove the lock has completed and we know for sure that the lock has been removed.  This is what effectively removes the race I described earlier.

Dan, I'll look into your refcounting approach as an alternative.

On 17 Oct 2012, at 13:51, Manik Surtani <manik at jboss.org> wrote:

> 
> This seems to have solved things, because step 1.4 cannot proceed until any remove operation completes (competing for the same entry space in the map) and process 1 cannot get beyond 1.3 since the lock is still held by the releasing thread in step 2.  But I'm still testing further in case of edge cases.

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121017/c7b71ee9/attachment-0001.html