debugging multithreaded app

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Bruno van Dooren - 16 Mar 2005 20:15 GMT

Hi,

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?

kind regards,
Bruno.

Reply to this Message

William DePalo [MVP VC++] - 16 Mar 2005 21:08 GMT

> i was debugging a multithreaded app, when i stumbled across some weird
> behavior of the debugger.
[quoted text clipped - 13 lines]
>
> 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

Reply to this Message

Bruno van Dooren - 18 Mar 2005 09:14 GMT

>> i was debugging a multithreaded app, when i stumbled across some weird
>> behavior of the debugger.
[quoted text clipped - 28 lines]
> 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.

Reply to this Message

Tim Robinson - 16 Mar 2005 22:38 GMT

> i was debugging a multithreaded app, when i stumbled across some weird
> behavior of the debugger.
[quoted text clipped - 5 lines]
> while(GetExitCodeThread() == STILL_RUNNING)
> Sleep(50);

[...]

I can't claim any insight into your problem, but this is the traditional way
to wait for a thread to exit:

m_Stop = true;
WaitForSingleObject(m_ThreadHandle, INFINITE);

There's no need to poll, as the original code does.

Signature

Tim Robinson
MVP, Windows SDK

Reply to this Message

Bruno van Dooren - 18 Mar 2005 09:15 GMT

>> i was debugging a multithreaded app, when i stumbled across some weird
>> behavior of the debugger.
[quoted text clipped - 14 lines]
>
> There's no need to poll, as the original code does.

Thanks. i didn't know.
Bruno.

Reply to this Message

debugging multithreaded app

Free Magazines