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.Threading SafeMonitor
Namespace: Spotfire.Dxp.Framework.Threading
Assembly: Spotfire.Dxp.Framework (in Spotfire.Dxp.Framework.dll) Version: 14.10.7525.5058 (14.10.7525.5058)
Syntax
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