[JIRA] Created: (GLAZEDLISTS-556) DebugList Locking is not thread safe

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[JIRA] Created: (GLAZEDLISTS-556) DebugList Locking is not thread safe

JIRA jira-no-reply@java.net
DebugList Locking is not thread safe
------------------------------------

                 Key: GLAZEDLISTS-556
                 URL: http://java.net/jira/browse/GLAZEDLISTS-556
             Project: glazedlists
          Issue Type: Bug
          Components: core
    Affects Versions: current
         Environment: All supported environments
            Reporter: goochjj
         Attachments: 0001-updates-to-DebugList-and-DebugLock-semantics.patch

DebugLock uses an ArrayList internally to track Threads that have locked the delegate.  The access to the ArrayList is (mostly) done within the locked area of the locks; however, our locks are reentrant, and the read lock allows multiple readers.  Plus checking uses the contains method which is run from an unlocked thread.

When instantiating threadsHoldingLock it should be wrapped in a Collections.synchronizedList call.

In addition, I have enhanced the checks to detect deadlocks caused by the inability to upgrade a read lock to a write lock.

See attached patch.


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

       
Reply | Threaded
Open this post in threaded view
|

[JIRA] Commented: (GLAZEDLISTS-556) DebugList Locking is not thread safe

JIRA jira-no-reply@java.net

    [ https://java.net/jira/browse/GLAZEDLISTS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=374360#action_374360 ]

reden commented on GLAZEDLISTS-556:
-----------------------------------

Bah, I've been hitting this issue for weeks. Finally took the time to debug through it and came to the same conclusion. Should have looked at the bug database first. :-)

Fixing...

> DebugList Locking is not thread safe
> ------------------------------------
>
>                 Key: GLAZEDLISTS-556
>                 URL: https://java.net/jira/browse/GLAZEDLISTS-556
>             Project: glazedlists
>          Issue Type: Bug
>          Components: core
>    Affects Versions: current
>         Environment: All supported environments
>            Reporter: goochjj
>         Attachments: 0001-updates-to-DebugList-and-DebugLock-semantics.patch
>
>   Original Estimate: 15 minutes
>  Remaining Estimate: 15 minutes
>
> DebugLock uses an ArrayList internally to track Threads that have locked the delegate.  The access to the ArrayList is (mostly) done within the locked area of the locks; however, our locks are reentrant, and the read lock allows multiple readers.  Plus checking uses the contains method which is run from an unlocked thread.
> When instantiating threadsHoldingLock it should be wrapped in a Collections.synchronizedList call.
> In addition, I have enhanced the checks to detect deadlocks caused by the inability to upgrade a read lock to a write lock.
> See attached patch.

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

       
Reply | Threaded
Open this post in threaded view
|

[JIRA] Assigned: (GLAZEDLISTS-556) DebugList Locking is not thread safe

JIRA jira-no-reply@java.net
In reply to this post by JIRA jira-no-reply@java.net

     [ https://java.net/jira/browse/GLAZEDLISTS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

reden reassigned GLAZEDLISTS-556:
---------------------------------

    Assignee: reden

> DebugList Locking is not thread safe
> ------------------------------------
>
>                 Key: GLAZEDLISTS-556
>                 URL: https://java.net/jira/browse/GLAZEDLISTS-556
>             Project: glazedlists
>          Issue Type: Bug
>          Components: core
>    Affects Versions: current
>         Environment: All supported environments
>            Reporter: goochjj
>            Assignee: reden
>         Attachments: 0001-updates-to-DebugList-and-DebugLock-semantics.patch
>
>   Original Estimate: 15 minutes
>  Remaining Estimate: 15 minutes
>
> DebugLock uses an ArrayList internally to track Threads that have locked the delegate.  The access to the ArrayList is (mostly) done within the locked area of the locks; however, our locks are reentrant, and the read lock allows multiple readers.  Plus checking uses the contains method which is run from an unlocked thread.
> When instantiating threadsHoldingLock it should be wrapped in a Collections.synchronizedList call.
> In addition, I have enhanced the checks to detect deadlocks caused by the inability to upgrade a read lock to a write lock.
> See attached patch.

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

       
Reply | Threaded
Open this post in threaded view
|

[JIRA] Resolved: (GLAZEDLISTS-556) DebugList Locking is not thread safe

JIRA jira-no-reply@java.net
In reply to this post by JIRA jira-no-reply@java.net

     [ https://java.net/jira/browse/GLAZEDLISTS-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

reden resolved GLAZEDLISTS-556.
-------------------------------

    Fix Version/s: 1.10.0
       Resolution: Fixed

Changes applies in svn change 2376:
{quote}
Fix of GLAZEDLISTS-556: applied patch from user "goochjj" with slight modification:
 - Fixed spelling of "acquire"
 - Removed check in beforeWriteOperation that was seeing if a read lock was held instead. It was redundant (since trying to get a write lock when a read lock is held would already throw an error) or wrong (since downgrading a write lock to a read lock is permitted) and was causing issues with unit tests.
{quote}

> DebugList Locking is not thread safe
> ------------------------------------
>
>                 Key: GLAZEDLISTS-556
>                 URL: https://java.net/jira/browse/GLAZEDLISTS-556
>             Project: glazedlists
>          Issue Type: Bug
>          Components: core
>    Affects Versions: current
>         Environment: All supported environments
>            Reporter: goochjj
>            Assignee: reden
>             Fix For: 1.10.0
>
>         Attachments: 0001-updates-to-DebugList-and-DebugLock-semantics.patch
>
>   Original Estimate: 15 minutes
>  Remaining Estimate: 15 minutes
>
> DebugLock uses an ArrayList internally to track Threads that have locked the delegate.  The access to the ArrayList is (mostly) done within the locked area of the locks; however, our locks are reentrant, and the read lock allows multiple readers.  Plus checking uses the contains method which is run from an unlocked thread.
> When instantiating threadsHoldingLock it should be wrapped in a Collections.synchronizedList call.
> In addition, I have enhanced the checks to detect deadlocks caused by the inability to upgrade a read lock to a write lock.
> See attached patch.

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