[infinispan-dev] Per-entry lock container

Dan Berindei dan.berindei at gmail.com
Wed Oct 17 02:47:04 EDT 2012


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20121017/4b5ca265/attachment.html 


More information about the infinispan-dev mailing list