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