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