[MUD-Dev] Multi-threading ( was: TECH DGN: Re: a few mud server design questions (long))
sean at hoth.ffwd.cx
Wed Aug 1 11:46:14 New Zealand Standard Time 2001
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
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
> 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.
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev