On 05/21/2013 11:58 PM, Michael Powell wrote:
I ran across this article, which although a bit dated, is a pretty good sketch of what I would consider a fairly robust thread runner abstraction, which if you read past the frustration, makes good sense, at least in my opinion: http://peter.bourgon.org/blog/2008/12/12/boost-thread-kindof-sucks.html.
The worker in this blog has a synchronization error. If stop() is called before run() -- this could happen due to thread scheduling -- then it will not stop. If you can live without the notify_all() in stop(), then a better solution is to pass a cancellation callback as an argument to run(), and check this instead of checking m_running. Something like this: class cancellation { // Use atomic<bool> virtual bool is_cancelled() const = 0; }; class worker { void run(cancellation& state) { while (!state.is_cancelled()) { } } };