Quantcast

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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

robeden
Hey Holger -

Just checking: Is “1.10.0” the correct “Fix Version” for current bugs?

Rob

Begin forwarded message:

From: "reden (JIRA)" <[hidden email]>
Subject: [JIRA] Resolved: (GLAZEDLISTS-556) DebugList Locking is not thread safe
Date: April 17, 2014 at 10:01:49 AM CDT


    [ 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



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

hbrands
Administrator
Hi Rob,

yes, that's correct.

Holger


2014-04-17 17:45 GMT+02:00 Rob Eden <[hidden email]>:
Hey Holger -

Just checking: Is “1.10.0” the correct “Fix Version” for current bugs?

Rob

Begin forwarded message:

From: "reden (JIRA)" <[hidden email]>
Subject: [JIRA] Resolved: (GLAZEDLISTS-556) DebugList Locking is not thread safe
Date: April 17, 2014 at 10:01:49 AM CDT


    [ 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




Loading...