Random thoughts

[Jon A. Lambert]

> From: clawrenc at cup.hp.com
> Subject: Re: Random thoughts
> Date: Thursday, April 10, 1997 5:45 PM
> 
> C&C == Compare&Commit.  
> 
> Unfortunately I don't have a blob to cut'n'paste in on this, so here
> goes round the mulberry bush again:

This is good.  My synapses have a comparable life-cycle to your
spoof objects.  They decay rapidly over time.     :-)

> 
> I run a lockless server.  I use no read or write locking.  Events
> compete competitively to commit as transactions.  Those that lose
> reschedule, and try again.  To detail:
> 
> Events request objects from the DB.  
> 
> If the object is not in the cache, the DB loads the object.
> 
> The DB replies to the event with a read-only shared reference to the
> object.
> 
> The event is added to the "interested parties" list for the object.
> 
> 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 #).

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

For instance:

Event A requests Object X for possible update.
Event B also requests Object X for possible update.
Event A modifies attributes a,c,d on Object X.
Event B modifies attributes b,e on Object X.
Event A requests C&C which is successful and then commits.
Event B requests C&C which is also successful and then commits.

If the entire Object was updated Event B would back
out Event A's updates.  If only attribute updates occur then
you are OK.

> Should the original copy and the current-in-DB copy compare OK, then
> the event commits and all its changes in its written-to copies are
> commited atomically.  This is the Compare&Commit, or C&C.
> 
> If the C&C fail, the event is thrown away, all the copies are
> released, and the event is rescheduled.

Aye and well they should. :-)

> 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.   I can see where this would prevent unnecessary 
execution of event code that is fated to fail in any event.  Perhaps saving some
CPU with the added overhead of code complexity. 
Perhaps your DB  would terminate event B with extreme prejudice in my
earlier example?
  
I guess I prefer a kindlier, gentler DB.  You should consider the damage you
do to your events self-esteem by frustrating their attempts at execution at every
turn by a tyrannical DB manager.  This being a philosophical issue as I have yet
to measure this accurately. ;-)
  
> >I'm thinking of using a "magic-number" marking to determine whether
> >my objects are dirty in cache.  
> 
> Ala CRC?

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.  *shrug*.  A simple
memory compare might be more reliable and efficient, but not as "fun". 

> 
> >Any thoughts on multi-threading the language implementation? What
> >happens when the same objects method is called by a second thread?
> 
> Not a problem.  My language internally is thread safe (took a lot
> work, mostly me finally figuring out how much design work I really had
> to do up-front).  after that everything is handled by the
> transactional nature of the events -- Nothing inside of an event
> actually exists or is changed until C&C, so the question doesn't even
> arise.  Until that event C&C's, it really doesn't matter what the
> objects states are intal to that event.
> 
> >Does this entail writing fully renterant and reusable code in the
> >server  language implementation?
> 
> 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.

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