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

[manik.surtani@jboss.com]

Ok, this can be done, but it won't be altogether straightforward:


  |   getLock(Fqn) {
  |     1. create new lock.
  |     2. putIfAbsent on the concurrent map that holds locks, swapping to the actual lock in the map if needed
  |     3. acquire lock
  |     4. after acquisition, check again that the lock is the current lock in the concurrent map, if not, release lock and retry this method.
  |   }
  | 
  |   releaseLock(Fqn) {
  |     1.  get lock from map
  |     2.  if not null, and if owner, attempt to release lock
  |     3.  remove lock from collection
  |   }
  | 

While this will work, this will cause waiters to spin on getLock().4 until it has got the same lock it expects.  In releaseLock().3, this will cause threads that release locks to clean up, but will cause additional spinning on getLock().4.  Basically, in getLock(), a lock is only valid if you created it in getLock().1.

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

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