Standards, Environments, and Macros condition(5)
NAME
condition - 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 exclu-
sion 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 condi-
tion, it may wake up waiting threads by signaling the asso-
ciated condition variable. The waiting threads, upon awaken-
ing, 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 syn-
chronize 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 implicitly or explicitly to the initialization of
that condition variable. A condition variable does not need
to be explicitly initialized. A condition variable is ini-
tialized with all zeros, by default, and its scope is set
to within the calling process. For inter-process synchroni-
zation, 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.
SunOS 5.11 Last change: 20 Jul 1998 1
Standards, Environments, and Macros condition(5)
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 attri-
butes 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 condi-
tion broadcast allows a thread to unblock all threads wait-
ing on the condition variable.
Destroy
The condition destroy functions destroy any state, but not
the space, associated with the condition variable.
ATRIBUTES
See attributes(5) for descriptions of the following attri-
butes:
ATRIBUTE TYPE ATRIBUTE VALUE
MT-Level MT-Safe
SEE ALSO
fork(2), mmap(2), setitimer(2), shmop(2),
condbroadcast(3C), conddestroy(3C), condinit(3C),
condsignal(3C), condtimedwait(3C), condwait(3C),
pthreadcondbroadcast(3C), pthreadconddestroy(3C),
pthreadcondinit(3C), pthreadcondsignal(3C),
pthreadcondtimedwait(3C), pthreadcondwait(3C),
pthreadcondattrinit(3C), signal(3C), attributes(5),
SunOS 5.11 Last change: 20 Jul 1998 2
Standards, Environments, and Macros condition(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.
USYNCTHREAD does not support multiple mapplings to the same
logical synch object. If you need to mmap() a synch object
to different locations within the same address space, then
the synch object should be initialized as a shared object
USYNCPROCES for Solaris, and PTHREADPROCESPRIVATE for
POSIX.
SunOS 5.11 Last change: 20 Jul 1998 3
|
