[MUD-Dev] Re: atomic functions
J C Lawrence
claw at under.engr.sgi.com
Wed May 6 15:19:19 CEST 1998
On Wed, 6 May 1998 23:28:45 +0200 (MET DST)
Felix A Croes<felix at xs1.simplex.nl> wrote:
> 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.
Ahh! Light dawns! You are taking about exception models, not locking
or commit models!
Ahhhhhhh, I see. Then yes, in that guise atomic functions as you term
them have a very definite and valuable use. Nice idea.
However it also assumes (but does not require) that an atomic function
has only one success state, and possibly many failure states. Or, to
use the exception model, what if some exception forms are are
acceptable?
My language construction uses exceptions heavily. In fact an
exception is the default (only) return path. An exception encludes
specifics on where it was raised, and may be bound with other
code-supplied data sets. An ERR_OKAY exception is thus the normal
return with any return code being accessably by querying the exception
for its bound data set, and with ERR_<anything_else> being the error
cases (with possible bound data sets).
--
J C Lawrence Internet: claw at null.net
(Contractor) Internet: coder at ibm.net
---------(*) Internet: claw at under.engr.sgi.com
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...
--
MUD-Dev: Advancing an unrealised future.
More information about the mud-dev-archive
mailing list