File: monitor.h

package info (click to toggle)
libcds 2.3.3-6
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 15,632 kB
  • sloc: cpp: 135,002; ansic: 7,234; perl: 243; sh: 237; makefile: 6
file content (121 lines) | stat: -rw-r--r-- 4,693 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
// Copyright (c) 2006-2018 Maxim Khizhinsky
//
// Distributed under the Boost Software License, Version 1.0. (See accompanying
// file LICENSE or copy at http://www.boost.org/LICENSE_1_0.txt)

#ifndef CDSLIB_SYNC_MONITOR_H
#define CDSLIB_SYNC_MONITOR_H

#include <cds/details/defs.h>

namespace cds { namespace sync {
    /**
        @page cds_sync_monitor Synchronization monitor
        A <a href="http://en.wikipedia.org/wiki/Monitor_%28synchronization%29">monitor</a> 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.

        <b>Implemetations</b>

        \p libcds contains several monitor implementations:
        - \p sync::injecting_monitor injects the lock object into each node.
            That mock monitor is designed for user-space locking primitive like
            \ref sync::spin_lock "spin-lock".
        - \p 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.

        <b>How to use</b>

        If you use a container from \p libcds that requires a monitor, you should just
        specify required monitor type in container's traits. Usually, the monitor
        is specified by \p traits::sync_monitor typedef, or by \p cds::opt::sync_monitor
        option for container's \p make_traits metafunction.

        If you're developing a new container algorithm, you should know internal monitor
        interface:
        \code
        class Monitor {
        public:
            // Monitor's injection into the Node class
            template <typename Node>
            struct node_injection: public Node
            {
                // Monitor data injecting into container's node
                // ...
            };
            // Locks the node
            template <typename Node>
            void lock( Node& node );
            // Unlocks the node
            template <typename Node>
            void unlock( Node& node );
            // Scoped lock applyes RAII to Monitor
            template <typename Node>
            using scoped_lock = monitor_scoped_lock< pool_monitor, Node >;
        };
        \endcode
        Monitor's data must be injected into container's node as \p m_SyncMonitorInjection data member:
        \code
        template <typename SyncMonitor>
        struct my_node
        {
            // ...
            typename SyncMonitor::node_injection m_SyncMonitorInjection;
        };
        \endcode
        The monitor must be a member of your container:
        \code
        template <typename GC, typename T, typename Traits>
        class my_container {
            // ...
            typedef typename Traits::sync_monitor   sync_monitor;
            typedef my_node<sync_monitor> node_type;
            sync_monitor m_Monitor;
            //...
        };
        \endcode
    */
    /// Monitor scoped lock (RAII)
    /**
        Template arguments:
        - \p Monitor - monitor type
        - \p Node - node type
    */
    template <typename Monitor, typename Node>
    struct monitor_scoped_lock
    {
    public:
        typedef Monitor monitor_type;   ///< Monitor type
        typedef Node    node_type;      ///< Node type
    private:
        //@cond
        monitor_type&    m_Monitor; ///< Monitor
        node_type const& m_Node;    ///< Our locked node
        //@endcond
    public:
        /// Makes exclusive access to the node \p p by \p monitor
        monitor_scoped_lock( monitor_type& monitor, node_type const& p )
            : m_Monitor( monitor )
            , m_Node( p )
        {
            monitor.lock( p );
        }
        /// Unlocks the node
        ~monitor_scoped_lock()
        {
            m_Monitor.unlock( m_Node );
        }
    };
}} // namespace cds::sync
#endif // #ifndef CDSLIB_SYNC_MONITOR_H