[MUD-Dev] Re: lockless system - foolproof?

J C Lawrence claw at kanga.nu
Sun Aug 30 13:23:26 CEST 1998


On Sun, 30 Aug 1998 10:03:18 -0600 
Chris Gray<cg at ami-cg.GraySage.Edmonton.AB.CA> wrote:

> I certainly don't want to speak for JC, but here's my
> understanding...

> The goal is to have the programmer not have to worry about issues
> like that - they are too tricky for most people who would want to
> try scripting on a MUD. So, JC's system, last I heard, doesn't
> present any specific locking or commit primitives to the
> programmer. The goal is to have the underlying system take care of
> it all for you. A lofty goal, but very nice if achieved effectively.

Correct.  There are no locking or commit sematics exposed to the user
or programmer.

> As an event runs, the system keeps original, untouched copies of all
> database objects that the event references or changes. As the event
> changes things, copies of the originals are made, and the changes
> are put into those copies. When the event completes, the C&C
> (compare and commit) happens (all automatically). If any of the
> objects that the event referenced have been changed in the meantime,
> then the event must be retried. Otherwise, the event's changes are
> atomically committed to the database. 

Bingo!

> I think there were some optimizations possible. There could be lots
> of retries needed on busy objects. I believe some of the suggested
> solutions involved the scheduling of events, with the final attempt
> that of running the contentious (hah!) event all by itself, with
> nothing else running.

<nod>

> That said, now JC can berate me for not understanding things
> properly!

Why would I ever do that?

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




More information about the mud-dev-archive mailing list