SafeMonitor Class

TIBCO Spotfire 6.0 API Reference

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

System Object
Spotfire.Dxp.Framework.Threading SafeMonitor

Namespace: Spotfire.Dxp.Framework.Threading
Assembly: Spotfire.Dxp.Framework (in Spotfire.Dxp.Framework.dll) Version: 13.19.7018.3940 (13.19.7018.3940)

Syntax

C++

Copy to Clipboard Print

public static class SafeMonitor

public static class SafeMonitor

Remarks

On Vista, the UI thread can be hijacked and used to pump Paint messages when it calls Monitor.Wait(), Monitor.Enter() and several other operations that one expects would suspend the calling thread (e.g. Thread.Join etc). Vista will hijack the thread if the wait is too long in order to keep the UI resposive.

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.