[MUD-Dev] C&C and Event Rescheduling

[clawrenc at cup.hp.com]

In <33D8DED4.41C67EA6 at iname.com>, on 07/25/97 
   at 10:15 AM, Shawn Halpenny <malachai at iname.com> said:

>clawrenc at cup.hp.com wrote:

>> In <33D63D8C.167EB0E7 at iname.com>, on 07/23/97
>>    at 09:53 PM, Shawn Halpenny <malachai at iname.com> said:

>[ determining object has changed during event execution ]

>Yes.  While pondering this stuff yesterday I'd thought about a
>counter that keeps track of the number of attribute-writes for that
>object.  Should it have changed by the time the next commit comes
>around, then do a comparison (actually, if the count is different,
>isn't it safe to assume that _some_ attribute was changed, therefore
>don't do a comparison at all?)

Yup, and this would be more efficient than my suggestions.

>> >Do your
>> >events keep track of the attributes they touch or is that handled
>> >entirely by the DB?
>> 
>> This is currently in a mess.  Actually that's an understatement.  I'm
>> partially dug into Arjuna to use it as a persistant store.  Part and
>> parcel of this idea would be devolving MUD objects at the storage into
>> individual objects, one each per attribute and method.  Its then a
>> simple matter of flagging the references at runtime to resolve what
>> bits got checked/changed ans what didn't.

>I've taken a cursory look at Arjuna, but I'm not sure that I'm
>comfortable with every object being stored in its own file (doesn't
>that turn into a linear search for an object, given its ID?).  It
>seems to be a well-designed piece of software, though.

They use individual files per object type.  I forget how they do
indexing, but it didn't seem *too* bad.  I was (its been a while since
I've had a chance to look at them) however very concerned with their
pessimal cacheing.

>Making each attribute and method into an object is interesting.  It
>would certainly simplify C&C, since there's no longer a need for
>attribute checking.  Have to look into that.

Nahh, I'd still do attribute checking -- only I'd only check the
attribute that were referenced or changed.  Thus the contention is
devolved down to the individual attributes on objects.  This doesn't
help the worst case (50 players decide to move from room A to room B),
but it should help with the majority of contentions.

>> >Is there a problem with a situation where a
>> >single object with attributes touched by two events within the
>> >duration of a third event using the same object could cause some
>> >attributes touched by the third event to falsely pass the comparison?
>> 
>> Yes, but I don't consider this a problem:

>[ example elided ]

>> Logically interesting I'll admit, but not a problem that I can see.

>True, not a problem and interesting as you say.  For some reason it
>bothers me, though, but is probably something I could live with (and
>wouldn't have to consider if I counted commits or attribute changes).

It bothered me until I admitted to myself that I couldn't think of a
negative impact.

>> >>   Re: #7.  Similarly I post messages (flags really) to all the members
>> >> of the interested parties lists for all the objects that a
>> >> successfully committed transaction modified.  The effect of those
>> >> flags is that the next time those events traverse a block boundary
>> >> (essentially any piece of code wrapped in {braces}, such as entering
>> >> or leaving an IF, or WHILE etc), the flag gets checked and if TRUE,
>> >> the event aborts to reschedule.
>> 
>> >I do much the same, using the exception mechanism of the internal
>> >language.
>> 
>> I explicitly didn't put this in the language exceptions as once an
>> event compleats and attempts C&C there' no language running to receive
>> the exception.  A new event would have to be started to catch the
>> exception...

>But the event that is being killed and rescheduled is active when the
>C&C fails...

Not for me.  The event is done and cleared out.  It is *gone*.  The
Executor then signals the dispatchor that it wants to C&C, get the
pass/fail on the C&C and proceeds accordingly.

>...in the case where other events have to be notified that an
>object they were using has changed.  

That's handled by the DB which alsready maintains the interested party
lists.  After all, its the only one who knows who has what.

>Those events get the exception. 

I guess I could do this, but my exception code really isn't built for
it and its also a waste of processing.  Why have the stack unwind when
you already know that the event is going to C&C?  I have the executor
order the executing thread to kill and flush the event, and then it
prepares for the next event off the queue.  Boom!  Its dead, gone, and
the next one is being processed.  The event itself doesn't care -- it
will get rescheduled, and it caused no permanent effeects (it never
C&C'ed), so there are no costs or side-effects to slaughtering it
outright.  The VM for the event has no permanence, so it just resets
to initial state and awaits the next event off the queue..

>I'm not quite happy with this either...I think I can tie it to my
>notification stuff below (which is similar to your flags above) and
>make it simpler (and uniform) overall.

I'm interested.

>> Consider:
>> 
>>   Player A types, "get axe".
>> 
>>   Event 1 runs the "get axe" code.
>> 
>>   Event 1 issues the IO, "You pick up the axe." back to the player.
>> 
>>   Player B picks up the axe.  This event sucessfully commits.
>> 
>>   Event 1 then tries to C&C, fails, reschedules, and pops back with
>> "What axe?"
>> 
>>   Meanwhile the player A sees:
>> 
>>     > get axe
>>     You pick up the axe.
>>     B picks up the axe.
>>     What axe?
>>     > i
>>     ...no axe...
>> 
>> >Handling commands where events that have to touch a number of objects
>> >that have likely changed by the time the event is processed isn't
>> >something I've worked on yet.  Therein lies the difficulty.
>> 
>> Its worth attention.

>Yep.  Haven't got to it yet.  Current thinking:  output should be
>queued and then displayed when the event successfully commits, or
>displayed immediately when a condition necessary for a successful
>commit fails (i.e.  someone already picked up the axe).

I buffer all IO and release only upon successful commit.  If it never
commits, it never releases the IO.

>>   How do you handle broadcasting state changes to other objects?

>The following is my first take on this, since until this point I had
>only said that there needs to be some way of notifying other objects
>of state changes:

>Post an event to call the notification method on each interested
>object. 

How do you know who is interested?  Where is that data maintained, and
how does it get there?  Does the notification enclude what changed, or
just that there was a change?

>Only a single instance of this method needs to be running at
>a time, since the event will now handle further state changes by way
>of the C&C mechanism and thus keep retrying the notification code
>until it completes.  So, the event is only posted if the notification
>method that is called is not already being executed (this is
>maintained by a bit in a bit field within the object).

What about if an object has watches on multiple other objects?

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