[jbosscache-issues] [JBoss JIRA] Closed: (JBCACHE-1543) Remove contention due to PessimisticUnversionedNode.getLock()

[Brian Stansberry (JIRA)]

     [ https://jira.jboss.org/jira/browse/JBCACHE-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry closed JBCACHE-1543.
-------------------------------------

    Resolution: Done


> Remove contention due to PessimisticUnversionedNode.getLock()
> -------------------------------------------------------------
>
>                 Key: JBCACHE-1543
>                 URL: https://jira.jboss.org/jira/browse/JBCACHE-1543
>             Project: JBoss Cache
>          Issue Type: Task
>      Security Level: Public(Everyone can see) 
>          Components: Locking
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 3.2.1.CR1
>
>
> PessimisticUnversionedNode.getLock() shows up as a middling contention hotspot in profiling tests. The method always calls initLock(), which is a synchronized method. So any lock attempts will first have to briefly get the monitor for the node before they can move on to acquiring the lock.  This adds contention in the case of for higher level structural nodes in a tree (e.g. Fqn.ROOT).
> Solution is to make the PessimisticNodeLock.lock field volatile and then only call initLock() if it is null; aka double-checked locking. Making the field volatile ensures that the IdentityLock object is fully constructed before it is visible to other threads reading PessimisticUnversionedNode.lock, which is the requirement for making double-checked locking correct.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira