[infinispan-dev] Per-entry lock container
Manik Surtani
manik at jboss.org
Wed Oct 17 09:16:00 EDT 2012
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 <dan.berindei at gmail.com> wrote:
>
> On Wed, Oct 17, 2012 at 3:13 AM, Jason Greene <jgreene at redhat.com> wrote:
>
>
> Sent from my iPhone
>
> On Oct 16, 2012, at 10:39 AM, Jason Greene <jason.greene at redhat.com> 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
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani
Platform Architect, JBoss Data Grid
http://red.ht/data-grid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121017/f278ec56/attachment.html
More information about the infinispan-dev
mailing list