Re: Threads question

Tim Hollebeek (tim@franck.Princeton.EDU)
Fri, 25 Apr 1997 23:02:03 -0400 (EDT)

Dean Gaudet writes ...
>
> It is a common mistake for people considering multithreading things like
> IRCs and MUDs to reason that each connection should be a thread. I mean
> it's an obvious way to break up the tasks amongst threads. However it's
> far better, performance-wise, to have a queue of events which are
> processed by a dynamic number of worker threads. Thus you only require as
> many threads as you have work to do. Tuning that number is a matter of
> work, and depends on how you want the whole thing to function.

What most people miss is that the fastest way to do N short,
nonblocking tasks is to do them one at a time in order. Not quite as
cool as getting to play with a thread library, but still true. Threads
are only an advantage if they allow things to proceed while one task is
forced to "wait" for something. If that never happens, trheads are unot
much help. Wanting 1000 threads means you really think you have 1000
things to do, of which only a few can proceed at any one time. In reality,
that never happens.

Actually, if someone put a gun to my head and forced me to write a
threaded IRC server, I'd have threads serve *channels*, not
connections, and all but the highest volume channels would share
threads. The reason is that connections interact quite often, leading
to hairy synchronization issues (if they don't interact, IRC is pretty
boring :-)) while channels are to a first approximation independent.

---------------------------------------------------------------------------
Tim Hollebeek | Disclaimer :=> Everything above is a true statement,
Electron Psychologist | for sufficiently false values of true.
Princeton University | email: tim@wfn-shop.princeton.edu
----------------------| http://wfn-shop.princeton.edu/~tim (NEW! IMPROVED!)