[MUD-Dev] Re: atomic functions

[Chris Gray]

[Jon A. Lambert:]

I'm following up to Jon, but not directly responding.

An early morning (and perhaps foggy) thought I just had is this:

Suppose you let the system handle all of the atomicity, by making all events
completely atomic, regardless of how much they do internally. What is the
downside? Well, one big downside could be that if the event ends up doing
too much, it could continually be failing C&C if other things are going on.
However, if the event is doing a lot, there are likely lots of sub-events
within it, that can be atomic, and can complete even if the entire main
event doesn't. So, rather than having constructs that are required to get
atomicity, why not have atomicity be the default, and have constructs that
allow you to relax the atomicity? Something as simple as a 'commit'
statement, marking the boundary between sequences required to be atomic.

So what would happen with code like this:

    nonatomic event() {
        phase1();
        commit;
        phase2();
    }

This could only be done if 'phase1' leaves everything in a consistent state.
If 'phase1' has been completed successfully, the internal progress status of
the event is updated (from 0 to 1, say). Then, if 'phase2' fails to C&C, and
the event is retried, it will restart from 'phase2'.

Hmm. I guess one could argue that anything like this is really just syntactic
sugar, since you could rewrite it as:

    phase2event() {
         phase2();
    }

    event() {
        phase1();
        schedule event phase2event;
    }

Would this even be worth considering?

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA


--
MUD-Dev: Advancing an unrealised future.