[MUD-Dev] Re: atomic functions

[Shawn Halpenny]

On Sun, May 03, 1998 at 09:34:56AM -0700, Chris Gray wrote:
> [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?

Yep.  This is related to the sub-thread from a while back about ensuring
event output gets to the users in correct order, event-sequencing, and
all that.  It's how I'm planning to handle it.

The idea was to take an event that touches a lot of objects (say, a
message written to every player), break it up into smaller events that
touch fewer objects and process those events in some order, to prevent
this large event from repeatedly failing to C&C (and eventually forcing
the server to single-thread until it completed).  Felix' atomic
functions would seem to handle this, but I think the function author
would have to explicitly mark the atomic sections properly.

I want a method to do this without having to write the code in a special way,
though:  I don't want the scriptor to have to think about breaking his "add
10 to the max_damage of every adamantine sword whose name begins with the
letter 'Q'" event into a chain of events (one per sword, by the time all is
said and done), just to make sure that an update of that breadth will
commit in timely fashion.  Roughly, I want the scriptor to be able to
write something like:

function foo()
{
	foreach obj (obj_in_world.type == "admantine sword")
	{
		... some stuff ...

		obj.max_damage += 10;

		... more stuff ...
	}
}

and not have the server handle foo() single-threadedly.

Is breaking that loop into an event chain as simple as scheduling an event to
execute the guts of the loop on each iteration?  I think you'd still end up
with a lot of failed C&C's as those new events ripened, since the
foo() event hasn't completed looping yet.

Would the effect be less drastic if the attributes were stored as distinct
objects in the DB, rather than considering mud objects as the base storage
unit?  That way, the only time C&C would fail is if some other event had
touched the exact same attribute, as opposed to just touching the object.
(I'm particularly hoping someone (like JCL!) will have tried something like
that and can feedback here).

--
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.