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

Subject: [Boost-users] [thread] "almost works" clarification
From: Michael Powell (mwpowellhtx_at_[hidden])
Date: 2013-05-21 17:58:41

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