Web site: (not active)
Origin: Denmark
Category: Microkernel
Desktop environment: CLI
Architecture: unknown
Based on: Independent
Wikipedia: RC_4000_multiprogramming_system
Media: Install
The last version | Released: 1980 (?)
RC 4000 Multiprogramming System – an operating system developed for the RC 4000 minicomputer in 1969. It is historically notable for being the first attempt to break down an operating system into a group of interacting programs that communicate through messages passed through the kernel. Although the RC 4000 was not very successful, it was highly influential, giving rise to the microkernel concept that dominated operating system research throughout the 1970s and 80s. This system is also known as Monitor, and we will use that term in this article.
Monitor was largely created by Per Brinch Hansen, who worked at Regnecentralen, where the RC 4000 was ultimately designed. Leif Svalgaard participated in the implementation and testing of Monitor. Brinch Hansen found that there was no suitable operating system for the new machine and was tired of having to adapt existing systems to it. In his view, the best solution was to build an underlying kernel, which he referred to as the core, that could be used to build an operating system of interacting programs. Unix, for example, uses small, interacting programs for many tasks, transferring data through a system known as pipes. However, a great deal of fundamental code is buried in the kernel itself, particularly things like file systems and program control. The Monitor would eliminate this code by making almost the entire system a set of interacting programs, reducing the kernel to a single communication and support system.
The Monitor uses a shared-memory pipe system as the basis for its own inter-process communication. Data sent from one process to another is copied into an empty memory buffer, and when the receiving program is ready, it sends it back. The buffer is then returned to the pool. Programs have a very simple API for passing data, using a set of four asynchronous methods. Client applications sent data using `send message` and could optionally block it using the `wait answer` code. Servers used a series of calls: `wait message` and `send answer`. Messages had an implicit “return path” for each message sent, making the semantics more akin to a remote procedure call than a Mach I/O system.
The Monitor divided application space into two: “internal processes,” which were traditional programs that started on demand, and “external programs,” which were efficient device drivers. External processes were actually handled outside of user space by the kernel, although they could start and stop like any other program. Internal programs started with the context of the “parent” program that launched them, so each user could create their own operating system by starting and stopping programs within their own context.
Scheduling was left entirely to the programs themselves if they required it (in the 1960s, multitasking was a debatable feature). One user could log into a preemptive multitasking environment, while another could start in single-user mode to run batch processing at higher speeds. Real-time scheduling could be supported by sending messages to a timer process that would only return at the appropriate time.
The Monitor proved to have truly terrible performance. Much of this was due to the cost of inter-process communication (IPC), a problem that has plagued most microkernels. Monitor data had to be copied twice for each message, and memory management in the RC 4000 was not particularly fast. One area of concern was launching and terminating programs to handle the constant stream of requests.
These two areas have seen the vast majority of development since the Monitor’s release: developing new designs to utilize the hardware for messaging support and supporting threads within applications to reduce launch times. For example, Mach requires a memory management unit to improve messaging by using copy-on-write and allocation protocols (instead of copying data) from one process to another. Mach is also used extensively for threading, allowing external programs or servers (in more modern terms) to initiate new handlers to receive requests. However, Mach’s IPC was too slow to make the microkernel approach practically viable. This changed when Liedtke’s L4 (microkernel) demonstrated an order-of-magnitude improvement in inter-process communication overhead (IPC).
Source: Wikipedia; License: Creative Commons Attribution-ShareAlike 4.0.
