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
Le 21/05/13 23:58, Michael Powell a écrit : 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