Is the Threadpool useless ?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a problem with the threadpool I can't seem to figure out.
If I use ThreadPool.QueueUserWorkItem to queue say 25 work items,
I would expect the Threadpool to give me the 25 free threads of the thread
pool i.e. execute my WaitCallback method 25 times instantly. However, there
seems to be about 0.5 sec. delay in pulling each thread of the queue.

Running the test code

public void WaitCallback( object state )
{
System.Diagnostics.Debug.WriteLine("Thread "+((int)state).ToString()+"
started");
Thread.Sleep(10000);
}

for( int i =0; i<50; i++)
ThreadPool.QueueUserWorkItem(new WaitCallback(WaitCallback),i);

I would expect the threadpool to instantly give me all available threads
thus executing the WaitCallback method 25 times. However, it takes at least
25 seconds for the pool to kick off 25 threads.

If you do not get the threads immediately, this in my book would make the
Threadpool completely useless for server purposes and any other for that
matter.

Is this as designed or am I doing something wrong ?

Regards

Per Millard
Systems Architect
Copenhagen
Denmark
 
That's just the way it is. Even if you manually create threads, the
operating systems does not immediately honor the request or start the
thread. Threads are resources and they take time to be allocated.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
 
Hi Alvin

I'm aware of that. But shouldn't the whole purpose of the threadpool be,
that threads are already allocated and thus take less time to obtain. I would
argue, that manually allocating a thread takes considerably less time. If
this is by design, clients accessing a server that uses the threadpool for
worker thread allocation would already have to wait 500 ms to get served,
just as a result of using the threadpool. I just have a hard time believing
that his was the intension. For me, it looks like they are dequeing work
items using a separate thread that runs in a time interval.

Regards

Per Millard
Systems Architect

Alvin Bruney - ASP.NET MVP said:
That's just the way it is. Even if you manually create threads, the
operating systems does not immediately honor the request or start the
thread. Threads are resources and they take time to be allocated.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



Per Millard said:
I have a problem with the threadpool I can't seem to figure out.
If I use ThreadPool.QueueUserWorkItem to queue say 25 work items,
I would expect the Threadpool to give me the 25 free threads of the thread
pool i.e. execute my WaitCallback method 25 times instantly. However, there
seems to be about 0.5 sec. delay in pulling each thread of the queue.

Running the test code

public void WaitCallback( object state )
{
System.Diagnostics.Debug.WriteLine("Thread "+((int)state).ToString()+"
started");
Thread.Sleep(10000);
}

for( int i =0; i<50; i++)
ThreadPool.QueueUserWorkItem(new WaitCallback(WaitCallback),i);

I would expect the threadpool to instantly give me all available threads
thus executing the WaitCallback method 25 times. However, it takes at least
25 seconds for the pool to kick off 25 threads.

If you do not get the threads immediately, this in my book would make the
Threadpool completely useless for server purposes and any other for that
matter.

Is this as designed or am I doing something wrong ?

Regards

Per Millard
Systems Architect
Copenhagen
Denmark
Click to expand...
Click to expand...
 
Thre thread pool waits .5 seconds to see if a thread becomes free before it starts a new one. If this is an issue for you you can warm up the pool by caklling the

ThreadPool.SetMinThreads

method to "warm up" the pool

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi Alvin

I'm aware of that. But shouldn't the whole purpose of the threadpool be,
that threads are already allocated and thus take less time to obtain. I would
argue, that manually allocating a thread takes considerably less time. If
this is by design, clients accessing a server that uses the threadpool for
worker thread allocation would already have to wait 500 ms to get served,
just as a result of using the threadpool. I just have a hard time believing
that his was the intension. For me, it looks like they are dequeing work
items using a separate thread that runs in a time interval.

Regards

Per Millard
Systems Architect

Alvin Bruney - ASP.NET MVP said:
That's just the way it is. Even if you manually create threads, the
operating systems does not immediately honor the request or start the
thread. Threads are resources and they take time to be allocated.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



Per Millard said:
I have a problem with the threadpool I can't seem to figure out.
If I use ThreadPool.QueueUserWorkItem to queue say 25 work items,
I would expect the Threadpool to give me the 25 free threads of the thread
pool i.e. execute my WaitCallback method 25 times instantly. However, there
seems to be about 0.5 sec. delay in pulling each thread of the queue.

Running the test code

public void WaitCallback( object state )
{
System.Diagnostics.Debug.WriteLine("Thread "+((int)state).ToString()+"
started");
Thread.Sleep(10000);
}

for( int i =0; i<50; i++)
ThreadPool.QueueUserWorkItem(new WaitCallback(WaitCallback),i);

I would expect the threadpool to instantly give me all available threads
thus executing the WaitCallback method 25 times. However, it takes at least
25 seconds for the pool to kick off 25 threads.

If you do not get the threads immediately, this in my book would make the
Threadpool completely useless for server purposes and any other for that
matter.

Is this as designed or am I doing something wrong ?

Regards

Per Millard
Systems Architect
Copenhagen
Denmark
Click to expand...
Click to expand...

[microsoft.public.dotnet.framework]
 
Hi Richard

Thanx a lot. That was valuable info. I already tried setting min threads but
I used a value that was to high. The function doesn't throw an exception, but
returns false so I disregarded that option. Anyway, I couldn't understand why
it took 0.5 seconds to create a new thread, but you cleared that up for me.
Thanx again. You guys from DVM rock, even without the big B

Regards

Per Millard

Richard Blewett said:
Thre thread pool waits .5 seconds to see if a thread becomes free before it starts a new one. If this is an issue for you you can warm up the pool by caklling the

ThreadPool.SetMinThreads

method to "warm up" the pool

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Hi Alvin

I'm aware of that. But shouldn't the whole purpose of the threadpool be,
that threads are already allocated and thus take less time to obtain. I would
argue, that manually allocating a thread takes considerably less time. If
this is by design, clients accessing a server that uses the threadpool for
worker thread allocation would already have to wait 500 ms to get served,
just as a result of using the threadpool. I just have a hard time believing
that his was the intension. For me, it looks like they are dequeing work
items using a separate thread that runs in a time interval.

Regards

Per Millard
Systems Architect

Alvin Bruney - ASP.NET MVP said:
That's just the way it is. Even if you manually create threads, the
operating systems does not immediately honor the request or start the
thread. Threads are resources and they take time to be allocated.

--
Regards,
Alvin Bruney [MVP ASP.NET]

[Shameless Author plug]
The Microsoft Office Web Components Black Book with .NET
Now Available @ www.lulu.com/owc
Forth-coming VSTO.NET - Wrox/Wiley 2006
-------------------------------------------------------



Per Millard said:
I have a problem with the threadpool I can't seem to figure out.
If I use ThreadPool.QueueUserWorkItem to queue say 25 work items,
I would expect the Threadpool to give me the 25 free threads of the thread
pool i.e. execute my WaitCallback method 25 times instantly. However, there
seems to be about 0.5 sec. delay in pulling each thread of the queue.

Running the test code

public void WaitCallback( object state )
{
System.Diagnostics.Debug.WriteLine("Thread "+((int)state).ToString()+"
started");
Thread.Sleep(10000);
}

for( int i =0; i<50; i++)
ThreadPool.QueueUserWorkItem(new WaitCallback(WaitCallback),i);

I would expect the threadpool to instantly give me all available threads
thus executing the WaitCallback method 25 times. However, it takes at least
25 seconds for the pool to kick off 25 threads.

If you do not get the threads immediately, this in my book would make the
Threadpool completely useless for server purposes and any other for that
matter.

Is this as designed or am I doing something wrong ?

Regards

Per Millard
Systems Architect
Copenhagen
Denmark
Click to expand...
Click to expand...

[microsoft.public.dotnet.framework]
Click to expand...
 
Back
Top