blob: 647bdb1b5466ba1faf69ccaecaa8cd0f6e627be1 (
plain)
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
|
This chapter describes the functions you use when you work with cached
monitors. Unlike a plain monitor, a cached monitor is associated with
the address of a protected object, and the association is maintained
only while the protection is needed. This arrangement allows a cached
monitor to be associated with another object without preallocating a
monitor for all objects. A hash table is used to quickly map addresses
to their respective monitors. The system automatically enlarges the hash
table as needed.
Important
---------
Cached monitors are slower to use than their uncached counterparts.
See `Monitors <Monitors>`__ for information about uncached monitors.
.. _Cached_Monitors_Functions:
Cached Monitors Functions
-------------------------
Cached monitors allow the client to associate monitoring protection and
state change synchronization in a lazy fashion. The monitoring
capability is associated with the protected object only during the time
it is required, allowing the monitor object to be reused. This
additional flexibility comes at the cost of a small loss in performance.
- :ref:`PR_CEnterMonitor` enters the lock associated with a cached
monitor.
- :ref:`PR_CExitMonitor` decrements the entry count associated with a
cached monitor.
- :ref:`PR_CWait` waits for a notification that a monitor's state has
changed.
- :ref:`PR_CNotify` notifies a thread waiting for a change in the state of
monitored data.
- :ref:`PR_CNotifyAll` notifies all the threads waiting for a change in
the state of monitored data.
|
