[MUD-Dev] Multi-threaded mud server.

[Mark Gritter]

Caliban Tiresias Darklock writes:
> 
> I think that's the most obvious initial model to want when you do this sort
> of thing, but I also think it's been beaten to death on the
> context-switching issue. Consider if you have forty players on forty
> threads; when ten of them go and talk, when each of them says something in
> sequence you have ONE HUNDRED context switches. One for each of the players
> who hear the speech, and one to return success to the initial thread,
> making ten context switches for each statement times ten players. Yuck yuck
> yuck.
> 

I agree.  So don't do it that way.  :)  Why should a thread block just
because it's communicating with an object "controlled" by a different thread?

I think the say() method should look something like this:

void Character::say(string text) {
  foreach Chracter c in room
    lock c's input queue
    add { myName() + "says" + text } to c's input queue
    unlock c's input queue
  end
} 

Then when the thread or threads handling the other characters start running
that character, they pull the "say" event or text off the associated queue
and display it.  You only do a context switch when the lock is held _and_
another thread is runnable.  So you can either use non-blocking synchronization
(queue insertion can be done using atomic compare-and-swap) or use a number
of worker threads that's some multiple of the number of processors.
(If the amount of time the lock is held is likely to be <= a context switch
time, then just sitting around is the right thing to do, though.)

The model Ross discusses keeps context switches to 0 in the absence
of contention.  (If there are other processes, you have to do "heavyweight"
context switching, of course.)

> Or, the short form of the above: How do you balance the load before you
> measure it?
>

Good point.  You do load balancing dynamically---  if one thread falls behind 
in "simulated time", it's a sign that you need to reduce its 
responsibilities.  You _do_ gain by moving characters in the same area into 
the same worker thread, since that will probably reduce the number of lock 
conflicts.

Mark Gritter
mark at erdos.stanford.edu


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