nu.kanga.list.mud-dev

32: Re: {MUD} Re: various (MUD)

On Mon, 26 Aug 1996 14:09:39 -0700, you wrote:

} On Aug 26,  7:07pm, Alex Oren wrote:
} > On Mon, 26 Aug 1996 10:11:57 -0700, JCL wrote:
} 
} > } Object creates
} > } and destroys are really of a different class of DB-level events than object
} > } content changes.
} >
} > Which brings me to a discussion we were having on a different thread: having
} > properties as parts of the object or as standalone objects.
} >
} > Consider:
} >
} > Assume three properties on the PLAYER object: Inventory, Gold and Hits.
} >
} >    [Bubba, Bozo and Googoo are in a room]
} >    Googoo> drop sword
} >    Bubba> give 20 coins to Googoo
} >    Bozo> kill Googoo
} >
} > All three commands invoke events that change the state of the Googoo
} > object, possibly failing and re-executing due to C&C contention. The events
} > will have to be executed serially.
} 
} Not true, if Bubba, GooGoo, and Bozo are different players or objects.  At the
} system level the order of entry for the above three commands is indeterminate.
}  Bubba can't know that GooGoo droped the sword until the DropSword event
} compleats.  Ditto for Bozo and Bubba's coins.

Chris, you misunderstood me. Probably my poor wording is showing again, but you
should be used to it by now :-)
(In other words, I'm not as stupid as I sometimes sound.)

There are three events in the system, all contending for the GooGoo object.
At the first iteration, two of them will fail C&C and will be rescheduled.
At the second iteration, one of them will fail C&C and will be rescheduled.
Thus, serial execution (even worse than serial, actually).

} At the system level all three commands can be considered simultaneous and
} processed (compleated) in any order.  The only contention which could arise in
} the above would be over te GooGoo object and containment changes due to the
} coins.  Not a problem as the event just gets resceduled and executes then.
}  Whether the combat starts before or after GooGoo gets the coins is also moot,
} for the same reasons.

See above.

} The only area I see any need of strict sequential ordering is in the processing
} of commands or events arising from the same object.

This has nothing to do with ordering.
I suggested that having attributes (Inventory, Gold and Hits) as separate DB
objects will reduce contention.

So, to rephrase my earlier post:

All three commands invoke events that change the state of the Googoo object,
possibly failing and re-executing due to C&C contention. Thus the efficiency of
the events' execution will be worse than serial.

Now, if we change the model so that each property becomes a DB object in it's
own right (I believe that is what ChrisG uses) there is no contention, no C&C
stalls and reschedules and all the benefits of fully concurrent execution.

OTOH, one may argue that most of the contention will be for containment
properties anyway (inventories, rooms, etc.) so we will not gain much.

Comments?


Have fun,
Alex.