C++11: Publisher/Consumer pattern does not finish unless publisher sleeps - c++

Question

In C++, I am trying to get a handle for the publisher/consumer pattern using a condition_variable. This is loosely the template I have seen online:
#include <iostream>
#include <thread>
#include <string>
#include <mutex>
#include <queue>
#include <condition_variable>
#include <chrono>
using namespace std;
mutex m;
queue<string> que;
condition_variable cond;
void write(string &&msg) {
unique_lock<mutex> locker(m);
que.push(msg);
locker.unlock();
cond.notify_one();
this_thread::sleep_for(chrono::milliseconds(1));
}
void read() {
while (true) {
unique_lock<mutex> locker(m);
cond.wait(locker);
if (!que.empty()) {
cout << que.front() << endl;
que.pop();
}
locker.unlock();
}
}
void publisher(string &msg) {
for (int i = 0; i < 100; ++i)
write("Publisher: " + msg + ", " + to_string(i));
}
int main() {
string msg = "Hello";
thread pub_thread(publisher, std::ref(msg));
/* The main thread will print the publisher's messages to cout. */
read();
/* Make the main thread wait for the publisher to finish. */
pub_thread.join(); //
return 0;
}
The thing I do not understand is the sleep_for call on the publisher thread. I understand that this is there simply to simulate a "real life" scenario in which the publisher will not be spitting out messages so fast. However, curiously, if I comment out that line, the code does not run to completion. Why is that?
Furthermore, I tried setting the sleep_for time to 0 with the same effect. It seems that the published fundamentally needs to sleep, but I do not understand why. To get more specific, the code should print out 100 messages. If I let the code sleep for 1 ms, then all 100 messages are printed. If I do not, then I only see about 10 messages before the code freezes. It seems like there is a deadlock occurring.
Bonus points if there is a better pattern which avoids having to put the publisher to sleep...
I am aware that in practice you need to have a strategy for stopping the main thread, like a poison pill. I have intentionally omitted this to focus on the present discussion.
EDIT
Hmmm. If I put in a block to handle spurious wakeup, then that fixes the problem. But that still does not explain why the original code failed.
Here is an improved read function:
void read() {
while (true) {
unique_lock<mutex> locker(m);
cond.wait(locker, [&](){ return !que.empty(); });
cout << que.front() << endl;
que.pop();
locker.unlock();
}
}

Answer 1

You need to handle the situation when the publisher is publishing faster than the consumer consuming.
When that happens, the consumer will miss condition_variable triggers. Remember that notify calls do not accumulate.
Change the consumer to consume all available messages once it wakes up:
if (!que.empty()) → while (!que.empty())
Like this:
void read() {
while (true) {
unique_lock<mutex> locker(m);
cond.wait(locker);
while (!que.empty()) {
cout << que.front() << endl;
que.pop();
}
locker.unlock();
}
}

Answer 2

You have two problems: one is that the publisher is under no obligation to yield to the reader - or to pause long enough for the reader to successfully get lock the mutex - unless you make it.
The second is that your reader is anyway incorrect:
void read() {
while (true) {
unique_lock<mutex> locker(m);
cond.wait(locker);
if (!que.empty()) {
cout << que.front() << endl;
que.pop();
}
}
}
This assumes you get one "wakeup event" per element pushed onto the queue, because it consumes exactly one element per wakeup. But that's not how condition variables work.
It's entirely possible for this sequence to happen:
publisher adds item 1
publisher signals condvar
publisher adds item 2
publisher signals condvar
reader wakes from condvar wait
reader consumes item 1
In this case the publisher will add 100 items, and signal 100 times, but the reader will only wake 99 times and therefore consume at most 99 items.
The correct code should be something like this:
void read() {
unique_lock<mutex> locker(m);
while (true) {
// don't wait if we don't have to
while (que.empty()) {
cond.wait(locker);
}
// consume everything we can
while (!que.empty()) {
cout << que.front() << endl;
que.pop();
}
}
}
Using the predicate achieves roughly the same thing (I just wrote all the logic out explicitly for clarity) - the second while isn't there in your edit, but looping round and skipping the first while is a slightly more expensive way to get the same behaviour.
Also, there's no need to thrash the mutex on every iteration - the condition variable already (un)locks it as required.