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 <[email protected]> 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 [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
