At a coarser abstraction level we prepare nodes somewhat like we prepare keys. One cannot tell for sure by looking in a node, what it is intended for. Nodes compose domains, segments, meters and, of course, many constructions that the kernel does not dream of.

When a start key is invoked that designates a node the kernel becomes immediately aware that that node is intended as the root of a domain. The kernel then seeks, from node keys in the root, the other nodes that compose the domain. After possibly causing some faults and re-executions of the invoker of the start key, all of the nodes of the domain will be in item space and the kernel can construct a proper domain that can attempt to obey user mode instructions. The kernel’s working domain is somewhat apart from the nodes that logically define it. See how domains are prepared for more details. If a node key is used to examine a node of the domain it is necessary to provide the correct information, even if it is only an illusion. If something should happen to these nodes it is necessary to ensure that the kernel’s domain to the node states do not part ways. It goes even further. In an MP configuration user code within one domain may consult domain state of a process running even then on another CPU. Keykos is committed to delivering current information. There must be at least the illusion of one fundamental reality. The same issues apply to meters and segments.

A node frame includes a node header with an exclusive lock, a shared lock and one byte field, the PrepCode, indicating a possible mode of preparation. The several nodes of a domain each have distinctive codes for this field. Nodes prepared as segment nodes or meters have other distinct codes. If the kernel should need to evict a node from a node frame it will need to know if it is part of something such as a domain. The PrepCode in the node frame tells.

If a node key is used to access a slot in a prepared node, several possible special cases may arise. Whether special handling is required depends on which slot and the PrepCode of the containing node. If there is special handling the key is involved. There are two modes of involvement, each with its own indicator bit in the slot: DR (don’t read) & DW (don’t write). Every key in the DR state is also in the DW state. Except for number keys, involved keys are prepared. A slot read will take a detour if the DR bit is on and a slot write if the DW bit is on. These involved bits are set when the node is prepared and reset when it is unprepared.

To read the slot, one must of course be aware of whether it is prepared as that determines the format of the remaining information. If the slot is involved DR, then the information that logically belongs in the slot is most likely elsewhere and is to be found only by code that is cognizant of the role of the slot in the prepared node. Involved keys exist only in prepared nodes and the value of the PrepCode for the containing node, and the slot number within the prepared node determine exactly what is necessary to retrieve the information that the slot logically holds. If it is necessary to change a slot in a node the DW bit warns that other data structures think that they know the current value and it is thus necessary to warn them to of any change. Usually it is just easier to unprepare the node and then the slot will hold what logically belongs there. In a few critical cases we do it the hard fast way.

If every slot access via a node key were to test the PrepCode of the node and the slot index if set, then the Involved mechanism would be unnecessary. Slot accesses are frequent, however.