[MUD-Dev] Re: lockless system - foolproof?
Chris Gray
cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Aug 30 10:03:18 CEST 1998
[James Wilson:]
>Assuming this solution (please let me know if there are any other solutions),
>the possibility arises of having to collect a large number of such database
>commits due to some operation on a complex compound object, where guaranteeing
>the atomicity of access to subobjects is not sufficient. Then a thread which
>tries to grab all the objects in question, operate upon them in such a way that
>the overall constraints are satisfied, and save the changes, would be
>vulnerable to frequent, possibly endless restarts as one or another of the many
>objects it is trying to keep coherent is changed.
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.
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. 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.
That said, now JC can berate me for not understanding things properly!
--
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
More information about the mud-dev-archive
mailing list