condition(5)						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 variables 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
       condition  variable  is initialized with all zeros, by default, and its scope is set  to within the calling process. For inter-process syn-
       chronization, 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 ALSO

       fork(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 pol-
       icy.

       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.11							    20 Jul 1998 						      condition(5)