This class encapsulates the complexity around handling Monitor.Enter / Monitor.Wait
when called on the UI-thread on Vista; the thread can be hi-jacked and
messages will be pumped (including WM_PAINT) which potentially can cause
deadlocks.
This class keeps track of the UI thread and handles calls to Enter and Wait
in a safe way.
Inheritance Hierarchy
Spotfire.Dxp.Framework.ThreadingSafeMonitor
Namespace: Spotfire.Dxp.Framework.Threading
Assembly: Spotfire.Dxp.Framework (in Spotfire.Dxp.Framework.dll) Version: 23.18.9504.3877 (23.18.9504.3877)
Syntax
C#
public static class SafeMonitor
The SafeMonitor type exposes the following members.
Methods
Name | Description | |
---|---|---|
Lock | Obsolete. Creates a lock that will work on the UI-thread as well as on background threads.
It must be called within a using-statement to assure that the Monitor is exited.
| |
PulseAll | Obsolete.
Pulses all threads waiting on the lock.
| |
Wait | Obsolete. Blocks until the waitDelegate returns false.
|
Remarks
Hijacking of the UI thread must be avoided since it can cause the deadlocks in the runtime property framework. The deadlock scenario is as follows:
- Events from the document are raised on the UI thread to a control C.
- The handler that is invoked reads a runtime property A in the model. Since A is not yet computed, it is marked as being under computation and the UI thread continues to compute A.
- The computer for A reads another runtime property, say FilteredRows, that is being computed by a worker thread. The UI thread must then wait for the worker thread to complete its computation and calls Monitor.Wait().
- Vista hijacks the UI thread and dispatches a Paint message to the same control, C.
- The handler for the paint message read the runtime property A. Since this runtime property is marked as being under computation, the UI thread must wait for computation of A to finish.
- We now have a deadlock situation since the UI thread is waiting for itself -- a situation that would never occur in any sensible threading model.
- The technical reason appears to be a change in CoWaitForMultipleHandles, which under Vista now dispatches WM_PAINT.
Version Information
See Also