1.WaitForSingleObject
The wait function allows a thread to voluntarily enter a wait state until a particular kernel object becomes a notified state. The most common of these wait functions is Waitforsingleobject: dword WaitForSingleObject (HANDLE hobject, DWORD dwmilliseconds); When a thread calls the function, the first parameter, Hobject, identifies a kernel object that can support notification/not notification. The second parameter, dwmilliseconds. Allows the thread to indicate how long it will wait in order to wait for the object to become a notified state. Call the following function to tell the system that the calling function is ready to wait until the process identified by the hprocess handle terminates running: WaitForSingleObject (hprocess, INFINITE), and the second parameter tells the system, The calling thread is willing to wait forever (infinite amount of time) until the process terminates. Typically, infinite is passed as the second argument to WaitForSingleObject, but it can also pass any value (in milliseconds). By the way, infinite has been defined as 0xFFFFFFFF (or-1). Of course, passing infinite is a bit dangerous. If the object never becomes a notified state, then the calling thread will never wake up, and it'll always be in a deadlock state, but it will not waste valuable CPU time. Here's an example of how to call WaitForSingleObject with a time-out value instead of infinite: DWORD DW = WaitForSingleObject (hprocess, { ), switch (DW) case wait_object_0: //The process terminated. break; case wait_timeout: //The process did Not terminate within Milliseconds. break; case WAIT_failed: //bad call to function (invalid handle?) break;} The above code tells the system that the calling thread should not become a scheduled state until a particular process terminates, or until the end of the 5 0 0 0 M s time. Therefore, if the process terminates, the function call will return in less than 5000ms of time, and if the process has not been terminated, it returns within approximately 5000ms time. Note that you cannot pass 0 for dwmilliseconds. If the 0,waitforsingleobject function is passed, it will always return immediately.
2.WaitForMultipleObjects
The return value of WaitForSingleObject can indicate why the calling thread has become a scheduled state again. If the thread waits for the object to become a notified state, the return value is WAIT_OBJECT_0. If the timeout set has expired, the return value is wait_timeout. If you pass an incorrect value (such as an invalid handle) to WaitForSingleObject, the return value will be wait_failed (to learn more, call GetLastError). The following function, WaitForMultipleObjects, is similar to the WaitForSingleObject function, except that it allows the calling thread to simultaneously view the notified state of several kernel objects: DWORD waitformultipleobjects (DWORD dwcount, const handle* phobjects, bool Fwaitall, dword dwmilliseconds);d The Wcount parameter is used to indicate the number of kernel objects that you want the function to view. This value must be between 1 and maximum_wait_objects (defined as 64 in the Windows header file). The phobjects parameter is a pointer to an array of kernel object handles. You can use the WaitForMultipleObjects function in two different ways. One way is to have the thread go into a wait state until any one of the specified kernel objects becomes a notified state. Another way is to get the thread to wait until all the specified kernel objects become notified. The fWaitAll parameter tells the function how you want it to be used. If true is passed for this parameter, the function will not allow the calling thread to run until all the objects become notified states. The function of the dwmilliseconds parameter is exactly the same as it does in WaitForSingleObject. If the specified time is reached while waiting, the function will return anyway. Again, it is common to pass infinite for this parameter, but you should be careful when writing code to avoid deadlock situations. The return value of the WaitForMultipleObjects function tells the calling thread why it is being re-dispatched. The possible return values are wait_failed and wait_timeout, and the effect of these two values is clear. The return value is WAIT_OBJECT_0 if the fWaitAll parameter passes TRUE and all objects become notification states. IfPass false for fWaitAll, and the function returns once any object becomes a notified state. In this case, you may want to know which object becomes the notification state. The return value is a value between Wait_object_0 and (Wait_object_0 + dwcount-1). In other words, if the return value is not wait_timeout and not wait_failed, then the WAIT_OBJECT_0 should be subtracted from the return value. The resulting number is the index in the array of handles passed to WaitForMultipleObjects as the second argument. The index indicates which object has changed to the notified state. Here are some sample code to illustrate the situation: HANDLE h[3];h[0] = hprocess1;h[1] = hprocess2;h[2] = Hprocess3;dword DW = WaitForMultipleObjects (3, H, FA LSE, (DW) { case wait_failed: //bad call to function (Invalid handle?) break; case wait_timeout: //None of the objects became signaled within Nbsp; case WAIT_OBJECT_0 + 0: //The process identified by H[0] (HPROCESS1) Terminated. break; case WAIT_OBJECT_0 + 1: //the ProceSS identified by H[1] (HPROCESS2) terminated. break; case WAIT_ OBJECT_0 + 2: //The process identified by h[2] (HPROCESS3) terminated. & Nbsp; break;} If you pass false,waitformultipleobjects for the fWaitAll parameter, the handle array is scanned starting at index 0, and the first object notified terminates the wait state. This may produce some results that you do not want. For example, by passing 3 process handles to the function, your thread waits for 3 child processes to terminate. If a process with index 0 in the array is terminated, WaitForMultipleObjects will return. At this point the thread can do whatever it needs, and then loop back and forth, waiting for the other process to terminate. If the thread passes the same 3 handles, the function returns WAIT_OBJECT_0 again immediately. The code does not run correctly unless you delete a handle that has been notified.
WaitForSingleObject and WaitForMultipleObjects functions
