It is rare in a computer system to allocate a time slot to a user before it is time to use the resource. (By user here I mean whatever agency needs to use the resource, typically, not a person.) The LARC allocated memory bus time slots in a predetermined fashion and the hardware designer could count on access when it was his turn and simplify and optimize the design by knowing when that was. The Harvest allocated a future time slot on the data portion of the memory bus as it allocated time on the address portion of the bus. Both of these were simple examples of planning ahead.

This note is mainly about allocating time, but space cannot be ignored. I have seen operating systems that allocated time to a process when it had no RAM to allocate to that process and vice versa. The process needs RAM and time simultaneously! (I was responsible for one such blunder.) This is a classic Operations research problem but we will explore solutions here that are simpler than those proposed in the OR community.

The FireWire protocol provides for advanced bandwidth reservation that is simple enough to implement correctly. The Keykos meter mechanism provides a foundation for user code to turn the resource spigot on and off thus implementing plan-ahead policies for CPU time. The meter is a sluggish tool for millisecond allocation, however. The meter adapted resource management to capability design. One capability, the meter key, was necessary to claim time on the CPU. Another capability would measure, set limits upon and start and stop consumption of time by particular meter users.

A contract

Here is an outline for a resource contract between an operating system kernel and an application. This contract leaves considerable implementation latitude by either party.

We assume a capability to claim RAM. By “claim RAM” I mean to either own RAM or somehow negotiate periods when said RAM will be real (swapped in) with its logical contents (pages). Here is a possible contract:

A special space bank sells pages and nodes that are guaranteed to be RAM resident for durations, yet to be negotiated. We say that the bank, and the material it sells, is hot during such durations. An application could be built and perhaps debugged from such a bank while the bank is cold. When it is necessary for the application to perform on a strict schedule, the bank is made hot, after which all material sold by the bank is guaranteed to be in RAM. The application is guaranteed that no page faults for material from that bank will impede it. The application must separately insure sufficient access to CPU and other necessary resources.

I imagine that the software that delivers on such a contract would require ownership of page frames in RAM. Such ownership is not possible in the current Keykos kernel. Such a program would be responsible for not negotiating conflicting durations. Duration futures could be sold. It is not clear to me what hooks in the code of the space-bank and kernel are necessary here.