[MUD-Dev] Re: atomic functions
malachai at iname.com
Thu Apr 30 16:18:44 New Zealand Standard Time 1998
On Thu, Apr 30, 1998 at 03:59:20AM +0200, Felix A. Croes wrote:
> Having recently completed the implementation of the generic parsing
> utility that I posted about earlier, I am now preparing to convert
> my server to the lockless multithreading paradigm put forward on this
> list by J.C. Lawrence.
> It has occurred to me that the commit-or-fail idea can be applied to
> parts of threads as well as entire threads, leading to the following
> concept of "atomic functions":
> An atomic function is a function that succeeds or fails as a
> whole. Any runtime error that is not caught within the function
> will lead to the entire function call, with all its effects
> and side-effects, being undone.
For me, a function cannot be executed without having a corresponding
event: it is tied tightly to the lockless-ness of the DB commits.
Events accumulate a working set. If those objects are committed (and
they will be if no other event has already finished with its objects
and has C&C'd), then the thread that was executing that event
effectively "dies" (although it's kept around in a pool for subsequent
quick reuse) and the event is no more. I would consider each executing
event method an atomic function as you've described them--all of the
effects undone on failed C&C reset the world state for that event to
the new current state. A runtime error in a function essentially
amounts to a failed C&C, since the end result is the same: no changes
persist. However, a failed function will cause the event method in
which it was called to not be rescheduled and thus it will not attempt
to C&C again. A C&C failure without a corresponding function error is
perfectly acceptable and, in fact, required.
> Atomic functions would be used to enforce consistency -- just like a
> thread either fails or succeeds without leaving the mud in an
> inconsistent, half-completed state. Of course, every function called
> at the beginning of a thread is effectively called atomically, so
> code that depends on atomic functions can be replaced by code that
> depends on (atomic) threads. The advantage of atomic functions
> would be to place the function call within the wider thread
> context, which would be similar to imposing an execution order on
> threads. Also, calls to atomic functions could be nested.
I'm not sure I understand how this alone will impose an execution
order. If I have threads (I could even substitute "events") executing
in parallel, normally whichever is able to C&C first, wins. Any order
I impose on executing events depends on sequence numbers associated
with the events themselves. Design details about the sequencing are still
muddy, since I'm re-examining my approach.
I know that you believe you understand what you think I said, but,
I am not sure you realize that what you heard is not what I meant.
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev