WaitForSingleObject

john5632

Hi, I have a Dialog based application, to transfer a file I am using a thread (say T1). If I need to abort the T1 I need to press cancel button, for abort process I am using a memeber variable (bStopPushThread ) as a flag. If I set it ture it comes out of T1. But my application getting hang. Code on Abort button click is below:

if(g_hThreadHandlePush)
{
m_bStopPushThread = true;
//terminate push thread
WaitForSingleObject(g_hThreadHandlePush,INFINITE); //hang here
CloseHandle(g_hThreadHandlePush);
//g_hThreadHandlePush = NULL;
}

But It I dont use WaitForSingleObject(), it wirk fine, T1 treminates. I can check using debug.. If I use WaitForSingleObject as pointer come on this statement application hangs and I even cant check the T1. Please suggest me solition.

Cedric Moonen

Could you also post the code of the thread in which the m_bStopPushThread variable is accessed ?

Cédric Moonen Software developer
Charting control [v3.0] OpenGL game tutorial in C++

Code o mat

Are you completely sure g_hThreadHandlePush is the handle of the thread that checks the flag?

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<

Roger Stoltz

You probably have code looking like this in your thread:

while( !m_bStopPushThread )
{
// Do whatever the thread is supposed to do
}

Chances are that the m_bStopPushThread has been optimized into a register in your thread controlling loop which means that the thread won't see the value change. This happens if the variable is not written to inside the loop. Building a debug version disguises this behaviour since optimizations usually are turned off. The remedy is to declare the variable m_bStopPushThread as volatile, which will tell the compiler to read its value from the variables memory address every time and not to hold its value in a register.

"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown

Albert Holguin

This is exactly what I was thinking... +5

Code o mat

Thanks. :)

> The problem with computers is that they do what you tell them to do and not what you want them to do. < > If it doesn't matter, it's antimatter.<

Albert Holguin

If I had to guess, as someone already stated, g_hThreadHandlePush may not be the actual thread handle that you're expecting. To follow up on that, I hate to see people wait on something for an INFINITE time span. I know some disagree, but imagine if someone works on your code years later when you're not around and removes (for example) the m_bStopPushThread variable... they would end up with a freeze and it would be very hard to pinpoint where the freeze is occurring (debugging in multithreaded applications gets complex). I think you're better off setting a reasonable timeout, then alerting as to what occurred (using trace statements, message box, whatever).