Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

Linux 2.6 - man page for pthread_cond_broadcast (linux section 3posix)


       pthread_cond_broadcast, pthread_cond_signal - broadcast or signal a condition

       #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 currently 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 contend 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 pthread_cond_signal().

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

       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-variable state has been
       changed in a way that more than one thread can proceed with its task.  Consider	a  single
       producer/multiple consumer problem, 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_broad-
       cast()  function,  the  producer  would	notify	all  consumers that might be waiting, and
       thereby the application would receive more throughput on a multi-processor.  In	addition,
       pthread_cond_broadcast()   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 exam-
       ple,   consider	 the   following   partial   implementation  of  pthread_cond_wait()  and
       pthread_cond_signal(), 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 syn-
       chronization 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  spurious  wakeups  may


       pthread_cond_destroy()  ,  pthread_cond_timedwait()  ,  the  Base  Definitions  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 orig-
       inal Standard can be obtained online at http://www.opengroup.org/unix/online.html .

IEEE/The Open Group			       2003			PTHREAD_COND_BROADCAST(P)

All times are GMT -4. The time now is 03:18 AM.

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