A condition variable synchronizes threads that share a resource but must wait for that resource to reach a usable state. It works with a mutex: the waiting thread releases the mutex while suspended, then reacquires it before checking the condition again. section 16.3 section 16.5
Use the condition-variable pattern as a wait–check–act cycle:
- Lock the shared resource with a unique_lock associated with its mutex. section 16.3.1
- Wait in a while loop while the required condition remains true, such as a full queue for a producer or an empty queue for a consumer. section 16.3.1 section 16.3
- After notification, reacquire the mutex and recheck the condition; proceed only when it is false. section 16.3.1
- Notify waiting threads after changing the shared state so their condition may have become false. section 16.3
Bounded producer–consumer queue
A shared queue uses one mutex and two condition variables. Producers wait on producer_cv while the queue is full; consumers wait on consumer_cv while it is empty. When a producer inserts the first item, it notifies consumers. When a consumer removes an item from a full queue, it notifies producers. Consumers also stop waiting when the queue is empty and no producers remain active. section 16.3 section 16.3.2
Figure 16.9 The producer and consumer threads each creates a local unique lock object queue_lock from queue_mutex to guard its critical region. The two condition variables, producer_cv and consumer_cv, work together to synchronize the producer and consumer threads. The producer threads loop to enter values into the shared queue, and the consumer threads loop to remove values from the shared queue. A producer thread cannot enter a value into the queue when the queue is full. A consumer thread cannot remove a value from an empty queue.
The synchronization flow shows how the shared mutex, unique locks, producer_cv, and consumer_cv coordinate queue access. section 16.3.1
Condition variables prevent threads from repeatedly polling a shared condition, but they do not remove synchronization risks. Timing can produce irreproducible behavior, deadlocks can hang the application, and extra threads and context switches can reduce performance. section 16.4
