[MUD-Dev] Atomic functions

[Felix A. Croes]

A few years ago, I posted to this list about my idea for atomic
functions,

    http://www.kanga.nu/archives/MUD-Dev-L/1998Q2/msg00256.php

I have now implemented them in my server, and this posting concerns
that implementation and the effects of atomic functions on MUDs.

An atomic function is a function which either completes entirely, or
not at all.  An error in an atomic function rolls back changes made
by that function.

    object environment;

    atomic void move(object destination)
    {
	environment = destination;
	destination->enter_inventory(this_object());
    }

The move function above makes two changes.  First, it changes the
environment of the current object.  Second, it places the current
object in the inventory of the destination object.  However, the
second step could fail because, for instance, there is no room in
the inventory of the destination object.  Making the function atomic
ensures that if the second step fails, the first step "never happened."
There will still be an error to deal with, but at least that error has
not left the object in an inconsistent state, with an environment
which does not contain it.

The server requirements for atomic functions are very similar to those
for the C&C thread model.  The server must have its own internal
virtual machine; VM threads must be finite in duration, and must run
sequentially.

In my implementation, I made use of "data planes."  The base plane is
the normal dataspace in which values are created, destroyed, modified,
and so on.  On entering an atomic function, a higher plane is created
which is initially empty.  Thereafter, each value which is modified is
lifted to the higher plane, which means that the previous value is
backed up.  On a normal exit from the atomic function, the backups are
discarded and the values are committed to the lower plane.  If an error
occurs, the higher plane is discarded and the backups are restored.

Comparisions with an earlier version of the server, in which atomic
functions had not yet been implemented, indicate that the
administrative overhead -- discovering if a value is on a plane lower
than the current one -- is negligible; this means that non-atomic
functions are equally fast in both versions of the server.  There is
some overhead for creating and removing data planes, but it is minor;
atomic functions which make no changes to data are almost as fast as
the non-atomic equivalents.  The significant cost is in backing up
values that are modified, and in later committing or discarding the
changes.  Since checking the plane of a value is so cheap, the current
implementation tries to back up as little as possible each time a
value from a lower plane is modified.

Implementing atomic functions took me about 6 months, spread out over
a year.  An implementation in a completely new server would probably
take a smaller effort.

The effect of atomic functions on developing MUDs is profound.  My
guess is that future MUDs run on my server will be executing code
atomically half of the time.  One MUD, Castle Marrach, is already
extensively using atomic functions to preserve consistency of the
database.  In my own thinking, atomic functions have shifted from
"useful" to "invaluable."  Of course, bug-free MUDs will not need it. :-)

A version of my server with atomic functions is available here:

    ftp://ftp.dworkin.nl/pub/dgd/dgd-1.1.121.tar.gz

Regards,
Felix Croes



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev