Re: [infinispan-dev] Per-entry lock container
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(a)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(a)jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
Attachments:
- attachment.html (text/html — 3.9 KB)