Random thoughts

[clawrenc at cup.hp.com]

In <199704080234.CAA489247 at out2.ibm.net>, on 04/07/97 
   at 10:33 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said: >>
From: coder at ibm.net
>> On 05/04/97 at 06:02 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:

>> >> > How does this handle the Dragon's Dinner scenario, ala:
><snipped  - you've probably put us all through it :-) >
>> 
>> For me there actually is no problem as the general area is resolved by my
>> lockless/retry model (the old C&C business I detailed, Oh, about 6 - 8
>> postings ago -- I'll repost if needed.).  Essentially the two events
>> execute in parallel, but one gets to C&C first and commits, the other then
>> fails C&C, and retries/reschedules.  This only works becuase all events
>> only modify and access local data prior to C&C.
>> 
>Concerning the C&C (copy and compare(?)):

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:

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.

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.

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.

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.

>The DB is not comparing the object on an element by element basis, is
>it? Is it doing a memory contents comparison?
>Does the object contain a "magic number"?
>Does this copy and compare include object method code? 

>I'm thinking of using a "magic-number" marking to determine whether
>my objects are dirty in cache.  

Ala CRC?

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

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