condition man page on SmartOS

Man page or keyword search:  
man Server   16655 pages
apropos Keyword Search (all sections)
Output format
SmartOS logo
[printable version]


       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 argu‐
       ment, 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:

       │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_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

				 Jul 20, 1998			  CONDITION(5)

List of man pages available for SmartOS

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
Vote for polarhome
Free Shell Accounts :: the biggest list on the net