[MUD-Dev] Multi-threaded mud server.

[Mik Clarke]

Jon A. Lambert wrote:

> Yes, but I can't for the life of me figure out why it's so damn important
> to avoid. ;)

Agreed, context switching is not expensive and it isn't a problem.  Most OSshave
it down pat by now.  Attempting to balance the load on the threads is
fairly pointless, as the system does not assign threads to particular CPUs.
Modern multi tasking systems will typically execute less than a thousand CPU
instructions between (involuntary) context switches. Threads get voluntarily
suspended as soon as they start waiting for something - I/O, page faults
etc...  The same thread will probably be batted around between the CPUs like
they were playing catch with it.

The reason you don't want more than 2 or 3 times as many threads than
CPUs:

When your application is busy - very busy, and all threads are demanding
attention, the CPU(s) will be fairly busy trying to service them all. If you have
many more threads than CPUs you end up with 'ready to dispatch' threads
waiting a long time to get some CPU.  Most threads will not be ready to dispatch.
They will either be idle or waiting for something else to happen (like I/O to
complete, or memory to be paged).  When you have enough ready threads to 95%
saturate the CPU, adding more threads won't make it go any faster.

For the mainframe product I work on we use a figure of 2-3 times the number
of CPUs for the threads.  This gives us good through put (our environment
has quite a lot of I/O in it) and leaves some CPU free for the rest of the
system.

Why some muds don't take to multi-threading:

If a Mud runs through an external database, it should multi-thread very well.  If
a mud runs from a single instorage, strucutre (ala LPs, Diku) it will not
multi-thread very well.  The main problem is that you either have to have
hundreads and thousands of semaphores to protect each data structure from
simultaneous access by multiple threads (ok when they are all reading, but
bad news when one or more of them is trying to make a (non-atomic) change).
The alternative is to lock the whole structure and make the threads wait for
thier turn before accessing it.  This lets them do I/O and validation type things
before they join the queue, and they need to know beforehand if they want to
read or update (multiple consecutive readers can be allowed).  For a Diku, such
a change is a big deal.

Mik




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev