<br><div class="gmail_quote">On Wed, Oct 17, 2012 at 3:13 AM, Jason Greene <span dir="ltr"><<a href="mailto:jgreene@redhat.com" target="_blank">jgreene@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
Sent from my iPhone<br>
<div class="im"><br>
On Oct 16, 2012, at 10:39 AM, Jason Greene <<a href="mailto:jason.greene@redhat.com">jason.greene@redhat.com</a>> wrote:<br>
<br>
>> from _get_ to lock on an eventually created new instance.<br>
><br>
> 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.<br>
<br>
</div>Although there is no way out of the remove, you still have to recheck the lock is valid after every successful aquire, and then try to lock the new lock<br></blockquote></div><br><br>Right, you still need a retry loop on acquire, so why not use reference counting and actually reuse the lock?<br>
<br>I think all you need is a tryAddRef method, something like this:<br><br> public boolean tryAddRef() {<br> int newCount;<br> int oldCount;<br> do {<br> oldCount = refCount.get();<br> if (oldCount == 0)<br>
return false;<br> newCount = oldCount + 1;<br> } while (!refCount.compareAndSet(oldCount, newCount));<br> return true;<br> }<br><br>Then in your acquireLock you call tryAddRef in a loop and when it returns true you can go on and really acquire the lock - knowing that another thread can't remove it from the map.<br>
<br>