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

[Sean K]

On Wed, Aug 01, 2001 at 12:22:49AM -0400, Jon Lambert wrote:
> 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...

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.

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

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

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

Yup.  I was thinking in more of a MUD context, where connections
where connections will be communicating with one another in some
fashion.

> 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.)

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.

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

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.

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

I'd like to think so.  The technical aspects of MUD design interest
me as much as the design aspects.

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