Thread Pooling

Norbert Nemec Norbert at Nemec-online.de
Mon Apr 24 12:42:32 PDT 2006


Thanks, K.Wilson for your insightful clarification. Like ever so often,
I forgot that I, like every programmer, have only a limited perspective
and should not be too quick to judge according to my own experiences.

Indeed, "plenty of threads" should be clarified to "at least as many
threads as there are processors but not orders of magnitude more".
Creating a thread is fairly cheap nowadays, but, of course it has some
cost, and there certainly are applications (like the server that you
mention) where this cost has considerable weight.



wilsonk at nowhere.com wrote:
> In article <e2i973$1iap$1 at digitaldaemon.com>, Norbert Nemec says...
>> Weren't thread pools mostly a crutch for old systems where creating
>> threads was expensive? Nowadays, threads are usually lightweight enough
>> that it is the best strategy to write a program creating plenty of
>> threads and leave the scheduling completely to the operating system.
>>
>> So, of course, you could have a function like "scheduleTask", but that
>> function should simply create a thread and it is to operating systems's
>> job to schedule this thread for later execution.
>>
> 
> Hi Norbert,
> 
> I think you are correct with your statement above about thread creation being
> expensive on old systems compared to nowadays. But the creation of "plenty of
> threads and leave the scheduling completely to the operating system" may need
> some clarification. 
> 
> I assume that you are thinking of a program that only uses any given thread once
> during exectution, then the program terminates. If this is not the model you are
> thinking of then, thread pools are a useful optimization. 
> 
> I wrote a server generation tool that used thread pooling and it was much faster
> under Linux than the process-based (ie. "lightweight threads", as you say, under
> Linux ;) or thread-spawning models. The reason for this is the very short term
> use (and no re-use) of many threads in the server <--- usually HTTP servers. 
> 
> Example: "For each connection spawn a new thread, service the request, then kill
> thread" is very expensive compared to "For each new connection grab thread from
> pool, service request, place thread back in pool".
> 
> Thread pools are used in the ACE framework, SEDA framework, etc. for high
> speed/high load communications (Apache 2 also uses a thread pool, by the way).
> 
> So anyways, if you are not worried about communications software (and the like)
> then simply letting the OS schedule everything may be marginally acceptable (I
> am sure others know of programs where this strategy 'won't' be acceptable,
> though). 
> 
> Thanks,
> K.Wilson
> 
> 



More information about the Digitalmars-d mailing list