[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