[cap-talk] Computational models vs durability, resources, synchronicity

[Jonathan S. Shapiro]

On Wed, 2007-01-03 at 17:07 -0800, Jed Donnelley wrote: 
> >I claim that this is merely the beginning of a model for computation,
> >and that it lacks, among other things, in the words of Jonathan,
> >considerations of:
> >
> >    "durability, resource exhaustion, and synchronicity"
> >
> >In other words, it lacks *anything* related to the question of
> >executing instructions on a real machine architecture.
> 
> Hmmm.  I'm afraid I don't understand what you're getting at.
> In the object-capability model processes are assumed to
> execute the instructions of their underlying processor
> architecture in their own memory except for the "invoke"
> instruction...

Neither durability nor resource exhaustion can be addressed entirely at
a higher level.

Computation does not occur for the purpose of executing instructions.
Instructions are executed for the purpose of achieving computation. We
execute instructions for the purpose of having an effect on the system
state in order to achieve a computation. In doing so, we rely on the
operational semantics of the instruction(s) and the durability
properties of the system state. For example:

  - we rely on the assumption that a word stored to a location can later
    be re-fetched, provided it has not been overwritten in the
    intervening time. This is a durability property.

  - we rely (in many machine definitions) on the assumption that the
    storage allocating operation 'new' does not fail, or if it fails
    we rely on the presence of a robust error signalling mechanism.

This is all fairly easy to conceptualize in the context of something
like a JVM, or any system in which resources are not accounted for. When
we switch to an OS view, things become (sadly) more interesting.

Consider the memory durability assumption. In an OS, that memory is
backed by real storage, and that real storage may be revocable. If the
underlying storage is revoked, the ability to re-load previously stored
values is violated. To account for this, we must re-frame our
computational model to somehow deal with this fact (presumably by
signaling an error/exception).

The memory durability failure in the OS case is particularly pernicious,
because in among other things it violates the durability of *code* which
means we cannot rely on our error handlers to run.

So no, I do not think that the durability and resource issues can be
dealt with (or at least, not entirely) at a higher level in a resource
reifying system. They are intimately intertwined with the
instruction-level model of computation.

More precisely: this is an issue in any system having explicit and
prompt revocation.


As a counter-example, UNIX uses reference counting, with the effect that
the memory durability properties of the computational model are never
hazarded. With regard to the computational model this is a *vast*
simplification, but the cost of it is that one risks denial of resource
whenever one engages in resource sharing.

Having started with a simpler computational model, UNIX then "fixed"
this advantage by introducing mprotect() and munmap(), which have much
the same effect on the computational model that explicit and prompt
revocation has.

-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100