How Do i detect end of thread

[asafaa]

I declared a thread in my class and executed it by AfxBeginThread();
now i wnat to know from the class that created the thread, if my thread is over , how do i do that ?

Does CWinThread has a parameter that can tell me if the thread is now operating or finished ?

[VictorN]

I declared a thread in my class and executed it by AfxBeginThread();
now i wnat to know from the class that created the thread, if my thread is over , how do i do that ?

Does CWinThread has a parameter that can tell me if the thread is now operating or finished ?
Ta a look at this J.Newcomer's article: Using Worker Threads (http://www.flounder.com/workerthreads.htm)

[Ajay Vijay]

Use WaitForSingleObject and pass the handle of created thread in it and specify INFINITE as wait period.

[asafaa]

thank you all for the help.
Ajay Vijay , i don't think this can help cause i want the application to continue running when the thread hasn't been finished yet, and not to stop and wait for it to finish.

VictorN , a very useful article! added it to my favorites, solved the problem perfectlly! :)

[chi_luci]

you may also create a flag, a event or post a message when the thread exits..

[Andreas Masur]

[ Moved thread ]

[NigelQ]

Ah, you didn't mention that your class should continue to operate while the worker thread is still going.

It sounds like what you really want is a way to test whether the thread is still running.

I agree with chi_luci that the simplest way to do this is to set a flag variable when the thread is finished.

If you want the politically correct, thread safe approach, you could use something like:

if(WaitForSingleObject(m_MyThreadHandle, 0) == WAIT_OBJECT_0)
{
// The thread has finished!!!
}

Note: This assumes that the thread does not have it's m_bAutoDelete flag set (otherwise the thread handle would no longer be a valid variable once the thread terminates). I guess.you could always catch the exception in this case, but it's not exactly 'nice' programming.

Anyway...

Hope this helps,

- Nigel

[Arjay]

Another way to do this is to use MsgWaitForMultipleObjects() in the main UI thread. Where WaitForSingleObject will cause the main thread to block while waiting for the secondary thread (causing the app to hang if the wait is performed in a UI thread), MWFMO allows the waiting thread to process messages during the waiting, so the UI remains responsive. Check out "Waiting in a Message Loop" in msdn for how to set the function up.

Arjay

[NigelQ]

Another way to do this is to use MsgWaitForMultipleObjects() in the main UI thread. Where WaitForSingleObject will cause the main thread to block while waiting for the secondary thread (causing the app to hang if the wait is performed in a UI thread), MWFMO allows the waiting thread to process messages during the waiting, so the UI remains responsive. Check out "Waiting in a Message Loop" in msdn for how to set the function up.

Arjay

Actually the code I posted will not block waiting for the worker thread to terminate. If you notice the wait period is set to 0, which means just check the state and move on.

The if statement will only be entered if the WaitForSingleObject immediately returns with WAIT_OBJECT_0 meaning that the object (our worker thread) has signalled.

This type of testing will not block or result in any performance hit on the calling routine, therefore WaitForMultipleObjects is not necessary in this situation.

Hope this helps,

- Nigel

[Arjay]

Actually the code I posted will not block waiting for the worker thread to terminate. If you notice the wait period is set to 0, which means just check the state and move on.

The if statement will only be entered if the WaitForSingleObject immediately returns with WAIT_OBJECT_0 meaning that the object (our worker thread) has signalled.

This type of testing will not block or result in any performance hit on the calling routine, therefore WaitForMultipleObjects is not necessary in this situation.

Hope this helps,

- Nigel
Nigel, I completely agree and didn't mean to imply that WaitForSingleObject (WFSO) would block as you are using it.

What I wanted to do was present an alternative to using WFSO in a UI thread. To often I see WFSO being used in a UI thread to actually wait for a thread or process. As we all know, this results in the UI thread freezing until the secondary thread or process goes away - not usually what the user intended. MsgWaitForMultipleObjects is one way to solve this problem.

BTW, another alternative to WFSO as a check is to use GetExitCodeThread() and check for STILL_ACTIVE.

Arjay