THE multiprogramming system
|Developer||Technische Hogeschool Eindhoven / Edsger Dijkstra (et al.)|
|Written in||Electrologica X8 assembly language|
The THE multiprogramming system or THE OS was a computer operating system designed by a team led by Edsger W. Dijkstra, described in monographs in 1965-66 and published in 1968. Dijkstra never named the system; "THE" is simply the abbreviation of "Technische Hogeschool Eindhoven", then the name (in Dutch) of the Eindhoven University of Technology of the Netherlands. The THE system was primarily a batch system that supported multitasking; it was not designed as a multi-user operating system. It was much like the SDS 940, but "the set of processes in the THE system was static".
The THE system apparently introduced the first forms of software-based paged virtual memory (the Electrologica X8 did not support hardware-based memory management), freeing programmers from being forced to use actual physical locations on the drum memory. It did this by using a modified ALGOL compiler (the only programming language supported by Dijkstra's system) to "automatically generate calls to system routines, which made sure the requested information was in memory, swapping if necessary". Paged virtual memory was also used for buffering I/O device data, and for a significant portion of the operating system code as well as nearly all of the ALGOL 60 compiler. In this system itself, semaphores have been used as a programming construct for the first time.
The design of the THE multiprogramming system is significant for its use of a layered structure, in which "higher" layers only depend on "lower" layers:
- Layer 0 was responsible for the multiprogramming aspects of the operating system. It decided which process was allocated to the CPU, and accounted for processes that were blocked on semaphores. It dealt with interrupts and performed the context switches when a process change was required. This is the lowest level. In modern terms, this was the scheduler.
- Layer 1 was concerned with allocating memory to processes. In modern terms, this was the pager.
- Layer 2 dealt with communication between the operating system and the console.
- Layer 3 managed all I/O between the devices attached to the computer. This included buffering information from the various devices.
- Layer 4 consisted of user programs. There were 5 processes: in total, they handled the compilation, execution, and printer of users' programs. When finished, they passed control back to the schedule queue, which was priority-based, favoring recently started processes and ones that blocked because of I/O.
- Layer 5 was the user (as Dijkstra notes, "not implemented by us").
The constraint that higher layers can only depend on lower layers was imposed by the designers in order to make reasoning about the system (using quasi-formal methods) more tractable, and also to facilitate building and testing the system incrementally. The layers were implemented in order, layer 0 first, with thorough testing of the abstractions provided by each layer in turn. This division of the kernel into layers was similar in some ways to Multics' later ring-segmentation model. Several subsequent operating systems have used layering to some extent, including Windows NT and macOS, although usually with fewer layers.
The code of the system was written in assembly language for the Dutch Electrologica X8 computer. This computer had a word size of 27 bits, 32 kilowords of core memory, 512 kilowords of drum memory providing backing store for the LRU cache algorithm, paper tape readers, paper tape punches, plotters, and printers.
- Dijkstra, Edsger W. The structure of the 'THE'-multiprogramming system (EWD-196) (PDF). E.W. Dijkstra Archive. Center for American History, University of Texas at Austin. (transcription) (Jun 14, 1965)
- Dijkstra, E.W. (1968), "The structure of the 'THE'-multiprogramming system", Communications of the ACM, 11 (5): 341–346, doi:10.1145/363095.363143
- Silberschatz, Abraham; Peterson, James L. (May 1988), "13: Historical Perspective", Operating System Concepts, p. 512