[MUD-Dev] Re: atomic functions

[Felix A. Croes]

J C Lawrence <claw at under.engr.sgi.com> wrote:

> On Thu, 30 Apr 1998 03:59:20 +0200 (MET DST) 
> Felix A Croes<felix at xs1.simplex.nl> wrote:
>[...]
> >     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.
>
> > 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.
>
> Hurm.  I'm not entirely sure I understand.  Would this be a correct
> re-phrasing?  
>
>   An atomic function is a member of a special class of functions which
> may be called from an executing event, but whose pass/fail result are
> reported back to the caller as vs re-entering the C&C mechanism.

While the handling of an atomic function failure is almost identical
to that of event failure under C&C, the <meaning> is not: the function
failed due to a runtime error.  This is only similar to event failure
if events, also, can be undone by a runtime error.  Because of this,
I prefer not to define atomic functions in C&C event terms.


> Note however that the *ONLY* possible use for such a function is to be
> able to call it from an executing event, have it FAIL, and continue
> execution of the event despite the failure.  Why is this is only
> possible use?  Because if the function succeeds (the only other
> possible return state of a function at this level), then there is no
> effective difference between the execution pattern of such an "atomic
> function" and any other form.  It is only in the FAIL state that the
> execution pattern is different.
>
> Delving futher into the FAIL state semantics, if the caller is to also
> FAIL because of the atomic function's failure, then the only gain from
> the atomic function overhead is is that it may get earlier
> notification of its impedending C&C failure via the atomic function
> than it would have otherwise.  This can be a notable performance
> enhancement, but comes at significant cost in complexity of the
> execution environment (which is now heirarchial as vs flat) and in
> code.  Additionally the benefit is only gained for callers of atomic
> functions -- all other events suffer the penalty of the more complex
> environment without any gain.  

In my design, events are only cancelled if they fail to commit their
changes.  Uncaught errors cause the event to terminate, but do not
make it skip the commit phase.

Aside: an event that fails a number of times will eventually be
rescheduled in (effective) single-threaded mode.  Thus, it is not
possible for scheduled events to disappear altogether, and the
temporary failure of events is invisible from within the system.

Note that calling the execution environment `flat' is slightly
misleading.  It is flat, but not <utterly> flat -- without atomic
functions there are still two layers.  Per my design, the only
penalty associated with atomic functions is in the copying of data
required when they are being executed.  This is precisely what
happens when data is normally being accessed by an event in a C&C
environment, and indeed, the code makes no distinction.


> It is only when the calling function is intended to continue execution
> despite the failure of the atomic function (at the C&C level), that
> the execution pattern is different.  However the functional gain here
> I find (and found, I implemented somethign like this for a while)
> to be illusionary.  There just is no practical use for the feature.

I contest this :)  I claim that it is very useful indeed, and not
at all illusionary.  I frequently find that actions which have to
be atomic -- for instance, moving a hungry dragon into a room,
which changes both the environment of the dragon and the inventory
of the room -- are part of a larger event, the actions of which
I want to be executed precisely in that other without other
events intervening.


>   Note: ColdC has a similar construct with their exception handling
> model (Miro or Brandon can probably expand better than I there).

Critical sections in ColdC?  I looked it up, and there does not
appear to be any undoing of changes involved.

Felix Croes

--
MUD-Dev: Advancing an unrealised future.