Multithreaded c++11-ish queue fails on windows - c++

Question

I'm not that into multi-threading, so I appreciate any advice.
In my server which is written in producer-consumer multi-threaded style
queue is wrapped altogether with its mutex and cv:
template <typename Event>
struct EventsHandle {
public: // methods:
Event*
getEvent()
{
std::unique_lock<std::mutex> lock {mutex};
while (events.empty()) {
condition_variable.wait(lock);
}
return events.front();
};
void
setEvent(Event* event)
{
std::lock_guard<std::mutex> lock {mutex};
events.push(event);
condition_variable.notify_one();
};
void
pop()
{ events.pop(); };
private: // fields:
std::queue<Event*> events;
std::mutex mutex;
std::condition_variable condition_variable;
};
and here how it is used in the consumer thread:
void
Server::listenEvents()
{
while (true) {
processEvent(events_handle.getEvent());
events_handle.pop();
}
};
and in a producer:
parse input, whatever else
...
setEvent(new Event {ERASE_CLIENT, getSocket(), nullptr});
...
void
Client::setEvent(Event* event)
{
if (event) {
events_handle->setEvent(event);
}
};
The code works on linux and I don't know why, but fails on windows MSVC13.
At some point exception is thrown with this dialog:
"Unhandled exception at 0x59432564 (msvcp120d.dll) in Server.exe: 0xC0000005: Access violation reading location 0xCDCDCDE1".
Debugging shows that exception is thrown on this line: std::lock_guard<std::mutex> lock(mutex) in the setEvent() function.
Little googling led me to these articles:
http://www.justsoftwaresolutions.co.uk/threading/implementing-a-thread-safe-queue-using-condition-variables.html
http://www.codeproject.com/Articles/598695/Cplusplus-threads-locks-and-condition-variables
I tried to follow them, but with little help. So after this long text sheet my question:
what's wrong with the code, mutex?
UPDATE
So... Finally after lovely game named 'comment that line out' it turned out that the problem was in memory management. Event's dctor caused failure.
As conclusion, it's better to use std::unique_ptr<> as mentions Jarod42 or use value semantic as advises juanchopanza when passing objects back and forth.
And use libraries whenever possible, don't reinvent the wheel =)

Answer 1

You have a data race due to a missing mutex in EventsHandle::pop.
Your producer thread may push items to the queue by calling setEvent(), and get preempted while executing the line events.push(event). Now a consumer thread can execute events.pop() concurrently. You end up with two unsynchronized writes on the queue, which is undefined behavior.
Also note that if you have more than one consumer, you need to ensure that the element you pop is the same you retrieved earlier from getEvent. In case one consumer gets preempted by another between the two calls. This is very hard to achieve with two separate member functions which are synchronized by a mutex that is a member of the class. The usual approach here is to offer a single getEventAndPop() function instead, that keeps the lock throughout the operation and get rid of the separate functions you currently have. This might seem like an absurd restriction at first sight, but multithreaded code has to play by different rules.

Answer 2

You might also want to change the setEvent method to not notify while the mutex is still locked. It depends on the scheduler but the thread waiting to be notified might wake up immediately just to wait for the mutex.
void
setEvent(Event* event)
{
{
std::lock_guard<std::mutex> lock{mutex};
events.push(event);
}
condition_variable.notify_one();
};

Answer 3

In my opinion, pop should be integrated in the getEvent().
This will prevent more threads from getting the same event (if pop is not in getEvent then more threads could get the same one).
Event*
getEvent()
{
std::unique_lock<std::mutex> lock {mutex};
while (events.empty()) {
condition_variable.wait(lock);
}
Event* front = events.front();
events.pop();
return front;
};