Click here to Skip to main content
15,887,383 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
what should be done if we want to use more than 64 wait objects???
Posted

In addition to what Edlin says:

Use with extra care. There is no way to get exact same effect as without sequential grouping. It may cause pathological situations such as deadlocks. Consider you have two groups: wait for one array first, that for a second one. What happen if you wait for all objects, and one of the threads in first group waits for one object from a second group? A deadlock which would not happen if you could wait for all object in one call.

In real life, waiting for more then 64 objects would be a sign of some kind of wrong design. I saw (and answered) to your first question; your code looked very artificial. It looks like you're only doing some research, am I right?

—SA
 
Share this answer
 
Comments
Albert Holguin 1-Jun-11 10:16am    
As usual... good answer! 5
Sergey Alexandrovich Kryukov 1-Jun-11 12:57pm    
Thank you very much, Albert.
--SA
SA is right about there being differences in waiting for all the objects versus waiting for multiple subsets to get more than 64. The issues is not so much related to the example at hand but is a more important to understand.

The issue at hand has to do with Thread Objects, which are only signaled when the thread exits so there's no possibility of deadlocks in this example. However, when used for synchronization, the definition of "WaitForMultipleObjects" is that when the wait is satisfied, you are guaranteed that all the objects were available and you successfully "locked" them all at once. If WaitForMultipleObjects cannot obtain all the objects at the same time, it does not change the state of the individual objects as that would lead to deadlocks. And while that guarantee can be made for each subset, it does not apply to the sum of the subsets (the total set) of objects.

In the case where you are waiting for all threads to finish, there is no difference between waiting for all the objects at once or waiting for each thread one at a time in a loop (other than the actual limit to the number of objects).
<pre lang="cs">void thread_wait_for_all()
{
    for (int i=0; i<True_Maximum_Simultaneous_Threads; i++)
    {
        if (ThreadArray[i] != NULL)
        {
            WaitForSingleObject(ThreadArray[i], INFINITE);
            CloseHandle(ThreadArray[i]);
            ThreadArray[i] = NULL;
        }
    }
}

 
Share this answer
 
Comments
Albert Holguin 1-Jun-11 10:19am    
I would tend to somewhat agree, but we definitely need to get out of the habbit of putting INFINITE waits even when you're just using pseudo-code... that's a horrible practice
Chuck O'Toole 1-Jun-11 10:42am    
That's not pseudo code, it's pasted right out of my application. It's an interactive application that waiting for some parallel processing to finish. I have no idea how long the activity will take, I have no idea what corrective action to take if the thread doesn't finish in a set amount of time. In this instance, and many others, "INFINITE" is a perfectly reasonable timeout setting.
Albert Holguin 1-Jun-11 11:04am    
INFINITE is never a reasonable timeout setting, only if you want future developers in your app to deal with your bugs
Chuck O'Toole 1-Jun-11 11:11am    
Then let us simply agree to disagree. After 45 years of being a software engineer, I've learned that many things are reasonable.
Albert Holguin 1-Jun-11 11:12am    
Agreeing to disagree is agreeable :)
You can use IOCP and for the best article for IOCP click here .
 
Share this answer
 
First wait for first 64 objects, then wait for next 64 objects, etc.
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 1-Jun-11 3:31am    
Your answer is correct, my 5. You should have noted that the effect of it is not quite equivalent to a wait in one call. I explain it in my answer.
Please see.
--SA
Albert Holguin 1-Jun-11 10:17am    
I agree with SA, this can lead to potential problems if not done correctly

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900