[MUD-Dev] Modular Design Issues RFC

[J C Lawrence]

On Thu, 15 Feb 2001 07:08:18 -0800 
Ryan Rhodes <ryanshaerhodes at hotmail.com> wrote:

> In parsing this input Events are created.  (I'm trying to use the
> vocab of this forum here not ours)...

That one is my fault.  I started using "event" in that sense due to
historical reasons, and never changed my terminology when I moved to
a different model.  Aiiieeee.

> I assume alot of games work this same way.  However, for some
> reason my instincts tell me that commercial games maintain a
> separate thread for each player.  

Don't bet on it.  On large active player base systems, this would
often be a performance sapping strategy (2,000 online players ==
2,000 threads plus server overhead).  Asynchronous IO using a light
weight poll() type syscall (cf the C10K problem to see what I'm
talking about) which is abstracted from the main server base either
by thread or process boundaries (some implementations put user IO
handling on physically seperate systems) tends to be much easier to
scale.

> This 'player' thread has it's own infinite loop and from it parses
> the players input, creates events, and executes them, thus
> simulating time for the player.  The problems this would seem to
> create, in terms of data synchronization, would seem enormous.  

This depends on your locking model.  Fine grained sychronous locking
with such an approach could indeed easily be be nightmarish (and yet
is the approach of many commercial OSes such as Solaris, IRIX,
HP-UX, and even Windows NT due to the the performance/latency
benefits).  More abstracted locking patterns, such as the C&C model
I've adopted don't present such problems, and have the side benefit
of side stepping the deadlock problem entirely.

> An example of the benefits of such a system are thus.  After
> writing a new component online, our developers use the compile
> command to compile it.  To do a compilation we are going to have
> to block.  I could use a thread or thread pool to handle this type
> of action and have it send a notification to the players object
> when it is finished much like the manner you used threads for
> something in your post.  The problem with this is that to the
> player it appears as though he executed his command and is free to
> move about and execute other commands - like to clone this newly
> compiled file, only the file isn't really compiled yet and is
> going to let you know when it is.  Now had I just used the main
> game loop to block, the wizard would have felt a delay until the
> compile was finished, solving the problem.  The problem here,
> obviously, is that I've given everyone else a delay as well
> because I shut down the main game loop and everything that goes
> with it.  Now if every player had his own game loop I could just
> block his thread when he executes the compile command and
> everything is great.  I suspect this solution causes that wealth
> of synchronization problems I'm talking about.  Please comment.

I can't comment on the Java specifics of this model (I tend to think
of Java as Broken As Designed (BAD)).  The approach I ve taken is to
do the compile OOB from the normal player/server loop, and then lock
the main loop only while the new object/function heirarchy is being
instantiated.  Thus from the player's perception there is just a
brief pause (usually unnoticable and with better snapshotting
support in my DB it would be entirely unnoticable) while the game
universe /shifts/ in some manner about them.

> Your point about Multi-processor machines being able to take
> advantage of multiple threads is correct.  I had forgotten this in
> my argument for threads.  

This is also true, and more so, for multi-process models, let alone
physically distributed models.

--
J C Lawrence                                       claw at kanga.nu
---------(*)                          http://www.kanga.nu/~claw/
--=| A man is as sane as he is dangerous to his environment |=--
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev