Community
Participate
Working Groups
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. [Platform Debug, JDT Debug]
*** Bug 79913 has been marked as a duplicate of this bug. ***
We experimented with adding explicit locking support to the debug platform via the use of a rule factory (similar to resource scheduling rules) that clients can use to perform locking when communicating with (accessing and modifying) a debugger, which revealed the following: * The potential for deadlock increases. Debug model implementations may already use Java's built-in synchronization to implement thread safety. The additional use of scheduling rules as locks increases the chance of deadlocks in the following scenario: a debug element obtains a VM lock on an object, and performs a function that eventually requires a scheduling rule lock while another thread holds the scheduling rule lock, and is waiting for the VM lock. This could be avoided if the same locking mechanism were used by the client and implementation, but that would require debug model implementations to change and publicize their locking implementation. * Using the scheduling rule locks is expensive. Each access to a debug model would require the use of an access lock. Thus, simple operations take on larger overhead. For example, generating a label would require the following steps, which will have a performance impact. - retrieving the debug rule factory adapter for a debug element - getting an access scheduling rule from the factory for the element - locking on the rule - computing the label - releasing the lock * The client doesn't know when a lock is required. Requiring the use of locks is aggressive, and will no doubt cause locking when no locks are needed. Debug model implementations often cache information in the model to avoid communication with the back end (for example element names, etc.). Thus, clients will perform locking, when the implementation doesn't require it. Only the implementation knows when a lock is required. * Client code becomes more complex. Although I was able to reduce the code pattern to a simple try/finally block with a getLock(..) and releaseLock(..) method, code interacting with a debug model grows more complex, and harder to maintain. Based on these findings, I believe it is up to debug model implementations to assure they are thread safe, performing their own synchronization as needed. Models that require serialized communication with a back end are also required to implement such behavior in their model. In terms of API, this is not a breaking change. In terms of behavior, it is a change that may expose concurrency issues in existing debug model implementations. Debug model implementations need to ensure they are thread safe. Marking as won't fix, as it is up to clients to implement thread safety in their debuggers.
