thread don't stop

[venAdder]

hi,

I ahve the follwing:

//system.h

class CSystem
{
...
static bool stopSim;
};

//system.cpp
bool CSystem::stopSim = false;

I start a new thread in a class with above variable as control variable as follows:

while( !CSystem::stopSim ){
...
}


FindClose( hFind );
dlg->m_btnSysStart.EnableWindow( TRUE );
dlg->m_btnSysStop.EnableWindow( FALSE );
CSystem::systemRunning = false;
return 0;

Now, when i exit app, i need to let this thread complete it's job and then exit gracefully so i do this
void CLaunchbar::OnBnClickedLbrexitapp()
{
// TODO: Add your control notification; handler code here
int ret = AfxMessageBox( "Are you sure you want to exit?", MB_YESNO );
if( ret == IDYES )
{

CSystem::stopSim = true;
//wait for the threads to exit
if( CSystem::systemRunning )
{
DWORD code = 0;
CMainFrame *parent = (CMainFrame*)this->GetParent( );
if( WaitForSingleObject(parent->m_dlgSys.m_handleSimThread,5000) == WAIT_TIMEOUT )
//dunno what's goign on here but ****er won't finish even when stop sim is set to true
TerminateThread( parent->m_dlgSys.m_handleSimThread, code );

}
theApp.Cleanup( );
AfxGetMainWnd()->PostMessage(WM_CLOSE);
}

}



now the problem is I set teh control variable to true and then wait for the thread to finish using WaitForSingle Object. But it always go to timeout( i tried infinite, it never finishes).

what am i doign wrong here?

[wildfrog]

First of all, please use code-tags when posting code.

//dunno what's goign on here but ****er won't finish even when stop sim is set to trueAre you sure the ****er isn't blocked by something, that it never checks the value of CSystem::stopSim?

Anyway, when using variables from multiple threads, to ensure that each thread reads the 'correct' value of stopSim, you should use the volatile keyword on your variable.

- petter

[kuphryn]

api spawned threads?

what inside while()?

Kuphryn

[Andreas Masur]

How to end a thread? (http://www.codeguru.com/forum/showthread.php?t=305166)

[MikeAThon]

what am i doign wrong here?
It's possible that what you're doing wrong is accessing the GUI from a thread. In general, it's bad to do that.

Inside the while loop, are you sending messages to the GUI? Remember, during the WaitForSingleObject call, your GUI thread is blocked and cannot process any messages. So, for example, if you are checking on whether a check box is checked, or if you are are doing any other manipulations of controls that involve messaging (most do, even though the MFC wrappers kinda hide that fact), then because the GUI thread is blocked it can't process any messages and the SendMessage call inside the thread's while loop will not return and the thread will be stuck.

Mike

[venAdder]

wow, that was right to the point.

I am nto exactly using a SendMessage call. I kinda pass a pointer to the dialog which displays information. Then using this pointer i do the drawing on the screen and add items to a couple of lsitboxes. So, what you are sayign makes sense.

That explains a lot of things.

Thankx, I'll think of a workable solution towards this. Since, I want the thread to finish processing the input which it already has recieved. This involves drawing etc. to GUI, which in turn controls the thread.

Thanx a lot for your input guys. This really cleared up a lot fo things.

[venAdder]

<quote>It's possible that what you're doing wrong is accessing the GUI from a thread. In general, it's bad to do that.
</quote>

Well I do wnat to display the results of the processing, which is realtime, and I can't think how I can do that without writing results to the GUI from a seperate thread.

[Andreas Masur]

Well...there isn't basically anything wrong with updating your GUI from a thread, however, you need to do some precautions. MFC is not thread-safe at object level (only at class level).

As long as the functions do not access the window handle (m_hWnd) you are fine. But many functions need to go back to the specific window handle and then will cause a debug assertion (access vialotion in release mode). The reason is that the window handle maps are kept in thread local storage to ensure protection from simultaneous access from multiple threads. So...there is the possibility for example that one thread might have a mapping from a handle to a C++ object, but another thread might map the same handle to a different one.

Thus you should pass the handle to the dialog and use user-defined messages to update controls etc. For further information take a look at this FAQ (http://www.codeguru.com/forum/showthread.php?t=312454)...

[MikeAThon]

Well I do wnat to display the results of the processing, which is realtime, and I can't think how I can do that without writing results to the GUI from a seperate thread.
Use PostMessage of a user-defined message to the main GUI thread. The message should be a signal to the main GUI thread that it should be the one that updates the listboxes.

As examples, see these:
"Sending Messages Across Threads" at http://www.flounder.com/messages.htm#Passing%20Pointers%20in%20Messages (read it carefully; it says not to SendMessage but rather use PostMessage)
"Using Worker Threads" at http://www.flounder.com/workerthreads.htm (read what he says about manipulating the UI from a thread)

Mike