Thread Pooling

wilsonk at nowhere.com wilsonk at nowhere.com
Mon Apr 24 06:25:39 PDT 2006


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