SafeMonitor Class

Spotfire 14.2 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

SystemObject
  Spotfire.Dxp.Framework.ThreadingSafeMonitor

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

C#
public static class SafeMonitor

The SafeMonitor type exposes the following members.

Methods

  NameDescription
Public methodStatic memberLock 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.
Public methodStatic memberPulseAll Obsolete.
Pulses all threads waiting on the lock.
Public methodStatic memberWait Obsolete.
Blocks until the waitDelegate returns false.
Top
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:

  1. Events from the document are raised on the UI thread to a control C.
  2. 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.
  3. 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().
  4. Vista hijacks the UI thread and dispatches a Paint message to the same control, C.
  5. 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.
  6. 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.
  7. The technical reason appears to be a change in CoWaitForMultipleHandles, which under Vista now dispatches WM_PAINT.

Version Information

Supported in: 14.2, 14.1, 14.0, 12.5, 12.4, 12.3, 12.2, 12.1, 12.0, 11.8, 11.7, 11.6, 11.5, 11.4
See Also

Reference