[jbossts-issues] [JBoss JIRA] Commented: (JBTM-610) Restore mutex handling on LockManager

[Andrew Dinn (JIRA)]

    [ 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^^^

in parallel

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