[e-lang] What is defensive consistency?

[Dean Tribble]

On 10/31/07, David Wagner <daw at cs.berkeley.edu> wrote:
>
> Can anyone help me pin down the definition of defensive consistency in
> an object-capability language (such as E, Joe-E, etc.)?  I've lately come
> to realize that I don't understand the concept as well as I thought I did.


That's probably true of all of us :)

Ok so far, I think, but what's the definition of a client?


How's this for a definition: A client is  a holder of the capability with an
independent interest from the holders of the capability. That's a very
general distinction, but I think that's OK. Within a security domain, I
would still want to be able to separately analyze (the reliance sets of)
multiple clients of the same object.

... How do I tell when an object or pair of objects should count as
> two different clients as opposed to a single client?  Put another way,
> what is the granularity of the failure domain?


I think those are two separate questions. Reliance analysis is useful at
lots of levels of a system. A FileSystem object should support failure
isolation among its clients, even though all it's clients are in the same
"failure domain" when the file system itself is included.

Hashtable is a little strange as an example: it's primarily about mutating
and querying, and it's useful semantics are about the combined sequence of
operations from all clients. Thus, it provides little useful correctness
isolation. Indeed, the "failure domain" would include all clients of the
Hashtable. That suggests and interesting category of abstraction: ones for
which consistency requirements span multiple operations (e.g.,
open-use-close, or add-iterate-remove). Defensive consistency would require
that the operations have some unforgeable token (into which the dependent
operations should typically be refactored) to ensure that operations from
another client could not interfere with the dependent sequences of
operations. Some of your questions need to be looked at differently
depending on whether considering consistency of individual operations or
sequences of operations.

I hope these aren't stupid questions.  I read back through MarkM's PhD
> thesis, which is my standard reference for capability concepts like this,
> but I couldn't figure out how to infer the answer to these questions.
>

No, they are quite interesting (though I need to get back to the EQ thread
:).

Some examples:

Logger: Instances provide operations to efficiently format and output
messages, and perhaps provides some assurance that log messages are
persisted. Defensive consistency would require for example:

   - log records are not corrupted by concurrent log requests from other
   clients.
   - log records are not exposed to other clients.

FontManager: instances find, load, and cache fonts for a UI system; they
encapsulate file and network authority, but use it in a very restricted
fashion. Each widget, panel, window, and independent application could use
the same instance if it is defensively consistent. Ignoring resource issues,
the only thing a client can do is cause an additional font to be
conveniently cached.

CallbackSequencer: register a semaphore and a callback, and get back a
revoker. When the semaphore is signaled, the callback is invoked in another
turn, unless the revoker is invoked first.  If the implementation is
defensively consistent, then any number of clients can use a single
instance. For example, each client can only revoke callbacks that they
scheduled.  An example of a failure to be defensively consistent would be if
the implementation internally used object identity for removal: if two
clients registered the same handle or callback, then perhaps revoking one
would revoke the other.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20071031/c25fc56e/attachment.html