Re: [Boost-users] [thread] "almost works" clarification

Subject: Re: [Boost-users] [thread] "almost works" clarification
From: Gaetano Mendola (mendola_at_[hidden])
Date: 2013-05-25 08:34:13

On 21/05/2013 23.58, Michael Powell wrote:
> Hello,
>
> Okay, so without starting a flame war, because that is not my
> intention... Also bear in mind, I am coming from an informed C# .NET
> frame of mind having worked with .NET threading, synchronization,
> events, and so forth.
>
> 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.
>
> Nothing against the author, I might turn that around and couch it
> instead: boost-thread-almost-works: in the sense that, while there are
> indeed a rich set of primitives provided to hide the details of
> pthread, Win32 threading, or what have you, it stops just short of
> providing that abstraction layer for what Peter and I (probably just
> he and I) consider a robust runner, monitor, and worker. The
> ingredients are there, though, and with a little bit of persuading,
> can compose a fairly robust little set of threaded runners.
>
> Okay, with that said, am I correct in understanding, the combination
> of condition and mutex facilitates the analog to C# .NET
> AutoResetEvent or ManualResetEvent (loosely, ResetEvent) type thing?
> In other words, thread keeps-on-a-runnin' until condition is notified,
> at which point thread loop(s) know to stop working when they check in
> with their conditioned mutex?
>
> In other words, mechanically speaking, a worker-bee that starts
> obtains a lock on the mutex. While the worker is running, on-lookers
> may poll the monitor for thread completion (which times out as long as
> the worker-bee is running and has a scoped lock), or otherwise signal
> the thread to complete through the notify mechanism (which tells the
> worker-bee to return, which clears the lock). The worker-bee runs
> until it is completed or its conditioned mutex has been notified
> (whichever comes first).
>
> In another rendition, I was actually using the thread-interruption
> mechanism, which I may still do, is another way of signaling a thread
> that it should stop what it's doing. However, seems a bit less
> graceful than routing requests through a formalized abstraction layer
> I think, except through creative use of interrupt disabled (which I
> was also using), but is something else to consider.
>
> Anywho, food for thought. Comments, critiques welcome. Thank you...
>
> Regards,
>
> Michael Powell

If you are trying to say that boost::thread is too low level for you,
we can talk about it. If you say instead that bogus Monitor
implementation is something to adopt or even use then you are totally
wrong.
Let's ignore the fact that the article is a tad dated.

Having a Thread polling to check if he has to terminate his main loop
it's a totaly waste, that's why basically people needs hardware
more more and more powerful, because they just waste it.

Instead of a solution (bugged) please explain what you are not able
to achieve with the current boost thread.

Also the Author is assuming that boost::thread is there to totally
simplify the usage of pthread. boost::thread is there to permit you
to write platform independent multi threaded code.

Regards
Gaetano Mendola