[MUD-Dev] request for comments

[JC Lawrence]

On Wed, 7 Jan 1998 10:38:34 PST8PDT 
Mike Sellers<mike at online-alchemy.com> wrote:
> At 05:03 PM 1/6/98 PST8PDT, JC Lawrence wrote:

>> To describe my system loosely, and briefly:
>> 
>> The server is heavily multi-threaded (I think the idle-state is
>> over 50 threads currently).
>> 
>> All events are processed aynchoinously and in parallel.
>> 
>> The server is lockless.
>> 
>> I don't guarantee order of execution of two unrelated events.

> So... without recapitulating the flamage on this that occurs
> regularly in r.g.m.*, how do you handle things like the "Dragon's
> Dinner" scenario, where the player thinks she has closed the door
> behind her, but then is surprised when she is fried by the dragon
> anyway (who, in this race condition, saw the door as "open" and went
> through)?  In a truly lockless system, aren't race conditions
> inevitable?

No, race conditions are not inevitable, and the solution is fairly
standard in the DB world.  The basic idea is that any process modifies
only local data.  Then, at the end of the process, a list of all the
data members referenced is generated, and the current (external)
values of those members is compared to the value they had when the
event started.  If they are different the event has "failed" and is
killed to be rescheduled for later.  If they are the same (nothing
changed during the course of execution), then commit the new changed
data, and proceed.

The key element is that no two processes can every modify the same
data at the same time, an no process can rely on a datum that another
process will modify before the first process compleats.

--
J C Lawrence                               Internet: claw at null.net
                                           Internet: coder at ibm.net
----------(*)                        Internet: jc.lawrence at sun.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...