[MUD-Dev] Multi-threaded mud server.

Ross Nicoll rnicoll at lostics.demon.co.uk
Mon May 17 05:23:36 CEST 1999


On Sun, 16 May 1999, Caliban Tiresias Darklock wrote:

> >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
[snip]
> So your context switching immediately goes through the roof, doesn't it? 
Sorry, this is me not explaining what I meant very well, I think. As I
understood it, most MUDs allocated a new thread per user. However, your
later suggestions do seem definately better than mine...

> 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. 
An interesting idea, but I think it would require too much inter-process
communication, and in particular may not load balance very well...

> 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. 
Now this I like, as it kinda goes right around most of the database write
problems... however, load balancing again becomes a problem, and player
would have to be moved between threads, which is a problem in itself...



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




More information about the mud-dev-archive mailing list