condition man page on Solaris

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

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 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.

   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 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.

   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 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
       PTHREAD_PROCESS_PRIVATE for POSIX.

SunOS 5.10			  20 Jul 1998			  condition(5)
[top]

List of man pages available for Solaris

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]
Tweet
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