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