At 10:27 AM 2/7/96 -0500, Jonathan S. Shapiro wrote:
>The killer in all of this was keeper invocation. Domain A does a CALL
>on domain B, which must run a keeper to validate a page. Domain B
>cannot run until it is unbroken. My model had been that the keeper
>would receive an additional key indicating which domain to restart,
>which might not be the domain that was broken. In effect, domain B's
>keeper was being called by Domain A.
>
>The problem: while all this is happening, Domain B remains available.
>An instant after domain B is repaired, some third party caller gets in
>ahead of Domain A. It just starts getting messier and messier.
>
>So I went off to look at the online Gnosis doc.
>
>Reading between the lines, it appears that KeyKOS simply injects the
>fault information into the keeper and makes it runnable, effectively
>creating a new thread. The principle is that a keeper can only be
>invoked by the domain that does the invalid action. The tricky part
>is that the domain performing the invalid action may not be running at
>the time.
You have come across what I consider to be the worst design wart in the Gnosis/KeyKOS design. In that design, the situation can only occur with the parameter string. (All the other things passed in the jump are placed in the domain, whose definition can not be defered to a keeper.)
KeyKOS requires that the page(s) which are to receive the string be defined in the memory tree before the jump occurs. (I think the manual says something to the effect that the kernel views the memory tree through a NoCall segment.) Typical programs ensure this during initialization by (1) defining a real page key, or (2) warming up the string by storing in its first and last byte. Technique (2) will only work with keepers that only add pages. If the keeper removes pages (such as a keeper transparently sharing a segment across a network), the warmed up page could disappear.
Designs that avoid this flaw are complex. The simplest I know of requires that domains which want to receive strings in kept pages have a page as part of the domain to buffer the string and a bunch of additional domain/resume key hair to get it copied when the keeper returns.
Another similar problem occurs on the 68000 family with the Compare Double and Swap instruction. This instruction defines atomic read/writes on two separate addresses. These address can be kept by separate keepers. So far so good, you just keep calling the keepers until there are pages at both address. However, the 68000 also allows you to write software which instead of validating the page, just provides the data. If you try to make this hardware facility available to a keeper you run into severe design problems.
Bill Frantz Periwinkle -- Computer Consulting (408)356-8506 16345 Englewood Ave. frantz@netcom.com Los Gatos, CA 95032, USA