[Boost-users] Re: Q: Stopping threads (Win32) or... the mysterious case of the thread with split personality

From: Dan Dimerman (dimerman_at_[hidden])
Date: 2004-12-05 14:07:52

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" <jeff.holle_at_[hidden]> wrote in message 
news:covlls$he0$1_at_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