Actually, rather than a ref counter, I could rely on ReentrantLock's 
hasQueuedThreads().  But even this will not guard against edge cases - threads 
waiting, and then timing out, preventing the removal of unused locks and 
presenting a men leak.

On 17 Oct 2012, at 07:47, Dan Berindei <[email protected]> wrote:

> 
> On Wed, Oct 17, 2012 at 3:13 AM, Jason Greene <[email protected]> wrote:
> 
> 
> Sent from my iPhone
> 
> On Oct 16, 2012, at 10:39 AM, Jason Greene <[email protected]> wrote:
> 
> >> from _get_ to lock on an eventually created new instance.
> >
> > 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.
> 
> 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
> 
> 
> Right, you still need a retry loop on acquire, so why not use reference 
> counting and actually reuse the lock?
> 
> I think all you need is a tryAddRef method, something like this:
> 
>    public boolean tryAddRef() {
>       int newCount;
>       int oldCount;
>       do {
>          oldCount = refCount.get();
>          if (oldCount == 0)
>             return false;
>          newCount = oldCount + 1;
>       } while (!refCount.compareAndSet(oldCount, newCount));
>       return true;
>    }
> 
> 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.
> 
> _______________________________________________
> infinispan-dev mailing list
> [email protected]
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

--
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

Reply via email to