Architecture of Backing Store Descriptors

[Jonathan Shapiro]

   The invocation semantics in KeyKOS include locking directly.  When two
   messages are sent to a domain, the domain receives one and the other waits.
    This seems like locking to me, and can be used to implement pretty much
   any other sequential synchronization construct.  Does KeyKOS specify
   fairness for domains waiting on a key invocation?

I believe Bryan was assuming a multithreaded domain model, which
KeyKOS does not directly support (though it can be done).  In this
model, a question arises as to how one thread should release
server-internal locks aquired by another.  I think there's a more
fundamental problem there, which is how to define the semantics of the
exceptional situation in which a thread's lock contracts have been
violated by a higher authority.

KeyKOS does not currently queue domains in priority order, though this
would be a straightforward change.  If priorities are dynamic, there
is some hair in rearranging the priority queues frequently, but it
should still be manageable.

It isn't that simple, however.  Consider that a high-priority domain
may be at the front of the queue, but by the time we get around to
running it its send data page may be paged out.  The effect will be
that on restart the high priority task ends up reloading the page
instead of getting on with useful work.

The "obvious" solution would be to implicitly pin the domain root,
general keys node, general registers node, and pages associated with
the message send and receive into memory iff the task is marked as
"real time."  A complicating factor is that we must retain enough
information to unpin these things if a debugger gronks the sleeping
process on the head (equally if the process is killed) while it's
waiting.  Further, pinned pages are a sufficiently precious resource
that they probably need to be accounted for carefully.

Therefore, I'ld prefer to go at that the other way around.  If a task
is marked real time, then it is an error if the nodes and pages listed
are NOT pinned, and a suitable exception message should be sent to the
keeper.  This places the burden back on the application, and admits
reasonable ground for accounting.  It seems to me that a correct real
time app needs to manage that burden explicitly in any case.


Jonathan