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

[Jon Lambert]

Sean K wrote:
 
>> Looking at Linux for instance...

> I was speaking from more of a windows perspective, where fork()
> doesn't exist.  So the programmer, for the most part, only has
> control over the treading model, and a program generally occupies
> only a single process.  

Processes and threads are also treated identically on Win32 systems
from the schedulers POV.  The programmer has full control over
both. It doesn't make a whit a difference _how_ the processes are
created.

See something I called Echo here...

  http://tychomud.home.netcom.com/download.htm 

I use CreateProcess() to hot boot a server instead of *nix fork() or
exec().

> In the linux context, they're essentially equivalent.  The major
> difference being ease of data sharing.  

It's the same with Windows.  The Windows version of Apache just
happens to create threads, it could just as easily created
processes.  I could have used it as an example as well and posed the
same questions.
 
> This relates a bit to the tick processing discussion I was having
> in another thread.  I think there's an application for both this
> and traditional multithreading in an application.

Don't forget NT fibers.  With fibers your application controls both
the scheduling and the point of context switch.  I called the above
soft-threaded, yet I think the proper term is software time
slicing. Fibers are just an api to do software time slicing.

I don't use fibers since I wasn't really that comfortable with them
at the time I was coding the VM piece of my mud.  Like I said in a
previous post, I multi-thread database and network I/O.  However I
use time-slicing based on tick counters in my VM.  Also the minute a
task makes a request to the other subsystems handling I/O, I
immediately switch to another task.  I don't multithread the VM
because I want to switch context on my byte code instruction
boundaries rather than machine instruction boundaries.  It makes it
much simpler. The only points of synchronization are a few work
queues.

The idea is to keep the CPU always doing something that needs to be
done while the app waiting on something somewhere else.

I also have an excellent example from a paper published one of the
developers of Lotus notes.  Unfortunately I can't find the link at
the moment but the thrust of it was that originally Notes operated
on a single select() model (like many muds).  They then alpha tested
a one thread per connection model (similar to the model that Java 1
muds had to put up with), and finally ended up with the best
performance from a ~20 thread pool model.  That is all on a single
CPU server.  They ended up with different thread mixes for dual and
quad processors.

> If the MUD occupies enough memory that it strays out of the
> physical and into the virtual, I agree.  And if this is the case,
> then loading everything into memory is of questionable use :)
> There are also other options, like memory-mapped files.  C++
> provides a nifty way to make this transparent by writing a custom
> allocator.  But this strays from the topic of multithreading into
> the genral realm of application design.

The only reason I mentioned it was to illustrate that something
which appears to a CPU bound task is not.  Both Linux and Windows
will page often long before you run out of real memory.  I guarantee
that your mud wont be the only thing running on any box.  The TCP
stack just for starters its own threads and memory needs.  And it's
memory needs are quite ravenous as connections go up.  This goes
back to dividing up tasks for multi-threading.  What I mean is a
long running function that touches memory all over the place will
cause page faults, and likely context switches. You want long
running tasks separate from command tasks users run to keep user
response time regular.

At this point someone always observes that muds just don't have long
running tasks or if they do they aren't well designed.  Yep that's
true.  Muds are also known not to much on their own either and try
to squeeze what they do do in between user input and output.  Which
is to say they could do a heck of a lot more interesting stuff if
their own tasks were decoupled from "nanny"ing the users.

--
--* 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