condition(5) Standards, Environments, and Macros condition(5)NAMEcondition - concepts related to condition variables
DESCRIPTION
Occasionally, a thread running within a mutex needs to wait for an
event, in which case it blocks or sleeps. When a thread is waiting for
another thread to communicate its disposition, it uses a condition
variable in conjunction with a mutex. Although a mutex is exclusive and
the code it protects is sharable (at certain moments), condition vari‐
ables enable the synchronization of differing events that share a
mutex, but not necessarily data. Several condition variables may be
used by threads to signal each other when a task is complete, which
then allows the next waiting thread to take ownership of the mutex.
A condition variable enables threads to atomically block and test the
condition under the protection of a mutual exclusion lock (mutex)
until the condition is satisfied. If the condition is false, a thread
blocks on a condition variable and atomically releases the mutex that
is waiting for the condition to change. If another thread changes the
condition, it may wake up waiting threads by signaling the associated
condition variable. The waiting threads, upon awakening, reacquire the
mutex and re-evaluate the condition.
Initialize
Condition variables and mutexes should be global. Condition variables
that are allocated in writable memory can synchronize threads among
processes if they are shared by the cooperating processes (see mmap(2))
and are initialized for this purpose.
The scope of a condition variable is either intra-process or inter-
process. This is dependent upon whether the argument is passed implic‐
itly or explicitly to the initialization of that condition variable. A
condition variable does not need to be explicitly initialized. A condi‐
tion variable is initialized with all zeros, by default, and its scope
is set to within the calling process. For inter-process synchroniza‐
tion, a condition variable must be initialized once, and only once,
before use.
A condition variable must not be simultaneously initialized by multiple
threads or re-initialized while in use by other threads.
Condition variables attributes may be set to the default or customized
at initialization. POSIX threads even allow the default values to be
customized. Establishing these attributes varies depending upon whether
POSIX or Solaris threads are used. Similar to the distinctions between
POSIX and Solaris thread creation, POSIX condition variables implement
the default, intra-process, unless an attribute object is modified for
inter-process prior to the initialization of the condition variable.
Solaris condition variables also implement as the default, intra-
process; however, they set this attribute according to the argument,
type, passed to their initialization function.
Condition Wait
The condition wait interface allows a thread to wait for a condition
and atomically release the associated mutex that it needs to hold to
check the condition. The thread waits for another thread to make the
condition true and that thread's resulting call to signal and wakeup
the waiting thread.
Condition Signaling
A condition signal allows a thread to unblock the next thread waiting
on the condition variable, whereas, a condition broadcast allows a
thread to unblock all threads waiting on the condition variable.
Destroy
The condition destroy functions destroy any state, but not the space,
associated with the condition variable.
ATTRIBUTES
See attributes(5) for descriptions of the following attributes:
┌─────────────────────────────┬─────────────────────────────┐
│ ATTRIBUTE TYPE │ ATTRIBUTE VALUE │
├─────────────────────────────┼─────────────────────────────┤
│MT-Level │MT-Safe │
└─────────────────────────────┴─────────────────────────────┘
SEE ALSOfork(2), mmap(2), setitimer(2), shmop(2), cond_broadcast(3C),
cond_destroy(3C), cond_init(3C), cond_signal(3C), cond_timedwait(3C),
cond_wait(3C), pthread_cond_broadcast(3C), pthread_cond_destroy(3C),
pthread_cond_init(3C), pthread_cond_signal(3C), pthread_cond_timed‐
wait(3C), pthread_cond_wait(3C), pthread_condattr_init(3C), signal(3C),
attributes(5), mutex(5), standards(5)NOTES
If more than one thread is blocked on a condition variable, the order
in which threads are unblocked is determined by the scheduling policy.
USYNC_THREAD does not support multiple mapplings to the same logical
synch object. If you need to mmap() a synch object to different loca‐
tions within the same address space, then the synch object should be
initialized as a shared object USYNC_PROCESS for Solaris, and
PTHREAD_PROCESS_PRIVATE for POSIX.
SunOS 5.10 20 Jul 1998 condition(5)
