[MUD-Dev] Re: atomic functions

[Felix A. Croes]

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

> On Fri, 1 May 1998 15:11:58 +0200 (MET DST) 
> Felix A Croes<felix at xs1.simplex.nl> wrote:
>
>
> > What it actually does is impose an execution order on bits of
> > atomically executed code:
>
> >	foo()
> >	{
> >	    atomic {
> >		/* code fragment 1 */
> >	    }
> >	    atomic {
> >		/* code fragment 2 */
> >	    }
> >	    atomic {
> >		/* code fragment 3 */
> >	    }
> >	}
>
> I suspect that you are confusing some logical equivalences.
>
> From an execution view point there are units which execute atomically.
> What the logical or language scope of those units are is really beside
> the point.  They're merely atomic units, and it is from those units
> that the world progression is made.  
>
> You are attempting to solve the problem of enforcing order of
> compleation of such atomic units thru blocking structures, and to add
> the concept of aggregate atomic actions via nesting.  No?  

Uh... no.  There is no blocking involved.  `atomic { ... }' is just
an atomic function in a different guise.

Also, I am not trying to solve any problems in C&C at all.  Rather,
I propose something that exists only within an event, and thus is
invisible from the C&C point of view.

Within an event, the atomic elements are individual virtual
machine instructions.  It is on that level that atomic functions
are atomic -- they are either executed as a whole or not at all.
The code you quote above can only be said to be similar to a
sequence of events in C&C if runtime errors causes the event to
fail.  No further similaries intended or implied.


> C&C odering really doesn't have anything to do with the C&C model, and 
> is external to the atomicity requirements of the C&C model.  Why?  C&C 
> defines the basic unit of existance: the state change.  An individual
> state change is insular -- it has no relevance to other state
> changes.  It is your __external__ process model which imposes its snes 
> of order upon your state changes.
>
> Next up nested C&C's are a logical fallacy for similar reasons (there
> are some really good papers on this on the web if I could remember
> where), but a useful modelling tool.  Nested C&C's offer the idea of a 
> larger aggregate state change being composed of previously define and
> known insular state changes.  The problem is that that model doesn't
> work at the logical level.  The super-state change has to inherit the
> working sets and exit criteria of the nested state changes in order to 
> validate its own C&C, and refuse the allow the nested state changes to 
> commit until that time.  If it did not it could fail C&C and attempt to
> rollback nested events which have already commited.

Disagreed.  You are implicitly assuming that all changes are
committed at the same level.  All that is needed to get the above
to work is to let nested commits affect the super-state change's
local, copied state instead.

That would also make the nested C&C's more like atomic functions
inside the super C&C -- though it is still an awkward comparision
otherwise.

I think the confusion stems from two different meanings of the
word 'atomic':

 1) an event is atomic because it does not overlap with other
    events.  This is the C&C viewpoint.
 2) an atomic function is atomic because it is executed either
    as a whole, or not at all.

Only if events fail on runtime errors are the two meanings identical
in practise.

Felix Croes

--
MUD-Dev: Advancing an unrealised future.