[jboss-dev-forums] [Design of JBossCache] - Re: Lock striping broken for Second Level Cache use case

[bstansberry@jboss.com]

I tried a locally built snapshot of trunk with dukehoops' test and the problem goes away.

Can you use a putIfAbsent instead of a get to try to preserve the original lock?  Idea being that if threads are waiting on the original lock you try to keep using it rather than having them queue up on a new lock.


  | ### Eclipse Workspace Patch 1.0
  | #P jbosscache-core
  | Index: src/main/java/org/jboss/cache/util/concurrent/locks/PerElementLockContainer.java
  | ===================================================================
  | --- src/main/java/org/jboss/cache/util/concurrent/locks/PerElementLockContainer.java	(revision 7915)
  | +++ src/main/java/org/jboss/cache/util/concurrent/locks/PerElementLockContainer.java	(working copy)
  | @@ -56,7 +56,8 @@
  |        Lock l = getLock(object);
  |        l.lock();
  |        // now check that the lock is still valid...
  | -      if (l != locks.get(object))
  | +      Lock official = locks.putIfAbsent(object, l);
  | +      if (official != null && l != official)
  |        {
  |           // we acquired the wrong lock!
  |           l.unlock();
  | 

(The above would be applied to the overloaded acquireLock(E, long. TimeUnit) as well.)

There is still a possibility that after the lock owner removes the lock from the map in releaseLock() another thread could sneak in and create a new lock. But that's not incorrect, just not fair.

View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4219185#4219185

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4219185