multithreading problem

[Fred Cailleau-Lepetit]

Hi,

I also think that in that case, wxwPostEvent is the best method.

Fred Cailleau-Lepetit
Web : http://cfred.free.fr/

Iulian-Nicu Serbanoiu a écrit :
> This is a race condition because the variable is accessed without a
> lock ( mutex ) by two threads ( possibly in the same time ).
> 
> Wouldn't it be better in this case to send a custom event using 
> wxPostEvent ?
> 
> Using a while in a wxDialog could lead to responsiveness problems of the 
> GUI.
> 
> I would definetely go for wxPostEvent in this case because using a
> mutex/lock is ( in my opinion ) too much trouble.
> 
> HTH,
> 
> Iulian
> 
> On 9/22/06, Francesco Montorsi <f18m_cpp217828 at yahoo.it> wrote:
> 
>> Hi,
>>     probably this is something simple but I don't see it.
>>
>> I have a wxThread-derived class which represents a detached thread and a
>> wxDialog using it.
>>
>> In the wxDialog I've declared a
>>     bool m_bThreadExist;
>> flag which I init to true just before launching the thread, which is
>> passed (as a pointer obviously) to the thread and which is set to false
>> in the thread::OnExit function.
>>
>> Since I need for other reasons that the wxDialog is alive until the
>> thread has completed, I've overloaded the wxDialog::EndModal function 
>> to do:
>>
>>     wxDialog::EndModal(retCode);
>>
>>     // wait for thread to finish
>>     while (m_bThreadExist)
>>        ;
>>
>> This approach works but is not 100% reliable; i.e. sometimes after the
>> dialog is hidden by wxDialog::EndModal(), my app hangs and uses 100% of
>> the CPU in the while() loop.
>>
>> Since this happens about 50% of the times I run that code in release
>> builds of the app, I have troubles to find the bug.
>>
>> So, do you see some conceptual error with this approach ?
>>
>> Thanks a lot,
>> Francesco