[MUD-Dev] C&C and Event Rescheduling
Jon A. Lambert
jlsysinc at ix.netcom.com
Fri Jul 25 10:11:54 New Zealand Standard Time 1997
> From: clawrenc at cup.hp.com
> Subject: [MUD-Dev] C&C and Event Rescheduling
> In <33CFCE6E.41C67EA6 at iname.com>, on 07/18/97
> at 01:22 PM, Shawn Halpenny <malachai at iname.com> said:
> >Yep, a slight change is necessary. Now (and again, roughly):
> >1. A client C requests object O from the database.
> >2. Add C to list of clients using O.
> >3. Return OC (a client-only copy of O) to C.
> >4. A client D (which may or may not be the same as C, but is on the
> > using-list for O) returns OC'.
> >5. If O has not changed since D's request for it (a different client
> > may have committed changes to O while D was processing), OC' is
> > atomically committed to the database, replacing O. D is removed
> > from O's using-list.
> >6. If O has changed since D's request for it, OC' is discarded and D
> > receives notification that OC' couldn't commit.
> >7. Clients in the using-list for O are asynchronously notified that
> > O has changed.
> Given that this basic pattern extend to all the objects which comprise
> a given event or transaction, this is identical in principle to my
This might be accomplished by separating methods into event methods
and regular methods. A regular method is never called by the event
manager since it isn't a logical transaction, while an event method
forms an application consistent transaction. Upon termination of an
event method an implicit commit is done. This should allow nested
transactions as a side effect of nested event method calls as long
as commits are delayed to the callers termination.
> There is reason behind all this madness: It reduces the number of
> data copies needed for transactions. By using this sort of layered
> scheme I manage to delay making a copy of the object until I
> absolutely need one (ie someone has attempted to modify the object).
On further thought, the amount of object copies doesn't bother me
to much as a performance issue. Many well-optimized locking DBs do
this as a matter of integrity. The wasted time and possible race
conditions in event rescheduling vs. wasted time waiting on "a lock"
and possible deadlocks do bother me. I can't really make an informed
guess as to which is better. Some heavy duty profiling is probably
> Re: #5. How do you determine that the object has changed during the
> execution of the event? I do this by always keeping an original copy
> of the object to compare to the copy current in the DB and then do a
> bit-wise comparison of the two objects. The original copy is the
> second copy made above for a modification.
> Aside: I'm actually getting *slightly* neater than this as the
> current plan encludes only making a copy of the object
> attribute/member which is changed, and then only comparing that at
The burdens of attribute detection are difficult. How does
one detect the difference between:
ObjectA method ()
x = ObjectB.attrX; // a direct reference
y = ObjectB.GetattrY(); // an indirect reference through accessor
// perhaps a derived attribute?
Another possibility is for the DB manager to push the requesting
events unique handle onto an interested parties list along with a
CRC. Upon an attempt to commit, you compare the stored event handle's
CRC to real objects CRC. Problem: How reliable is CRC-32/64?
Worst case: the 1 in 32 billion(?) burp causes an invalid pointer
reference followed by a big thump. On reboot and reload of DB
the invalid object reference is ideally gracefully groked.
Another issue: A performance judgment on CRC calculation vs. 2nd object
copy with memory/bitwise comparison.
> An event generated IO. How do you handle when it reschedules?
> Think about things like SAY, TELL, LOOK, etc for example cases.
You also mention somewhere below about how some objects undergoing
a state change will propagate/generate events (likely asynchronously).
I see these objects being very similar and/or handy with IO.
Maybe it's possible for either the DB manager or the VM to post
the object state change events to the event scheduler after the
point of a successful transaction commit.
This might require another special method/object language construct.
It would handle indirect state changes as long as the room container
is the primary propagator. And yes, even a temporary "neighborhood"
object could be born from the commit and die at the end of it's
state change method *boggle*
A global CHAT object could then spawn gobs of events during its
cycle through the world.
> Okay, 50 players in a room all moving west is unlikely. How about 50
> players in or near a room, some moving out the various doors, some
> coming back into the room having left, others picking up or dropping
> various objects (changes to the contents lists), Every single event is
> now compeating for the chance to get a single unmodified copy of that
> room when it C&C's.
> Now that I've cast doom and gloom. This need not be a huge problem.
> The fix is to change the manner in which you write
> events/transactions. The requirement is to split events into the
> smallest, fastest executing, logically consistant units you can. The
> idea is that by making the runtime of an individual event as short oas
> possible the chance of collision by other events is minimised.
> Further, by making the runtime short, the probability is that what a
> given event sequence contends with on its first step will not be
> contended for on its next step. eg:
You could go to a pure event model, where ALL method references are
considered object messages which are dispatched as events. I have
doubts whether any sort of application transactional integrity
could be easily achieved with this approach, unless there is a strong
in language mechanism in place. ala StartTransaction-EndTransaction.
This takes the implicit nature of persistence out of the language.
Blech...IMO implicity==simplicity for the potential mudlib coder.
[execution priority and starvation trimmed]
I need to look at this closer.
I agree with most of this conceptually. =)
More information about the MUD-Dev