[MUD-Dev] Multi-threaded mud server.

[Caliban Tiresias Darklock]

On 08:42 PM 5/16/99 +0000, I personally witnessed Ross Nicoll jumping up to
say:
>
>The MUD creates as many threads as processors, and then allocates players
>and computer characters in such a way that load on each processor should
>be roughly equal. This should keep context switching to a minimum.

Maybe I don't understand context switching -- my understanding of threads
is minimal -- but this sounds fallacious. As I understand it, context
switching is when one thread gives way to another thread, which means its
state (context) needs to be saved and the other's has to be restored
(switching). 

So if you have two players online, each with one character, each on a
different thread of a multiprocessor machine, and they have a conversation
-- don't you have to context switch twice with every statement? The current
player says something, which needs to go to the other player, so you
context-switch to the other thread to talk to player two, send him the
information, and then tell the original thread that you completed the
action successfully, which is yet *another* context switch. So your context
switching immediately goes through the roof, doesn't it? 

If I'm correct in this understanding, and please correct me if I'm not,
then the "proper" way to implement such a scheme would be for each thread
to accomplish specific *tasks* instead of handling specific *objects*. So
instead of a series of "do things with an object" threads, you would have a
series of "do this thing" threads -- and those which are rarely if ever
called can be shut down entirely after a given period. For example, you
might have a "login" thread which handles everyone connected but not logged
in, a thread which handles combat, a thread which handles character
creation, etc. 

Ideally, you would set this up so most of your common operations are in the
same thread, while progressively less common actions get separated out into
threads which can be put to sleep entirely when they're not needed. A login
thread, for example, only needs to be active when someone is sitting at the
main login screen to log in; if there are long periods during which no one
logs in, the thread can be put to sleep during those times. 

A related thought (and the one I'm still considering) would be a thread for
each area. When no one is in area X, that area can be safely unloaded from
memory; thus, with five players online, you don't need to have eighty areas
loaded. Just five, at most. All the other threads can be halted altogether. 

-----
| Caliban Tiresias Darklock            caliban at darklock.com 
| Darklock Communications          http://www.darklock.com/ 
| U L T I M A T E   U N I V E R S E   I S   N O T   D E A D 
| 774577496C6C6E457645727355626D4974H       -=CABAL::3146=- 


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