Random thoughts

[coder at ibm.net]

On 12/04/97 at 02:37 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
>> From: clawrenc at cup.hp.com

>> If the event attempts to modify the object, a new local,
>> event-specific copy of the object is made, and the changes are made to
>> that.  A copy of the original reference however is still kept.

>OK.  I had thoughts along similar lines here. The original reference MUST
>be kept by the event, or something equivalent (magic #).

Not really.  The event has an ObjectID and an associated pointer to an
in-memory cache.  The exact process was:

  Event->DB:  Gimme XXX Object.
  DB->Event:  Pointer-to-object-in-cache.

The DB is responsible for maintaining the cache.  Part of this means that
the cache contains in memory the entire working set of all currently
executing events.  This last is done via the interested party lists for
each object in the cache.

>> The event (loosely) attempts to keep track of what members of the
>> object it referenced.
>> 
>> Upon the event terminating it compares its copy of the original object
>> (the local reference) with the object that's actually in the DB (may
>> have been changed by events commiting during the current event's
>> execution).  Some intelligence is attempted here to only compare those
>> values etc which were referenced by the event.
>> 
>The updates attributes are committed only?  Or is the entire object
>replaced by the local copy?

That area is very badly broken currently.  The intention is to update only
the changed members.  

>> There is also some background intelligence here where the DB watches
>> the objects that are affected by event's C&C'ing, and will signal the
>> other events that are members of those object's interested party list
>> that they may be invalidated by the other event's C&C and so should
>> kill themselves and reschedule.

>Argh!  And I thought the event would receive a negative response from C&C
> and reschedule itself.  Now your saying that big brother DB is also
>signaling a  premature cancellation.   

No, the DB does not do any event management at all.  "Signal" was possibly
a bad choice of word.  Use "message" instead.  The DB merely informs the
Executor (who manages all executing events) of the possible invalidations. 
The Exector can then attempt to determine if the events are really
invalidated or not, kill them, reschedule them, whatever.

>I can see where this would prevent
>unnecessary  execution of event code that is fated to fail in any event. 

A base intention here is to get a failing event rescheduled as soon as
possible.  I don't want a long running event to continue running for its
full umpty second life when the system already knows as of the first
second that it was invalidated by another event's C&C.

>Perhaps your DB  would terminate event B with extreme prejudice in my
>earlier example?

Yup.  The Executor can and will terminate and reschedule invalidated
events.

>Yes CRC, or MD5 which someone happily pointed me too.  I was thinking
>that even with the overhead involved with a magic number system, it could
> be useful in creating a more generic and simpler interface to the DB.  A
>request to the Object Manager would return a reference and a CRC value. A
>request to update would supply a new object reference along with the
>original CRC.  If the CRC matches the update is committed else it fails. 
>Perhaps removing this from the event's "knowledge" checking might
>mitigate overhead issues and simplify coding? 
> 
>There is a reliability issue also.  It is possible for CRC to generate
>matches on  unlike objects, causing a potential corruption problem. 

This is fairly simply handled (and loosely matches what I do).  If the
CRC's don't match you are guaranteed that the object contents don't match. 
If they do match, you don't have that pure guarantee, so go do a manual
member-by-member comparison to make sure.

>> Yup.  This can get very interesting.  Start out viewing your language
>> system as a stack based state machine with the state determined
>> _externally_ to the machine, and it gets easier.
>> 
>Yes.  I'll buy this. 
>
>So thread that resumes execution of a task, only needs a handle to the
>task's state.  Execution of the task would continuous be changing the 
>state.  Pre-emption of task simply exits leaving the state as is current.
>Task state handles are known externally by Task manager.

Sorta.  I'm not quite that clean.  As all events are run in their own
threads, and that thread is private to that event, I don't actually have
context shift support in the language (don't need it), so I have no
"resume" support.  As far as the event is concerned, it is a compleately
distinct self-contained process.  

What this means is that the process state is not embedded in the language
processor, but is stored outside in the event.  The language just provides
the machine.  The event runs on the machine with the machine state stored
in the event.  

>Kewlio! (did I say that?)  This is MVS without registers!

<kof>

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...