debugging multithreaded app

  • Thread starter Thread starter Bruno van Dooren
  • Start date Start date
B

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(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.
 
Bruno van Dooren said:
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?
Click to expand...

<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
 
Bruno van Dooren said:
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);
Click to expand...
[...]

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.
 
William DePalo said:
<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
Click to expand...

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.
 
Tim Robinson said:
Bruno van Dooren said:
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);
Click to expand...
[...]

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.
Click to expand...

Thanks. i didn't know.
Bruno.
 
Back
Top