cds
2.3.2
|
A monitor is synchronization construction that allows threads to have both mutual exclusion and the ability to wait (block) for a certain condition to become true. Some blocking data structure algoritms like the trees require per-node locking. For huge trees containing millions of nodes it can be very inefficient to inject the lock object into each node. Moreover, some operating systems may not support the millions of system objects like mutexes per user process. The monitor strategy is intended to solve that problem. When the node should be locked, the monitor is called to allocate appropriate lock object for the node if needed, and to lock the node. The monitor strategy can significantly reduce the number of system objects required for data structure.
Implemetations
libcds
contains several monitor implementations:
sync::injecting_monitor
injects the lock object into each node. That mock monitor is designed for user-space locking primitive like spin-lock.sync::pool_monitor
is the monitor that allocates a lock object for a node from the pool when needed. When the node is unlocked the lock assigned to it is given back to the pool if no thread references to that node.How to use
If you use a container from libcds
that requires a monitor, you should just specify required monitor type in container's traits. Usually, the monitor is specified by traits::sync_monitor
typedef, or by cds::opt::sync_monitor
option for container's make_traits
metafunction.
If you're developing a new container algorithm, you should know internal monitor interface:
Monitor's data must be injected into container's node as m_SyncMonitorInjection
data member:
The monitor must be a member of your container: