Bug 250311 - Surface resource notification lock
Summary: Surface resource notification lock
Status: NEW
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Resources (show other bugs)
Version: 3.4   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Platform-Resources-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords: investigate
Depends on: 249951
Blocks:
  Show dependency tree
 
Reported: 2008-10-09 12:06 EDT by Jerome Lanneluc CLA
Modified: 2015-04-01 09:50 EDT (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jerome Lanneluc CLA 2008-10-09 12:06:49 EDT 
I20081007-1600

As shown in bug 249930, a deadlock can occur between Platform/Resource and a client because Platform/Resources takes a lock while notifying resource changes (in one thread), and a client can take its own lock while modifying the resource (in another thread).

One way to solve this issue would be to surface the resource notification lock so that the client could make sure to take this resource notification  lock before taking its own lock. 

The resource notification lock could be surfaced using a runnable. If the client's code runs inside this runnable, it would ensure that resource notification lock has been taken.
Comment 1 James Blackburn CLA 2011-05-04 15:37:45 EDT 
AFAIK the notification is the only place where client code is called while holding the WS lock.  Instead of providing access to this lock, we could instead consider not holding the WS lock during notification.
Linking to bug 249951.
Comment 2 Szymon Brandys CLA 2015-04-01 09:50:28 EDT 
I am no longer involved in Platform Core development.