Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

OpenSolaris 2009.06 - man page for condition (opensolaris section 5)

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 dispo-
       sition,	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  condi-
       tion,  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 coop-
       erating 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 depen-
       dent  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  initial-
       ized. A condition variable is initialized with all zeros, by default, and its scope is set
       to within the calling process. For inter-process  synchronization,  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-ini-
       tialized 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 imple-
       ment 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:

       |      ATTRIBUTE TYPE	     |	    ATTRIBUTE VALUE	   |
       |MT-Level		     |MT-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_broad-
       cast(3C),    pthread_cond_destroy(3C),	pthread_cond_init(3C),	 pthread_cond_signal(3C),
       pthread_cond_timedwait(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 locations within the same address space, then
       the synch object should be initialized as a shared object USYNC_PROCESS for  Solaris,  and

SunOS 5.11				   20 Jul 1998				     condition(5)

All times are GMT -4. The time now is 03:29 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password