[MUD-Dev] Multi-threading ( was: TECH DGN: Re: a few mud server design questions (long))

[Jon Lambert]

Sean Kelly write:
> From: "Jon Lambert" <tychomud at ix.netcom.com>

>> The ideal is NOT "one thread per CPU" no more than the ideal is "one
>> process per CPU".  The ideal is that a CPU should always have a unit
>> of work available and ready to run.  No more than one unit of work
>> and it should be ripe for the plucking at the exact moment when the
>> CPU becomes available.  Naturally we're always going to fall short
>> of that ideal.  :-)

> Good point.  A more careful re-statement of what I'd intended
> would be: one active thread per process.  The idea is to avoid
> unneccessary context-switching, not pine for the days of DOS :) 

I disagree with that as well.  "One active thread per process" still
misses the point I'm trying to make.  The point is processes and
threads are indeed one and the same animal in this context.

Looking at Linux for instance...

-------from Processes and Threads - By Danny Kalev ---
"Under Linux, threads and processes are almost indistinguishable
except for one thing: threads run within the same address space
whereas processes have distinct address spaces. However, no
differences exist between the two from a scheduler
point-of-view. Thus, a context switch between two threads of the
same process essentially jumps from one code location to another,
plus setting a few CPU registers."
--------------------------------

Let's assume Apache had some more configuration options (one real
and one imaginary last I looked):

 Option 1: pre-fork 5 worker processes

 Option 2: pre-create 5 worker threads (assume design requires no
 global data)

Which causes more context switches?  
Which one is "a bad idea" and why?

Surely there are many other caveats with threads and you've listed
one of them, synchronization.  While we could discuss that, I'd
simply point out it's not mandatory.  The 2nd apache configuration
above requires no more synchronization points than the 1st.

Now if you are doing no I/O at all in your application then that
task is not really further divisible under single CPU machine.  At
least not from the view of the scheduler.

Yet even in this case you could use a "soft-threaded" model
(i.e. tick counters, MUQ, Cold, Win 3.1 when viewed as a DOS app) in
which the context switch cost and length are defined entirely by the
application.  Even that has a few benefits, it avoids runaway
commands, prevents command starvation. provides an better average
user response time over a request mix (lower stand. dev.)

I've also seen muds that load their entire world database in memory
do more disk I/O while running than mud servers that are disk-based.
The I/O is hidden by the OS and shows up as excessive page faulting.
For example, something like...

  for (pObj = objects_list; pObj == NULL; pObj = pObj->next)

may indeed cause the OS to do lots of I/O. 

Anyways... I hope these ramblings are of use.

--
--* Jon A. Lambert - TychoMUD        Email:jlsysinc at ix.netcom.com *--
--* Mud Server Developer's Page <http://tychomud.home.netcom.com> *--
--* If I had known it was harmless, I would have killed it myself.*--


_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev