"Chris M. Thomasson" <inv...@invalid.invalid> writes:
> BTW, did Charlie also invent the idea of using an extra counter to
> make the CAS fail when an A, to B, back to A encounter occurs? To
> avoid destroying the data-structure?
the original CAS examples were simpler structures ... that didn't
require version sequencing (single threaded list, double threaded list,
counters, etc).
first time I remember working with similar version sequencing was late
80s for our HA/CMP project ... and cluster scaleup ... working with
national labs on technical and scientific and RDBMS vendors on
commercial scaleup.
Some of the RDBMS vendors had vax/cluster support in the same source
base as the support for other platforms. The easiest way to extend that
support to HA/CMP was doing a DLM that implemented vax/cluster
semantics. However the RDBMS vendors had some thots on how to
significantly improve over vax/cluster implementation ... and I had some
ideas dating back to having worked on the original sql/relational
implementation.
A non-cluster RDBMS improvement was fast commit ... release record-level
lock as soon as the corresponding journal record had been written
... even though the DBMS record hasn't been written (and roll journal
forward in case of recovery). The vax/cluster implementation wouldn't
pass the lock to another cluster processor until the corresponding DBMS
record had been written, and it would then have to read the DBMS from
disk. So I sought to extend "fast commit" to cluster operation
... piggy-backing the record in transmission granting the lock to a
different processor. This then requires merging journal records from the
different cluster processors in the original transaction execution
order. Because didn't have cluster wide synchronized timer, went with
transaction version number ... that was transmitted with granting the
lock and current record value (academic papers sometimes refer to it as
virtual time in recovery with distributed logs/journals).
trivia ... old reference to Jan1992 meeting in Ellison's conference room
regarding cluster scaleup
http://manana.garlic.com/~lynn/95.html#13
then for a number of reasons, over a couple weeks, cluster scaleup was
transferred, announced as supercomputer (for technical and scientific
*ONLY*) and we were told we couldn't work on anything with more than
four processors. Old press item from 17Feb1992:
http://manana.garlic.com/~lynn/2001n.html#6000clusters1
and later from press from 11May1992
http://manana.garlic.com/~lynn/2001n.html#6000clusters2