C++ Threading #6: Condition Variable
Why Stack Overflow recommends it
Stack Overflow users cite it as a reference tutorial when asking about condition variable usage, such as notify placement and producer/consumer patterns.
Recommended by 0 people across 0 different months, 2014 to 2018.
What it is
A short 2013 tutorial from Bo Qian, part of his C++ threading series, on std::condition_variable and how it coordinates the execution order of threads. It uses a producer/consumer style example with mutexes and notify/wait calls.
What people said
Cites Nura · 2014-06 · Stack Overflow · on “why introducing sleep causes producer consumer to wait?”
I'm just learning to use the C++ threading library. If anyone is curious - my code is just a modified version in a tutorial [this video] I wrote a simple producer/consumer code. I tried to introduce a sleep to make the producer and consumer in lockstep fashion, so item is consumed as soon as it is produced. But making the producer waits causes some deadlock. I couldn't figure out why. Can you please help me point out what I'm missing in the code? #include <iostream> #include <thread> #include <mutex> #include <vector> #include <chrono> #define BUFFER_SIZE 10 std::mutex mu; std::condition_variable full,empty; std::vector<int> vec; int i=0; std::chrono::milliseconds slp(10); void produce() { while
Cites Amit G. · 2018-06 · Stack Overflow · on “why does std::condition_variable::wait need mutex?”
The reason is that in some times the waiting-thread holds the m_mutex : #include <mutex> #include <condition_variable> void CMyClass::MyFunc() { std::unique_lock<std::mutex> guard(m_mutex); // do something (on the protected resource) m_condiotion.wait(guard, [this]() {return !m_bSpuriousWake; }); // do something else (on the protected resource) guard.unluck(); // do something else than else } and a thread should never go to sleep while holding a m_mutex . One doesn't want to lock everybody out, while sleeping. So, atomically: { guard is unlocked and the thread go to sleep}. Once it waked up by the other-thread ( m_condiotion.notify_one() , let's say) guard is locked again, and then the threa
Cites Kari · 2018-09 · Stack Overflow · on “unlock the mutex after condition_variable::notify_all() or before?”
Looking at several videos [this video] and the documentation example [LINK] , we unlock the mutex before calling the notify_all() . Will it be better to instead call it after? The common way: Inside the Notifier thread: //prepare data for several worker-threads; //and now, awaken the threads: std::unique_lock<std::mutex> lock2(sharedMutex); _threadsCanAwaken = true; lock2.unlock(); _conditionVar.notify_all(); //awaken all the worker threads; //wait until all threads completed; //cleanup: _threadsCanAwaken = false; //prepare new batches once again, etc, etc Inside one of the worker threads: while(true){ // wait for the next batch: std::unique_lock<std::mutex> lock1(sharedMutex); _conditionVar.wait