ThreadPool. Any way to know when all threads finished?
-
I'd like to know if there is any mechanism to know where the threads that ThreadPool object manages, are finished. The idea is having a loop that calls the ThreadPool to execute some method, and then block that main thread until all threads are finished. Is that possible?
Regards, Diego F.
-
I'd like to know if there is any mechanism to know where the threads that ThreadPool object manages, are finished. The idea is having a loop that calls the ThreadPool to execute some method, and then block that main thread until all threads are finished. Is that possible?
Regards, Diego F.
Diego F. wrote:
The idea is having a loop that calls the ThreadPool to execute some method, and then block that main thread until all threads are finished.
Then why would you even use threading at all?? The whole point behind threading is to move work to a seperate thread so your primary thread can continue to respond to requests. The thread pool doesn't raise any events when a thread is complete. Your threaded code has to supply that, or some other method to signal completion.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007 -
I'd like to know if there is any mechanism to know where the threads that ThreadPool object manages, are finished. The idea is having a loop that calls the ThreadPool to execute some method, and then block that main thread until all threads are finished. Is that possible?
Regards, Diego F.
Hi, AFAIK there is no built-in mechanism for this. I see at least three possibilities: 1. You could try to count yourself; use Interlocked.Increment each time you send a piece of work to a thread, and have it call Interlocked.Decrement when it is done. Then have your main thread do a busy wait (with Sleep!) on the same counter. disadvantages: - if a thread exits abnormally (or forgets to decrement) your main thread will hang forever. - the wait loop is not nice. 2. Since .NET 2.0 there is BackgroundWorker class, which supports cancellation and offers events. You could use its IsBusy property and/or its ProgressChanged event. 3. And of course you could use regular threads, keep them in a list, and periodically check their status. (Dont forget to clear the list when you conclude all has been done; so the threads get garbage collected). :)
Luc Pattyn [My Articles] [Forum Guidelines]
-
Diego F. wrote:
The idea is having a loop that calls the ThreadPool to execute some method, and then block that main thread until all threads are finished.
Then why would you even use threading at all?? The whole point behind threading is to move work to a seperate thread so your primary thread can continue to respond to requests. The thread pool doesn't raise any events when a thread is complete. Your threaded code has to supply that, or some other method to signal completion.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007Well, in my case, I don't mind to block the main thread. The help of ThreadPool is that I need to run a method many times (let's say hundreds), and if I can run it separately, I would think that it saves time. Am I wrong? Other way, you are rigth. It has no sense the use of threading.
Regards, Diego F.
-
Hi, AFAIK there is no built-in mechanism for this. I see at least three possibilities: 1. You could try to count yourself; use Interlocked.Increment each time you send a piece of work to a thread, and have it call Interlocked.Decrement when it is done. Then have your main thread do a busy wait (with Sleep!) on the same counter. disadvantages: - if a thread exits abnormally (or forgets to decrement) your main thread will hang forever. - the wait loop is not nice. 2. Since .NET 2.0 there is BackgroundWorker class, which supports cancellation and offers events. You could use its IsBusy property and/or its ProgressChanged event. 3. And of course you could use regular threads, keep them in a list, and periodically check their status. (Dont forget to clear the list when you conclude all has been done; so the threads get garbage collected). :)
Luc Pattyn [My Articles] [Forum Guidelines]
-
Thank you for your ideas. What method do you think is better when there are many threads?
Regards, Diego F.
I am not sure: - I have not used BackgroundWorker yet; - I have limited experience with ThreadPool; IMHO it lacks some functionality. - most often I use regular threads, so I can easily manage them (e.g. change their priority).
Diego F. wrote:
when there are many threads?
what is many ? It is my view that executing the same work in more than a couple of threads does not improve performance: all these threads start to compete with one another (they all want CPU cycles, or all want disk access, or...). So having 2 or 3 or 4 seems a maximum. The one good reason I can come up with for really many similar threads is for encapsulating independent jobs (as would be the case in a server with many clients). BTW: when using real Threads, you can also do the following: - for each new thread you create, add it to a list remark: you probably want to set IsBackground true - create a loop over that list, performing a Thread.Join(); when that loop finishes, all threads are done (does not matter in what order!). advantage: no need to count remark: clear the list when done - you might even create an extra thread to run that loop, so it does the waitforall logic, while your main thread can go on doing whatever it likes to do... Hope this helps. :)
Luc Pattyn [My Articles] [Forum Guidelines]
-
Thank you for your ideas. What method do you think is better when there are many threads?
Regards, Diego F.
Would this post[^] also be by your hand or is this person just copying and pasting your words?
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007