Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 79913 - Concurrency support
Summary: Concurrency support
Status: RESOLVED DUPLICATE of bug 80152
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.1   Edit
Hardware: PC Windows XP
: P3 enhancement (vote)
Target Milestone: 3.1   Edit
Assignee: Platform-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-12-01 13:44 EST by Darin Wright CLA
Modified: 2004-12-13 16:30 EST (History)
0 users

See Also:

Attachments
patch in progress (12.14 KB, patch)
2004-12-01 13:45 EST, Darin Wright CLA 		no flags Details | Diff
patch in progress - debug.ui (30.01 KB, patch)
2004-12-01 13:46 EST, Darin Wright CLA 		no flags Details | Diff
patch in progress - jdt.debug (2.41 KB, patch)
2004-12-01 13:46 EST, Darin Wright CLA 		no flags Details | Diff
patch in progress - jdt.debug.ui (3.20 KB, patch)
2004-12-01 13:46 EST, Darin Wright CLA 		no flags Details | Diff
View All 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 Darin Wright CLA 2004-12-01 13:44:35 EST 
Many debug architectures require communicating with a remote debug target. The 
debug user interface needs to be robust in the face of latent and unreliable 
connections. To avoid blocking the user interface, the debug platform is 
exploiting the use of background jobs to perform operations and communicate 
with debuggers. As the opportunity for concurrent requests against debuggers 
increases, the platform must provide support for serializing conflicting 
requests against debuggers - for example a read operation to render a stack 
frame and a request that would invalidate the stack frame by resuming its 
thread. The debug platform needs to provide API and a set of guidlines to 
follow when scheduling concurrent operations and requests against debuggers.
Comment 1 Darin Wright CLA 2004-12-01 13:45:20 EST 
Created attachment 16273 [details]
patch in progress
Comment 2 Darin Wright CLA 2004-12-01 13:46:00 EST 
Created attachment 16274 [details]
patch in progress - debug.ui
Comment 3 Darin Wright CLA 2004-12-01 13:46:20 EST 
Created attachment 16275 [details]
patch in progress - jdt.debug
Comment 4 Darin Wright CLA 2004-12-01 13:46:46 EST 
Created attachment 16276 [details]
patch in progress - jdt.debug.ui
Comment 5 Darin Wright CLA 2004-12-01 23:54:21 EST 
Created a branch with work in progress for these plug-ins:

* org.eclipse.deubg.core
* org.eclipse.deubg.ui
* org.eclipse.jdt.deubg
* org.eclipse.jdt.deubg.ui

The branch name is r3_1_debug_concurrency_branch
Comment 6 Darin Wright CLA 2004-12-02 17:30:27 EST 
Discoveries:

* A debug model may already implement its own concurrency/thread safe support 
via synchronization/locking. When combined with the locks proposed in this 
feature request, two sets of locks are active which could cause deadlocks. 
I.e. the debug UI obtains a rule lock on a thread, and then needs VM lock on 
an object, while a debug element maintains a VM lock on an object and needs a 
rule lock.
* Obtaining locks at the client (debug UI) end is very agressive. I.e. 
obtaining an access lock to generate a label is agressive since it is possible 
that the information is cached in the debug element, and requires no 
communication with the target. Only the model knows when/if 
communication/locking is required.
* Obtaining locks has a performance hit. For each access, rather than an API 
call an adapter must be obtained, a rule generated, and a lock obtained on the 
rule, and then the API call followed by the release.
Comment 7 Darin Wright CLA 2004-12-13 16:30:16 EST 
Marking as dup of plan item bug.

*** This bug has been marked as a duplicate of 80152 ***