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

Subject: Re: [Boost-users] [thread] "almost works" clarification
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-05-21 18:23:05

Le 21/05/13 23:58, Michael Powell a écrit :
> Hello,
Hi,
> 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.
This is a really old blog. From my quick reading it show how powerful 
the Boost.Thread design is. The user can create its own abstraction very 
easily.
>
> 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.
>
I'm not sure to understand what your want. Please don't  give solutions, 
just tell us what you want to achieve.

Best,
Vicente