Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (SunOS-5.10)
Apropos / Subsearch:
optional field

condition(5)          Standards, Environments, and Macros         condition(5)

       condition - concepts related to condition variables

       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.

       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.

       The condition destroy functions destroy any state, but not  the  space,
       associated with the condition variable.

       See attributes(5) for descriptions of the following attributes:

       tab()     allbox;     cw(2.750000i)|    cw(2.750000i)    lw(2.750000i)|
       lw(2.750000i).  ATTRIBUTE TYPEATTRIBUTE VALUE MT-LevelMT-Safe

       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)

       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

SunOS 5.10                        20 Jul 1998                     condition(5)