471,356 Members | 1,804 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,356 software developers and data experts.

Re: ThreadPool question .NET 2

On Aug 22, 1:01*pm, "Brian Stoop" <b.st...@consultant-spam.free.com>
wrote:
I have several Threads that start other Threads like this:

ThreadA
{
* * for (int i=0; i <10; i++)
* * {
* * * * ThreadPool.QueueUserWorkItem(new WaitCallback(TestThread1),
(object)i);
* * }

* * // Wait for all TestThread1 to terminate before proceeding ??????

}

ThreadB
{
* * for (int i=0; i <10; i++)
* * {
* * * * ThreadPool.QueueUserWorkItem(new WaitCallback(TestThread2),
(object)i);
* * }

* * // Wait for all TestThread2 to terminate before proceeding ??????

}

--------------------------------------------------------------------------------------------------

The TestThread1 and TestThead2 methods have as a randon sleep up to 30
seconds before terminating.

How can I tell when all the ThreadA ThreadPool requests have completed ?

thanks B
A simple way could be to keep a static counter which can be updated in
the call back function "TestThread1". Make the main thread wait while
this counter is not maxed out; 10 in your case.
Aug 22 '08 #1
1 1280
On Fri, 22 Aug 2008 04:09:26 -0700, Brian Stoop
<b.*****@consultant-spam.free.comwrote:
Is there a way to get this informaton from the ThreadPool ?
Not really. Even if you could get the ThreadPool to tell you how many
busy threads there are, there could be other ThreadPool threads working as
well. There'd be no way to know that as the current count of busy
ThreadPool threads changed, that was because of your threads versus any
others.

If you follow Shree's advice, make sure you increment and decrement your
counter in a thread-safe way (e.g. see the Interlocked class) and you
don't "busy wait" on the counter (i.e. create a single AutoResetEvent that
each worker thread sets after changing the counter, and have the main
thread wait on that handle before checking the counter).

Other alternatives include giving each thread a unique WaitHandle object
(again, an AutoResetEvent would work fine), having the main thread wait on
all of them, with the worker threads setting the handle when they are
done; or, combine the two techniques with a counter that the threads
manage and a single WaitHandle that the main thread waits on, and the last
worker thread to complete would set.

IMHO the last solution is the best, as it minimizes OS resources used
(just one AutoResetEvent object) but doesn't bother the main thread until
it's guaranteed to be able to proceed (it's silly to keep waking the main
thread up just to check a counter that an already-running thread could
have checked).

Pete
Aug 22 '08 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Dan Battagin | last post: by
5 posts views Thread by Duane Pressley | last post: by
6 posts views Thread by Max Adams | last post: by
1 post views Thread by doudou-shen | last post: by
10 posts views Thread by Lenn | last post: by
5 posts views Thread by =?Utf-8?B?RkxEYXZlTQ==?= | last post: by
3 posts views Thread by UltimateBanoffee | last post: by
7 posts views Thread by =?Utf-8?B?cmJEZXZlbG9wZXI=?= | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.