Why the program get deadlocked if I comment the "while" block? How does the "yield" line in it effect?

Question

I'm learning condition_variable and running some examples. I'm curious that why the following code get deadlock if I comment the block. It's a simple consumer and producer example using condition_variable. I think it's a deadlock problem, isn't it?

#include <iostream>
#include <thread>
#include <mutex>
#include <condition_variable>

using namespace std;

mutex mtx;
condition_variable cv;

int cargo = 0;

bool shipment_available()
{
    return cargo != 0;
}

void consume(int cnt)
{
    for (int i = 0; i < cnt; i++)
    {
        unique_lock<mutex> lck(mtx);
        cv.wait(lck, shipment_available);
        printf("%d\n", cargo);
        cargo = 0;
    }
}

int main()
{
    thread consumer_thread(consume, 10);

    for (int i = 0; i < 10; i++)
    {
        //while (shipment_available())    // Dead lock without this block
        //{
        //    std::this_thread::yield();
        //}
        unique_lock<mutex> lck(mtx);
        cargo = i + 1;
        cv.notify_one();
    }

    consumer_thread.join();
}

It runs well if I uncomment the block.

Answer 1

So walk through this highly likely possibility:

1. main() starts up the consumer thread.
2. Before the thread can acquire the mutex, main() locks it, increments cargo, and fires the notification, then releases the mutex by scope-rotation ten times.
3. main() now runs down to join the consumer thread.
4. Consumer finally acquires the mutex, and prepares to wait on the condition variable for the given predicate (non-zero cargo).
5. The predicate is already true, so no wait is performed.
6. The consumer zeros the cargo, then releases the mutex by scope-rotation.
7. The consumer loops for the second time, locks the mutex, then checks the predicate, only now the predicate is false because cargo is indeed zero, so it waits on the condition variable (releasing the mutex in the process) for a signal that will never come. The only thing that ever sent that signal is main(), and it is just camped out waiting for the consumer thread to join up, which can now never happen.

In short, you seem to be of the belief that condition variables signals stack up. That simply isn't the case. if no one is actively waiting on a notification at the time it is posted, it is simply lost to the ether.

Finally, and this is important, your "fix" is completely wrong in itself. The shipment_available function examines predicate data (i.e. data that must be protected by the mutex enshrouding it, not only for modification, but likewise for examination). Checking that without the mutex locked in main is a recipe for a race condition.

My suggestion is to reduce cargo by one rather than zeroing it out. Alternatively you could increment i by the value of cargo before zeroing it, thereby hastening i's ascent to the cnt limit, but you appear to be using an ascending cargo amount, so you'll have to make other adjustments accordingly.