POS

[BRIAN SPILSBURY]

MD> Sorry for murdering the language here, what I want is something that has
MD> executional persistence.

If you mean by this that if when I have 10 threads going, and I shutdown and
and restart then I still have those ten threads running, then I'm looking
for the same thing.

I've actually implemented such a system in C a long time ago, but I'm not sure
if I handled threads in it, probably not, it was more for a byte-level
persistent virtual memory system with damand paging.

But then I've written user level threading systems with set/getjmp,
itimers for interrupts, multiple stacks allocated in the heap.
So I know that mating the two will work quite happily.

MD> My point is that it could be possible to preserve the stack, etc. by
MD> going fuzzy on granularity.  Also, I have a tendency to think in terms of
MD> the likely nuts of bolts of the thing; if it is coded throughout as
MD> transactions, then there's the option of having a mode where there is
MD> atomicity.
MD> 
MD> BS> If you look at the solution I'm
MD> BS> proposing its not hugely different from your example up there,
MD> BS> except that its a more genearl case, and doesn't try to call page
MD> BS> flushes transactions, it reserves that for world-global
MD> BS> synhronization.
MD> 
MD> What is world-global synchronization and how does it occur?
MD> Alternatively, how does one deal with disjointness in data?

Well, its a word I just made up, but it means when the world is in a
synchronous state, ie no disjointedness in the data - because we have
commited the state so far. This is sounding to me like your fuzzy
transactionness.

In the idea I'm pushing persistence of execution becoems trivial since
the entire byte-level is being persisted, including your stacks,
garbage, etc.

I wouldn't want to confuse this with transactions at the object (as opposed
to byte) level, since to do that is to go mad.

Instead I would look at fine-grain object-level persistence as a way to ensure
that even if the world gets disjoint, the objects in that transactional store,
and the relations thereof are necessarily not disjoint.

But you pay for what you get. At the byte level, commits are few and far
between and quite expensive, but we can cheaply minimize the level of
disjointedness in this layer by minimizing the number of dirty pages
in our cache when we have spare cycles/bandwidth. We get a level of
reliability, but no guarantees. something pretty close to what you get in
most unix boxes, if you turn the power off when stuff is happening,
you'll likely lose some state, but more of the time you'll have enough to
recover.

With an object-level transactional store implemented over this, if we can
ask the byte-level system to ensure that certain pages _may not_ be
dirty and _any point in time_, then its pretty simple to put a robust
arbitrary db with guaranteed consistency at all times unless you get
hardware corruption, or something else that you can't do anything about.

I have a feeling that we're probably talking about roughly the same thing
in practice.but with details that need working out to make either
approach sane and representative.

Brian