(fwd) Re: Multi-threaded mudding (was a flamefest)

[clawrenc at cup.hp.com]

Not a bad description of the area.  His proposal is essentially a
simplified version of the lockless model I use (least case):

From: jacob at cd.chalmers.se (Jacob Hallen)
Newsgroups: rec.games.mud.misc,rec.games.mud.admin
Subject: Re: Multi-threaded mudding (was a flamefest)
Date: 9 May 1997 00:16:18 GMT

In article <3366c90e.1108797 at news.uq.edu.au>,
Geoffrey King <zzgking at mailbox.uq.edu.au> wrote:
>Here are i think a list of pros and cons for using threads (with an
>emphasis on Java), please feel free to adjust, amend or add to:

This entire thread of discussion shows how little people understand
about concurrentcy in programs.

If we want parallell execution of several chains of events at the same
time, we have to consider how these chains interact. In the case of a
MUD we find that it is possible to carry out quite a few different
things at the same time without any collisions of execution chains.
For instance we can happily execute a talk command in one room while
we perform a combat action in an other room. They do not interfere
with each other, and so they will behave in exactly the same way as in
a single threaded MUD.
On the other hand, we may get very funny results if we allow the
combat actions of two different participants in the combat be executed
at the same time. For instance, if two people are fighting a third
person and both strike at approximately the same time it may happend
that in mid execution, the target is suddenly gone, because the other
participant killed it, or made it flee.

There are a couple of different ways of stopping these thinsg from
happening. The most well known one is to use some sort of mechanism to
lock the resources you need before you exceute your chain of events.
Semaphores, monitors and rendez-vous are the most common mechanisms.

The important point about this is that the programmer has to determine
what resources are needed and has to explicitly lock and release them.
It takes quite a bit of skill and knowledge to do these things in a
correct way and the consequences of failing to do the right thing are
usually way beyond the bugs in a normal MUD. It would be quite easy
for any programmer to write code that makes the entire MUD lock up.
The classic problems are deadlock, where two execution chains require
a resource that the other one has locked, and starvation, where a
cahin needs a resource but never gets it.
There are no really good debugging tools available for systems based
on these techniques.

In a world of unskilled coders, I don't think you will be able to
build a multi-threaded mud which requires the coders to handle the
concurrency problems.

This means that a multi-processing mud should use implicit mechanisms
to handle resource sharing. This is quite possible, and not all that
hard if you use the current model of execution that is employed in all
MUDs that I'm aware of.

You have two basic ways of starting a chain of events. The first one
is that a player enters a command, starting the execution of a series
of statements and possibly changing the state of the MUD. The second
one is a timer triggered execution of a series of statements, possibly
changing the state of the MUD.

The most important property of both types is that the series of
statement is limited in length and thus execution time, and that these
limits restrict a single chain to fractions of a second.
This makes the chain-of-execution ideal as an indivisible unit for the
purpose of handling parallellism.

If we use LPC as an example, we would allow several chains of
execution to run in parallell, each handled by its own process or
thread. A thread would lock objects for reading or for writing
whenever the thread needs to access attributes of the object. If the
object is locked for writing, the modifications are actually done in a
copy of the object, not the object itself.
If a situation occurs where a thread needs a resource that is locked
it will get the resource if it is older than the owner of the
resource. The owner throws away everything it has done and starts
over.
If it is younger than the owner, it stops and waits for the resource
to be free.

When a thread terminates, it frees all resources and updates the state
of all objects it has modified and outputs all messages it has
generated.

This scheme would allow you to run an LPC based mud on several
parallell processors in a tightly or loosely coupled environment
without any changes to the LPC syntax, and very small changes to the
semantics. 

Jacob Hall n

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...