Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[platform-debug-dev] Implementing a Debug Model supporting concurrent access

Hi
We have a debug model implementation which internally is heavily message
driven, and uses the UI thread for dispatching our events.  We quickly
ran into problems implementing the debug model interfaces, because many
of the methods are synchronous and are often called by clients on the UI
dispatch thread.  Specifically, the problem was that such calls were
blocking the UI for prolonged periods of time and they blocked the
dispatching of our internal messages, which lead to deadlock.

We managed to work around most of these problems
by implementing all of the interfaces that we support, in a non-blocking
way, and by relying on events to update the clients when data becomes
available.  For example, the IStep.stepOver() method only posts a
message request a step operation, and returns immediately, when step
operation starts, a DebugEvent.RUNNING event is generated.

For the debug model interfaces which cannot be implemented this way we
are left with very few options.  We could for example, when called on
the UI dispatch thread, block the caller and start an internal nested dispatch loop to process the messages that our debug engine needs to process the request, and when the result is fetched, finally return. Unfortunately this method and any alternatives we've come up with, have a high risk of deadlocks and other synchronization problems.

So the question is: Would it be possible to require debug model clients
to access the debug model ONLY on threads other than the UI dispatch
thread.  And if so, in what time frame could such a requirement be
implemented by the platform.

Pawel Piech
Wind River Systems






Back to the top