Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
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  mu-
       tex,  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)  un-
       til  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, be-
       fore 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:

       |      ATTRIBUTE	TYPE	     |	    ATTRIBUTE VALUE	   |
       |MT-Level		     |MT-Safe			   |

       fork(2),	 mmap(2), setitimer(2),	shmop(2), cond_broadcast(3C), cond_de-
       stroy(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)


Want to link to this manual page? Use this URL:

home | help