Re: ThreadPool question .NET 2

[Shree]

On Aug 22, 1:01 pm, "Brian Stoop" <b.st...@consul tant-spam.free.com>
wrote:

I have several Threads that start other Threads like this:
>
ThreadA
{
    for (int i=0; i <10; i++)
    {
        ThreadPool.Queu eUserWorkItem(n ew WaitCallback(Te stThread1),
(object)i);
    }
>
    // Wait for all TestThread1 to terminate before proceeding ??????
>
}
>
ThreadB
{
    for (int i=0; i <10; i++)
    {
        ThreadPool.Queu eUserWorkItem(n ew WaitCallback(Te stThread2),
(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 "TestThread 1". Make the main thread wait while
this counter is not maxed out; 10 in your case.

[Peter Duniho]

Re: ThreadPool question .NET 2

On Fri, 22 Aug 2008 04:09:26 -0700, Brian Stoop
<b.stoop@consul tant-spam.free.comwr ote:

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