Return Values
pthread_cond_reltimedwait_np() returns zero after completing successfully. Any other return value indicates that an error occurred. When either of the following conditions occurs, the function fails and returns the corresponding value.
cv or reltime points to an illegal address.
The time interval specified by reltime has passed.
Unblock All Threads
pthread_cond_broadcast(3THR)
Prototype: int pthread_cond_broadcast(pthread_cond_t *cv); |
#include <pthread.h> pthread_cond_t cv; int ret; /* all condition variables are signaled */ ret = pthread_cond_broadcast(&cv); |
Use pthread_cond_broadcast(3THR) to unblock all threads that are blocked on the condition variable pointed to by cv, specified by pthread_cond_wait(). When no threads are blocked on the condition variable, pthread_cond_broadcast() has no effect. (For Solaris threads, see "cond_broadcast(3THR)".)
Return Values
pthread_cond_broadcast() returns zero after completing successfully. Any other return value indicates that an error occurred. When the following condition occurs, the function fails and returns the corresponding value.
cv points to an illegal address.
Condition Variable Broadcast Example
Since pthread_cond_broadcast() causes all threads blocked on the condition to contend again for the mutex lock, use it with care. For example, use pthread_cond_broadcast() to allow threads to contend for varying resource amounts when resources are freed, as shown in Example 4-10.
Example 4-10 Condition Variable Broadcast
Note that in add_resources() it does not matter whether resources is updated first or if pthread_cond_broadcast() is called first inside the mutex lock.
Call pthread_cond_broadcast() under the protection of the same mutex that is used with the condition variable being signaled. Otherwise, the condition variable could be signaled between the test of the associated condition and blocking in pthread_cond_wait(), which can cause an infinite wait.
Destroy Condition Variable State
pthread_cond_destroy(3THR)
Use pthread_cond_destroy(3THR) to destroy any state associated with the condition variable pointed to by cv. (For Solaris threads, see "cond_destroy(3THR)".)
Prototype: int pthread_cond_destroy(pthread_cond_t *cv); |
#include <pthread.h> pthread_cond_t cv; int ret; /* Condition variable is destroyed */ ret = pthread_cond_destroy(&cv); |
Note that the space for storing the condition variable is not freed.
Return Values
pthread_cond_destroy() returns zero after completing successfully. Any other return value indicates that an error occurred. When any of the following conditions occur, the function fails and returns the corresponding value.
The value specified by cv is invalid.
The Lost Wake-Up Problem
Calling pthread_cond_signal() or pthread_cond_broadcast() when the thread does not hold the mutex lock associated with the condition can lead to lost wake-up bugs.
A lost wake-up occurs when:
A thread calls pthread_cond_signal() or pthread_cond_broadcast().
And no threads are waiting.
The signal has no effect, and therefore is lost.
The Producer/Consumer Problem
This problem is one of the small collection of standard, well-known problems in concurrent programming: a finite-size buffer and two classes of threads, producers and consumers, put items into the buffer (producers) and take items out of the buffer (consumers).
A producer must wait until the buffer has space before it can put something in, and a consumer must wait until something is in the buffer before it can take something out.
A condition variable represents a queue of threads waiting for some condition to be signaled.
Example 4-11 has two such queues, one (less) for producers waiting for a slot in the buffer, and the other (more) for consumers waiting for a buffer slot containing information. The example also has a mutex, as the data structure describing the buffer must be accessed by only one thread at a time.
Example 4-11 The Producer/Consumer Problem and Condition Variables
typedef struct { char buf[BSIZE]; int occupied; int nextin; int nextout; pthread_mutex_t mutex; pthread_cond_t more; pthread_cond_t less; } buffer_t; buffer_t buffer; |
As Example 4-12 shows, the producer thread acquires the mutex protecting the buffer data structure and then makes certain that space is available for the item being produced. If not, it calls pthread_cond_wait(), which causes it to join the queue of threads waiting for the condition less, representing there is room in the buffer, to be signaled.
At the same time, as part of the call to pthread_cond_wait(), the thread releases its lock on the mutex. The waiting producer threads depend on consumer threads to signal when the condition is true (as shown in Example 4-12). When the condition is signaled, the first thread waiting on less is awakened. However, before the thread can return from pthread_cond_wait(), it must acquire the lock on the mutex again.
This ensures that it again has mutually exclusive access to the buffer data structure. The thread then must check that there really is room available in the buffer; if so, it puts its item into the next available slot.
At the same time, consumer threads might be waiting for items to appear in the buffer. These threads are waiting on the condition variable more. A producer thread, having just deposited something in the buffer, calls pthread_cond_signal() to wake up the next waiting consumer. (If there are no waiting consumers, this call has no effect.)
Finally, the producer thread unlocks the mutex, allowing other threads to operate on the buffer data structure.
Example 4-12 The Producer/Consumer Problem--the Producer