debugging multithreaded app

[Bruno van Dooren]

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(GetExitCo deThread() == 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.

[William DePalo [MVP VC++]]

"Bruno van Dooren" <mi******@hotma il.com> wrote in message
news:eW******** ******@TK2MSFTN GP15.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(GetExitCo deThread() == 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

[Tim Robinson]

"Bruno van Dooren" <mi******@hotma il.com> wrote in message
news:eW******** ******@TK2MSFTN GP15.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(GetExitCo deThread() == 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;
WaitForSingleOb ject(m_ThreadHa ndle, INFINITE);

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

--
Tim Robinson
MVP, Windows SDK

[Bruno van Dooren]

"William DePalo [MVP VC++]" <wi***********@ mvps.org> wrote in message
news:%2******** *******@tk2msft ngp13.phx.gbl.. .

"Bruno van Dooren" <mi******@hotma il.com> wrote in message
news:eW******** ******@TK2MSFTN GP15.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(GetExitCo deThread() == 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.

[Bruno van Dooren]

"Tim Robinson" <ti************ *************@n owhere.com> wrote in message
news:39******** *****@individua l.net...

"Bruno van Dooren" <mi******@hotma il.com> wrote in message
news:eW******** ******@TK2MSFTN GP15.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(GetExitCo deThread() == 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;
WaitForSingleOb ject(m_ThreadHa ndle, INFINITE);

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

--
Tim Robinson
MVP, Windows SDK

Thanks. i didn't know.
Bruno.