[jbossts-issues] [JBoss JIRA] Commented: (JBTM-610) Restore mutex handling on LockManager
Andrew Dinn (JIRA)
jira-events at lists.jboss.org
Tue Aug 25 09:38:23 EDT 2009
[ https://jira.jboss.org/jira/browse/JBTM-610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12482619#action_12482619 ]
Andrew Dinn commented on JBTM-610:
Failure to synchronize on the LockManager calls is not actually the source of this deadlock. Adding the synchronizations will not hep and is probably unnecessary.
The problem manifested in the test failure occurs as followd
Threads A and B both have the same current acttion A. A includes an instance L in its participants list which inherits from LockManager.
Thread A calls L.setlock()
setLock synchronizes on LockManager.locksHeldLockObject ***
setLock calls super.modified() (i.e. StateManager.modified())
StateManager.modified fetches the current AtomicAction and calls BasicAction.add() which triies to syncrhonize on A^^^
Thread B calls BasicAction.abort() synchronizing on A ***
abort() calls L..topLevelAbort
L.topLevelAbort calls L.doRelease()
L.doReleasetries to synchronize on LockManager.locksHeldLockObject ^^^
So, the problem is a simple two way deadlock. A and B both obtain a lock at *** and then want the other guy's lock at ^^^.
Synchronizing on the Lock/StateManager calls will not stop this deadlock happening because the lock on the action can be taken in BasicAction.abort without going through any of the Lock/StateManager calls.
A proper fix requires all paths which can take one lock to already include the other lock. Calls to BasicAction.abort can quite legitimately happen with no reference to Lock/StateManager instances. So it is not reasonable to expect these calls to first obtain the LockManager.locksHeldLockObject. Hence, it will be necessary to synchronize on the current action in StateManager.setlock before synchronizing on the LockManager.locksHeldLockObject and risking an invocation of super.modified().
> Restore mutex handling on LockManager
> Key: JBTM-610
> URL: https://jira.jboss.org/jira/browse/JBTM-610
> Project: JBoss Transaction Manager
> Issue Type: Task
> Security Level: Public(Everyone can see)
> Components: Transaction Core
> Reporter: Mark Little
> Assignee: Mark Little
> Fix For: 4.8.0
> It looks like someone tried to optimize the synchronizations around LockManager, probably for HP-MS performance tuning. Unfortunately they didn't fully understand the implications. Backing out to original approach until/unless performance becomes an issue again.
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
More information about the jbossts-issues