Re: WaitForMultipleObjects: How to asynchronously wait?
On 11 Feb 2007 06:34:31 -0800, "Daneel" <michael.ransburg@gmail.com> wrote:
Hello!
I'm using WaitForMultipleObjects to wait for three threads to finish.
CWinThread* thread1 = AfxBeginThread(foo,NULL,THREAD_PRIORITY_NORMAL,
0,0,NULL);
CWinThread* thread2 = AfxBeginThread(bar,NULL,THREAD_PRIORITY_NORMAL,
0,0,NULL);
CWinThread* thread3 =
AfxBeginThread(foobar,NULL,THREAD_PRIORITY_NORMAL,0,0,NULL);
HANDLE h[] = {thread1->m_hThread,thread2->m_hThread,thread3-
m_hThread};
The default behavior of the MFC CWinThread class is to close the thread
handle and delete itself once the thread terminates. So your initialization
of the array has a race condition with threads that exit very quickly, and
to make matters worse, it is undefined to close a handle that is being
waited upon. One solution is to start the thread suspended and set the
m_bAutoDelete member to false before resuming; I talk more about this here:
http://members.cox.net/doug_web/threads.htm#Q1
I want to wait for all of them. However, as some thread might take
longer than the others, I want to get notified immediately if one of
the threads finishes in order to update the GUI:
for (i = 0; i < 3; i++) {
WaitForMultipleObjects(3, h, FALSE, INFINITE);
// do something
UpdateData(FALSE);
}
This implies your UI is non-responsive while the threads are running.
That's not good. It's better to selectively disable parts of the
application as necessary but at least maintain the ability for the user to
cancel the job the threads are working on or exit the program; during this
time, your program would display the "Working in Background" cursor. In
order to keep your UI responsive while still detected the thread
termination, you could write your own message loop using
MsgWaitForMultipleObjects as described in Q5 and Q6 here:
http://members.cox.net/doug_web/threads.htm#Q5
Alternatively, you could have the threads PostMessage a WM_APP-based
message to a window belonging to the UI thread to indicate they're
terminating. The UI thread still needs to join with the threads (i.e. wait
for their handles to be signaled). This is described in Q8.
The problem is that as soon as one of the threads is finished, the for
loop executes all three times without WaitForMultipleObjects waiting
for the remaining 2 threads.
Again, you're in a race with the auto-delete behavior, and since you're not
checking return codes, either:
1. The handle remains valid and WFMO returns immediately, because once
signaled, a thread handle remains signaled, or
2. The terminating thread has closed its handle, and WFMO is returning an
error code.
What am I doing wrong? Do I have to remove the handle for the thread
which is finished from the HANDLE array before calling
WaitForMultipleObjects again? How can I do that?
I'd use one of the two approaches described earlier. Presumably, these
three threads are related in some way, and I'd create a job class to manage
them.
--
Doug Harrison
Visual C++ MVP