In general you do not want any thread pooling some variable. A background thead almost always has to pend, that is wait suspended, in a useful multi-threaded application. The trick is finding the way to pend on multiple events. Any decent threading library will provide a way. Dan Dimerman wrote:
Hello Jeffrey and thank you for your response,
As you point out, and is my general understanding, the thread indeed does kills itself by exiting its main loop. My question pointed more towards what you call "legit inter-thread" communication: I thought a shared variable would be enough, given there is only one state transition (true to false), just two threads and one is consistently the writer and the other consistently the reader. What I see (debugger) is that from inside one thread (main) the value of this variable is false, and from the other thread (worker) the value is different !
"Jeffrey Holle"
wrote in message news:covlls$he0$1@sea.gmane.org... First, a thread should kill itself. Second, you should use legit inter-thread communication. The request to commit suicide should be one of the things the thread pends on. Don't know boost.threads, but thats the general correct way to write a multi-threaded application.
Dan Dimerman wrote:
Hello,
I would like to ask the group if you know of an efficient and clean way to stop a thread. What I've been using till now was a while loop in the function operator()() given to the boost::thread when created, whose condition was a boolean data member. This boolean was the means to stop the thread, such that when it was turned off, the child thread would exit the while loop and join the main thread. I am seeing now that this data member is being held twice (one copy for the main thread and one copy for the child thread) and there's no synch between the two copies; so when the main thread turns it off / false, the child thread goes on (since its copy is still on / true) and hell breaks loose.
I am using VC7 in debug mode, so I started looking for some kind of flag/optimization I might be inadvertently using that makes data members into registers (thus explaining the copies), but couldn't find anything of the sort.
Any help will be greatly appreciated...
Dan
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.805 / Virus Database: 547 - Release Date: 03-Dec-04
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.805 / Virus Database: 547 - Release Date: 03-Dec-04