[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <33C69FC6.41C67EA6 at iname.com>, on 07/11/97 
   at 02:07 PM, Shawn Halpenny <malachai at iname.com> said:

>Roughly:
>1.  A client requests object O from the database. 
>2.  Return OC (a client-only copy of O) to the client. 
>3.  The client returns OC' after some munging. 
>4.  If no changes have been made to O since the request was made
>    (a different client request may have committed changes to O
>    while OC' was being created), OC' is atomically committed to
>    the database and notification of success is returned to the
>    client. 
>5.  If O has changed, OC' is thrown away and the client receives
>    notification that OC' could not commit.

This is pretty well identical to my model.  Concerns:

  Most events modify more than one object.  eg Bubba (object X) moves
from room A to room B.  Minimally objects A, B, and X will be modified
by this event (containment pointers/lists).

  How do you intend to handle the cases of an event requesting object
Q just to check the value of a data member (ie no modification), where
that data member has then been changed by the time the event commits
(see the dragon's dinner example, and look at the door)?

  Do you have a concept of a "transaction" where a transaction is
effectively synonymous with an event, and involves the possible
requesting of read-only copies of N objects, and the possible
modification of M objects where M is a subset of N?  What I'm looking
for here is the idea that a transaction or event can only commit if
all of its component objects resolve correctly to their commit state
(ie everything compares right).

  What about the case of an object with two attributes, say object A,
with attributes A::X, and A::Y.  Two events, Q and R, then occur.  Q
modifies the value of A::X.  R modifies the value of A::Y.  Both
events run simultaneously and commit in arbitrary order.  Should one
event fail and be rescheduled?

  You can take this last case and instead of having both events modify
the attributes, instead have one modify one value, and the other do a
read-only check, or have one do a read-only check of A::X while the
other modifies it.

>An event is the client and if it finds out OC' couldn't commit, the
>event is immediately rescheduled.

>Now assume we have event A and B trying to commit object O.  A and B
>first occur at the same time.  Event A's changes to O take twice as
>long as B's changes to O, so B commits first, causing A to
>reschedule.

>Say that the system is generating event B's like a mad bastard. It
>seems to me that in some cases, it would be possible (though
>unlikely) that event A will never be able to commit its changes,
>since the continuous committing of event B's changes prevents A from
>ever finishing.

This is a problem, and a not necessarily infrequent one.  eg. Put 50
users in a room.  Have them all move to the next room at the same
time.  Now consider that the source room, the target room, and each
user's object is being touched by each event.

>Is that possible?  And if so, what's an elegant solution?  (Timed
>delay on B's next attempt at committing?  Block B until A commits? 
>Reschedule A with higher priority?)

I don't have a pure solution.  I (rough memory) follow the following
course:

  A rescheduled event is given a higher than default priority.  All
this means is that it gets first crack at getting a thread to execute
on as versus a "normal" event which will have to wait until all
higher-priority events have threads.

  A 5*rescheduled event forces the Executor to cease assigning events
to threads until the 5*rescheduled event terminates.

  A 10*rescheduled event (I think its 10) forces the Executor to cease
assigning events to threads until the 10*rescheduled event
successfully terminates (ie it heads toward and finally goes into
single-tasking mode).

  A 20*rescheduled event (have no idea what the real number is)
signals all other executing events to block until this event has
terminated.  This just shuts down the multi-threading until the event
has run.  

Note: Events have a very short maximum time they must execute within. 
Event's which take longer than that time are killed and not
rescheduled.  This maximum time is reduced as events are rescheduled
and ascend the above priority list (ie I give them more chance to get
their job done, but less time to do it).

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...