Shared Source CLI Essentials

Synchronizing Concurrent Access to Components

The sharing of resources between components that are using multiple threads is notoriously difficult. It is a subtle proposition to get right, and whole forests have been sacrificed to the topic. People continue to investigate and experiment with new deadlock detection and avoidance algorithms.

Access to shared resources must always be synchronized or carefully coordinated in some manner. Component programmers can use protection mechanisms that exist in the execution engine specifically for this purpose, choosing to use its primitives manually, or else use higher-level constructs and leave the details to the execution engine. Just as the thread pool makes working with threads easier for some common cases, automatic features, such as synchronized regions of code and synchronized access to component member types, can make programming easier and less bug-prone. As always, the tradeoff is one of complexity and control.

When using execution engine primitives directly, implementers can use a broad palette of managed classes that expose them, including the Interlocked type, the Monitor type, the ReaderWriterLock type, and both the ManualResetEvent and AutoResetEvent types. In addition to these types, WaitHandle is used to represent all synchronization objects in the runtime that allow multiple wait semantics, such as mutex and event handles. WaitHandle encapsulates PAL synchronization handles and uses the thread pool to make callbacks.

The CLI ...