Manik, how about adding a reference count to the lock entry? If there is a waiter on the lock, the reverence count will be &gt; 0 and the owner won&#39;t remove the key on unlock.<br><br><br><div class="gmail_quote">On Tue, Oct 16, 2012 at 3:43 AM, Manik Surtani <span dir="ltr">&lt;<a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hmm, that actually might just do the trick.  Thanks!<div><div class="h5"><div><br><div>
<div>On 15 Oct 2012, at 17:46, Jason Greene &lt;<a href="mailto:jason.greene@redhat.com" target="_blank">jason.greene@redhat.com</a>&gt; wrote:</div><br><blockquote type="cite">I think what you are looking for is this:<br>
<br><a href="http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/ConcurrentHashMapV8.html#computeIfAbsent" target="_blank">http://gee.cs.oswego.edu/dl/jsr166/dist/jsr166edocs/jsr166e/ConcurrentHashMapV8.html#computeIfAbsent</a>(K, jsr166e.ConcurrentHashMapV8.Fun)<br>
<br>On Oct 15, 2012, at 11:23 AM, Manik Surtani &lt;<a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a>&gt; wrote:<br><br><blockquote type="cite">Guys, after investigating <a href="https://issues.jboss.org/browse/ISPN-2381" target="_blank">https://issues.jboss.org/browse/ISPN-2381</a> and <a href="https://github.com/infinispan/infinispan/pull/1382" target="_blank">https://github.com/infinispan/infinispan/pull/1382</a>, I&#39;ve discovered a pretty nasty race condition in our per-entry lock containers (whether OwnableReentrantLocks or JDK locks for non-transactional caches).<br>
<br>The problem is that we maintain a lock map, and any given request can acquire a lock, if a lock doesn&#39;t exist for a given key, create the lock and acquire it, and when done, release the lock and remove it from the lock map.  There&#39;s lots of room for races to occur.  The current impl uses a ConcurrentMap, where concurrent operations on the map are used to make sure locks are not overwritten.  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&#39;t good enough anymore.<br>
<br>The sledgehammer approach is to synchronise on this map for these two operations, but that causes all sorts of suckage.  Ideally, I&#39;d just hold on to the segment lock for the duration of these operations, but these aren&#39;t exposed.  Extending CHM to expose methods like acquireLockAndGet() and unlockAndRemove() would work perfectly, but again a lot of CHM internals are private or package protected.<br>
<br>So my options are: completely re-implement a CHM-like structure, like we&#39;ve done for BCHM, or perhaps think of a new, specialised structure to contain locks.  In terms of contract, I just need a fast way to look up a value under given a key, efficient put and remove as well.  It should be thread-safe (naturally), and allow for an atomic operation (like &quot;get, do work, put&quot;).<br>
<br>Any interesting new data structures on peoples&#39; minds?<br><br>Cheers<br>Manik<br>--<br>Manik Surtani<br><a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a><br><a href="http://twitter.com/maniksurtani" target="_blank">twitter.com/maniksurtani</a><br>
<br>Platform Architect, JBoss Data Grid<br><a href="http://red.ht/data-grid" target="_blank">http://red.ht/data-grid</a><br><br></blockquote><br></blockquote></div><br><div>
<span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<div>--</div><div>Manik Surtani</div><div><a href="mailto:manik@jboss.org" target="_blank">manik@jboss.org</a></div><div><a href="http://twitter.com/maniksurtani" target="_blank">twitter.com/maniksurtani</a></div><div><br>
</div><div><div>Platform Architect, JBoss Data Grid</div><div><a href="http://red.ht/data-grid" target="_blank">http://red.ht/data-grid</a></div></div></div></span></div></span></div></span>
</div>
<br></div></div></div></div><br>_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote></div><br>