On Wed, May 22, 2013 at 5:21 AM, Bjorn Reese
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:
Yessir, this is not a half-bad thought actually, encapsulate the canceled, or more generically "state" of which one mode is the cancel request, could be others, like timeout, etc. HTH
class cancellation { // Use atomic<bool> virtual bool is_cancelled() const = 0; };
class worker { void run(cancellation& state) { while (!state.is_cancelled()) {
} } };
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users