nu.kanga.list.mud-dev

6155: [MUD-Dev] Re: atomic functions

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.

--
Shawn Halpenny

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.