1condition(5) Standards, Environments, and Macros condition(5)
2
3
4
6 condition - concepts related to condition variables
7
9 Occasionally, a thread running within a mutex needs to wait for an
10 event, in which case it blocks or sleeps. When a thread is waiting for
11 another thread to communicate its disposition, it uses a condition
12 variable in conjunction with a mutex. Although a mutex is exclusive and
13 the code it protects is sharable (at certain moments), condition vari‐
14 ables enable the synchronization of differing events that share a
15 mutex, but not necessarily data. Several condition variables may be
16 used by threads to signal each other when a task is complete, which
17 then allows the next waiting thread to take ownership of the mutex.
18
19
20 A condition variable enables threads to atomically block and test the
21 condition under the protection of a mutual exclusion lock (mutex)
22 until the condition is satisfied. If the condition is false, a thread
23 blocks on a condition variable and atomically releases the mutex that
24 is waiting for the condition to change. If another thread changes the
25 condition, it may wake up waiting threads by signaling the associated
26 condition variable. The waiting threads, upon awakening, reacquire the
27 mutex and re-evaluate the condition.
28
29 Initialize
30 Condition variables and mutexes should be global. Condition variables
31 that are allocated in writable memory can synchronize threads among
32 processes if they are shared by the cooperating processes (see mmap(2))
33 and are initialized for this purpose.
34
35
36 The scope of a condition variable is either intra-process or inter-
37 process. This is dependent upon whether the argument is passed implic‐
38 itly or explicitly to the initialization of that condition variable. A
39 condition variable does not need to be explicitly initialized. A condi‐
40 tion variable is initialized with all zeros, by default, and its scope
41 is set to within the calling process. For inter-process synchroniza‐
42 tion, a condition variable must be initialized once, and only once,
43 before use.
44
45
46 A condition variable must not be simultaneously initialized by multiple
47 threads or re-initialized while in use by other threads.
48
49
50 Condition variables attributes may be set to the default or customized
51 at initialization. POSIX threads even allow the default values to be
52 customized. Establishing these attributes varies depending upon whether
53 POSIX or Solaris threads are used. Similar to the distinctions between
54 POSIX and Solaris thread creation, POSIX condition variables implement
55 the default, intra-process, unless an attribute object is modified for
56 inter-process prior to the initialization of the condition variable.
57 Solaris condition variables also implement as the default, intra-
58 process; however, they set this attribute according to the argument,
59 type, passed to their initialization function.
60
61 Condition Wait
62 The condition wait interface allows a thread to wait for a condition
63 and atomically release the associated mutex that it needs to hold to
64 check the condition. The thread waits for another thread to make the
65 condition true and that thread's resulting call to signal and wakeup
66 the waiting thread.
67
68 Condition Signaling
69 A condition signal allows a thread to unblock the next thread waiting
70 on the condition variable, whereas, a condition broadcast allows a
71 thread to unblock all threads waiting on the condition variable.
72
73 Destroy
74 The condition destroy functions destroy any state, but not the space,
75 associated with the condition variable.
76
78 See attributes(5) for descriptions of the following attributes:
79
80
81
82
83 ┌─────────────────────────────┬─────────────────────────────┐
84 │ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
85 ├─────────────────────────────┼─────────────────────────────┤
86 │MT-Level │MT-Safe │
87 └─────────────────────────────┴─────────────────────────────┘
88
90 fork(2), mmap(2), setitimer(2), shmop(2), cond_broadcast(3C),
91 cond_destroy(3C), cond_init(3C), cond_signal(3C), cond_timedwait(3C),
92 cond_wait(3C), pthread_cond_broadcast(3C), pthread_cond_destroy(3C),
93 pthread_cond_init(3C), pthread_cond_signal(3C), pthread_cond_timed‐
94 wait(3C), pthread_cond_wait(3C), pthread_condattr_init(3C), signal(3C),
95 attributes(5), mutex(5), standards(5)
96
98 If more than one thread is blocked on a condition variable, the order
99 in which threads are unblocked is determined by the scheduling policy.
100
101
102 USYNC_THREAD does not support multiple mapplings to the same logical
103 synch object. If you need to mmap() a synch object to different loca‐
104 tions within the same address space, then the synch object should be
105 initialized as a shared object USYNC_PROCESS for Solaris, and
106 PTHREAD_PROCESS_PRIVATE for POSIX.
107
108
109
110SunOS 5.11 20 Jul 1998 condition(5)