pthread_cond_signal manpage

Search topic Section
Get manual page for the search topic
List all commands matching the search topic
List all topics in the manpage index


       This  manual  page is part of the POSIX Programmer's Manual.  The Linux
       implementation of this interface may differ (consult the	 corresponding
       Linux  manual page for details of Linux behavior), or the interface may
       not be implemented on Linux.

       pthread_cond_broadcast, pthread_cond_signal -  broadcast	 or  signal  a

       #include <pthread.h>

       int pthread_cond_broadcast(pthread_cond_t *cond);
       int pthread_cond_signal(pthread_cond_t *cond);

       These  functions shall unblock threads blocked on a condition variable.

       The pthread_cond_broadcast() function shall unblock  all	 threads  cur-
       rently blocked on the specified condition variable cond.

       The  pthread_cond_signal()  function  shall unblock at least one of the
       threads that are blocked on the specified condition variable  cond  (if
       any threads are blocked on cond).

       If  more	 than  one  thread  is	blocked	 on  a condition variable, the
       scheduling policy shall	determine  the	order  in  which  threads  are
       unblocked.   When   each	  thread   unblocked   as   a	result	 of  a
       pthread_cond_broadcast() or pthread_cond_signal() returns from its call
       to  pthread_cond_wait()	or  pthread_cond_timedwait(), the thread shall
       own  the	 mutex	 with	which	it   called   pthread_cond_wait()   or
       pthread_cond_timedwait().  The  thread(s) that are unblocked shall con-
       tend for the mutex according to the scheduling policy (if  applicable),
       and as if each had called pthread_mutex_lock().

       The  pthread_cond_broadcast() or pthread_cond_signal() functions may be
       called by a thread whether or not it  currently	owns  the  mutex  that
       threads	calling	 pthread_cond_wait()  or pthread_cond_timedwait() have
       associated with the condition variable during their waits; however,  if
       predictable  scheduling	behavior is required, then that mutex shall be
       locked	by   the   thread    calling	pthread_cond_broadcast()    or

       The  pthread_cond_broadcast() and pthread_cond_signal() functions shall
       have no effect if there are no threads currently blocked on cond.

       If successful, the pthread_cond_broadcast()  and	 pthread_cond_signal()
       functions  shall	 return	 zero;	otherwise,  an	error  number shall be
       returned to indicate the error.

       The pthread_cond_broadcast()  and  pthread_cond_signal()	 function  may
       fail if:

       EINVAL The  value cond does not refer to an initialized condition vari-

       These functions shall not return an error code of [EINTR].

       The following sections are informative.


       The pthread_cond_broadcast() function is used whenever the shared-vari-
       able state has been changed in a way that more than one thread can pro-
       ceed with its task. Consider a single producer/multiple consumer	 prob-
       lem,  where  the	 producer  can insert multiple items on a list that is
       accessed one  item  at  a  time	by  the	 consumers.   By  calling  the
       pthread_cond_broadcast()	 function,  the producer would notify all con-
       sumers that might be waiting, and thereby the application would receive
       more  throughput on a multi-processor. In addition, pthread_cond_broad-
       cast()  makes  it  easier  to  implement	  a   read-write   lock.   The
       pthread_cond_broadcast()	 function  is  needed  in order to wake up all
       waiting readers when a writer releases its  lock.   Finally,  the  two-
       phase  commit  algorithm	 can use this broadcast function to notify all
       clients of an impending transaction commit.

       It is not safe to use the pthread_cond_signal() function	 in  a	signal
       handler	that  is  invoked  asynchronously. Even if it were safe, there
       would  still  be	  a   race   between   the   test   of	 the   Boolean
       pthread_cond_wait() that could not be efficiently eliminated.

       Mutexes	and  condition variables are thus not suitable for releasing a
       waiting thread by signaling from code running in a signal handler.

   Multiple Awakenings by Condition Signal
       On a multi-processor, it may be impossible  for	an  implementation  of
       pthread_cond_signal()  to  avoid the unblocking of more than one thread
       blocked on a condition variable. For example,  consider	the  following
       partial	implementation	of  pthread_cond_wait()	 and pthread_cond_sig-
       nal(), executed by two threads in the order given. One thread is trying
       to  wait	 on  the condition variable, another is concurrently executing
       pthread_cond_signal(), while a third thread is already waiting.

	      pthread_cond_wait(mutex, cond):
		  value = cond->value; /* 1 */
		  pthread_mutex_unlock(mutex); /* 2 */
		  pthread_mutex_lock(cond->mutex); /* 10 */
		  if (value == cond->value) { /* 11 */
		      me->next_cond = cond->waiter;
		      cond->waiter = me;
		  } else
		      pthread_mutex_unlock(cond->mutex); /* 12 */
		  pthread_mutex_lock(mutex); /* 13 */

		  pthread_mutex_lock(cond->mutex); /* 3 */
		  cond->value++; /* 4 */
		  if (cond->waiter) { /* 5 */
		      sleeper = cond->waiter; /* 6 */
		      cond->waiter = sleeper->next_cond; /* 7 */
		      able_to_run(sleeper); /* 8 */
		  pthread_mutex_unlock(cond->mutex); /* 9 */

       The effect is that more than one thread can return  from	 its  call  to
       pthread_cond_wait() or pthread_cond_timedwait() as a result of one call
       to pthread_cond_signal(). This  effect  is  called  "spurious  wakeup".
       Note  that  the	situation  is  self-correcting	in  that the number of
       threads that are so awakened is finite; for example, the next thread to
       call pthread_cond_wait() after the sequence of events above blocks.

       While  this  problem  could  be	resolved, the loss of efficiency for a
       fringe condition that occurs only rarely	 is  unacceptable,  especially
       given  that  one has to check the predicate associated with a condition
       variable anyway. Correcting this problem would unnecessarily reduce the
       degree of concurrency in this basic building block for all higher-level
       synchronization operations.

       An added benefit of allowing spurious wakeups is that applications  are
       forced to code a predicate-testing-loop around the condition wait. This
       also makes the application tolerate superfluous condition broadcasts or
       signals	on the same condition variable that may be coded in some other
       part of the application.	 The  resulting	 applications  are  thus  more
       robust.	Therefore, IEEE Std 1003.1-2001 explicitly documents that spu-
       rious wakeups may occur.


       pthread_cond_destroy() , pthread_cond_timedwait() ,  the	 Base  Defini-
       tions volume of IEEE Std 1003.1-2001, <pthread.h>

       Portions	 of  this text are reprinted and reproduced in electronic form
       from IEEE Std 1003.1, 2003 Edition, Standard for Information Technology
       --  Portable  Operating	System	Interface (POSIX), The Open Group Base
       Specifications Issue 6, Copyright (C) 2001-2003	by  the	 Institute  of
       Electrical  and	Electronics  Engineers, Inc and The Open Group. In the
       event of any discrepancy between this version and the original IEEE and
       The  Open Group Standard, the original IEEE and The Open Group Standard
       is the referee document. The original Standard can be  obtained	online
       at http://www.opengroup.org/unix/online.html .

IEEE/The Open Group		     2003	     PTHREAD_COND_BROADCAST(P)
YoLinux.com Home Page
YoLinux Tutorial Index
Privacy Policy | Advertise with us | Feedback Form |
Unauthorized copying or redistribution prohibited.
    Bookmark and Share