Re: debugging multithreaded app
From: Bruno van Dooren (microvax_at_hotmail.com)
Date: 03/18/05
- Next message: Bruno van Dooren: "Re: debugging multithreaded app"
- Previous message: wayne: "list box"
- In reply to: William DePalo [MVP VC++]: "Re: debugging multithreaded app"
- Next in thread: Tim Robinson: "Re: debugging multithreaded app"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 18 Mar 2005 09:14:51 +0100
"William DePalo [MVP VC++]" <willd.no.spam@mvps.org> wrote in message
news:%231EjyPmKFHA.904@tk2msftngp13.phx.gbl...
> "Bruno van Dooren" <microvax@hotmail.com> wrote in message
> news:eW6ZXylKFHA.1176@TK2MSFTNGP15.phx.gbl...
>> i was debugging a multithreaded app, when i stumbled across some weird
>> behavior of the debugger.
>>
>> in the destructor of my main object i send a stop event to the worker
>> thread, and then wait until that thread has finished.
>>
>> m_Stop = true;
>> while(GetExitCodeThread() == STILL_RUNNING)
>> Sleep(50);
>>
>> the strange thing is that if i break just before the m_Stop = true, and
>> then step through the while loop, the exit code is STILL_RUNNING forever.
>> i can step forever without the thread ever ending.
>> if a break just after the while loop, the thread has stopped without a
>> problem.
>>
>> is this normal behavior?
>
> <guess mode on>
> Could it be related to the fact that the debugger suspends _all_ threads
> on encountering the breakpoint? Not having seen the source, I don't know
> how it resumes them after the breakpoint is hit, but if it does it in a
> "lazy" way in which the debugged thread is resumed first while the
> background threads are resumed after the fact and if that resumption takes
> more than 50ms then it may be that the other thread never runs.
> </guess mode on>
>
> What does the other thread do? Is it guaranteed to stop after you set
> m_stop? If so, why use the hokey (IMO, YMMV) busy loop?
>
> Regards,
> Will
>
The reason for the while loop is that after the threads are stopped, a lot
of shared resources like notifiers and shared memory are cleaned up.
if i should not wait for the threads to finish, there is a race condition
between the functionality in the threads, and the cleanup code.
ps i just noticed that my code looked like
while(..)
;
without sleep. as a result there was probably not enough time for the
threads to resume.
still, i would have thought that it would only break the thread in which the
breakpoint was encountered.
thanks.
Bruno.
- Next message: Bruno van Dooren: "Re: debugging multithreaded app"
- Previous message: wayne: "list box"
- In reply to: William DePalo [MVP VC++]: "Re: debugging multithreaded app"
- Next in thread: Tim Robinson: "Re: debugging multithreaded app"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|