Threads..
-
I wonder if anyone can advise me about the following. I am currently working on an application that uses multiple worker threads to perform concurrent processing. It requires 50+ workers (although it may require many more in the future), each instantiating an object to perform some processing. I am using ::WaitForMultipleObjects() to wait for all the threads to terminate. Now, some threads run very quickly as they do not have that much to do and so they tend to terminate even before the last worker thread has been dispatched. As a result, the wait fails.. Do I assume correctly, that this occurs because the wait function determines that those threads that are already signalled and therefore have invalid handles are considered an error. So, how do I contend with the fact that some threads may already be signalled before the wait gets called. I would like to be able to wait until all the threads have completed before execeution of the main dispatching thread continues whether they are non-signalled or signalled before the wait is called. Any comments or advice would be greatly appreciated. James.
-
I wonder if anyone can advise me about the following. I am currently working on an application that uses multiple worker threads to perform concurrent processing. It requires 50+ workers (although it may require many more in the future), each instantiating an object to perform some processing. I am using ::WaitForMultipleObjects() to wait for all the threads to terminate. Now, some threads run very quickly as they do not have that much to do and so they tend to terminate even before the last worker thread has been dispatched. As a result, the wait fails.. Do I assume correctly, that this occurs because the wait function determines that those threads that are already signalled and therefore have invalid handles are considered an error. So, how do I contend with the fact that some threads may already be signalled before the wait gets called. I would like to be able to wait until all the threads have completed before execeution of the main dispatching thread continues whether they are non-signalled or signalled before the wait is called. Any comments or advice would be greatly appreciated. James.
The thread objects are not deleted until all handles are closed. As long as you're keeping your handles open until you need to Wait, you'll be fine. The system keeps the object around so that you can wait on the object, should you need to. Be aware that a large number of threads will tend to cause context thrashing if they're contending for CPU time. Consider using a thread pool instead. See the
QueueUserWorkItemfunction for using the built-in thread pool on Windows 2000 or later. -
The thread objects are not deleted until all handles are closed. As long as you're keeping your handles open until you need to Wait, you'll be fine. The system keeps the object around so that you can wait on the object, should you need to. Be aware that a large number of threads will tend to cause context thrashing if they're contending for CPU time. Consider using a thread pool instead. See the
QueueUserWorkItemfunction for using the built-in thread pool on Windows 2000 or later.Hi. Thanks for the reply. The issue is not one of too many threads competing for a timeslice, as 99% of them are only active for a fraction of their lifetime. Infact they are only active when told to be via event handling. I have been looking through the archives and found an interesting discussion that I had not seen before concerning DuplicateHandle() or some such that I might be able to use to define a duplicate handle for each thread ensuring that the wait has valid handles to reference even if a child worker has already become signalled before the wait function is requested. Cheers. James
-
Hi. Thanks for the reply. The issue is not one of too many threads competing for a timeslice, as 99% of them are only active for a fraction of their lifetime. Infact they are only active when told to be via event handling. I have been looking through the archives and found an interesting discussion that I had not seen before concerning DuplicateHandle() or some such that I might be able to use to define a duplicate handle for each thread ensuring that the wait has valid handles to reference even if a child worker has already become signalled before the wait function is requested. Cheers. James
How do you mean the wait "fails"? As in tells you that you've given it an invalid handle? The thread handle should still be valid until it's closed with CloseHandle, and should be deemed "signaled" if they have terminated - providing you tell WaitForMultipleObjects to wait for all objects pased (3rd parameter) it should wait for all the threads to terminate - I have a similar snippit of code that kicks off 64 threads off different life spans and that works. Could you put up the code that starts and waits for the threads. Also, are you starting the threads with CreateThread() or _beginthread(ex)?
-
How do you mean the wait "fails"? As in tells you that you've given it an invalid handle? The thread handle should still be valid until it's closed with CloseHandle, and should be deemed "signaled" if they have terminated - providing you tell WaitForMultipleObjects to wait for all objects pased (3rd parameter) it should wait for all the threads to terminate - I have a similar snippit of code that kicks off 64 threads off different life spans and that works. Could you put up the code that starts and waits for the threads. Also, are you starting the threads with CreateThread() or _beginthread(ex)?
Hi. I am using AfxBeginThread(), which as I now understand, invalidates the handle once the thread terminates. So, I am going to look into DuplicateHandle() to try and circumvent the problem. Thanks for your reply. James.
-
Hi. I am using AfxBeginThread(), which as I now understand, invalidates the handle once the thread terminates. So, I am going to look into DuplicateHandle() to try and circumvent the problem. Thanks for your reply. James.
-
It does indeed - well MFC deletes the CWinThread has died. There is an easier way than DuplicateHandle - set m_bAutoDelete in you CWinThread after its been created - just make sure you create it in suspended state
Hi. Yeah, I have also just had a look at that. Thanks for your reply. Cheers.
-
Hi. Yeah, I have also just had a look at that. Thanks for your reply. Cheers.
Hi. Thanks for all the replies. Problem fixed, although I think that I might have to redesign the threads dispatch process when I need to use more than 64 threads, the current max defined on my system. Thanks to all your responses...
-
I wonder if anyone can advise me about the following. I am currently working on an application that uses multiple worker threads to perform concurrent processing. It requires 50+ workers (although it may require many more in the future), each instantiating an object to perform some processing. I am using ::WaitForMultipleObjects() to wait for all the threads to terminate. Now, some threads run very quickly as they do not have that much to do and so they tend to terminate even before the last worker thread has been dispatched. As a result, the wait fails.. Do I assume correctly, that this occurs because the wait function determines that those threads that are already signalled and therefore have invalid handles are considered an error. So, how do I contend with the fact that some threads may already be signalled before the wait gets called. I would like to be able to wait until all the threads have completed before execeution of the main dispatching thread continues whether they are non-signalled or signalled before the wait is called. Any comments or advice would be greatly appreciated. James.
you can set priority of ur thread so that they dont run so quickly using API SetThreadPriority() Abhishek Srivastava Software Engineer (VC++) India ,Noida Mobile no 9891492921 :)