| 词条 | RC 4000 multiprogramming system |
| 释义 |
| name = RC 4000 Multiprogramming System | logo = | logo caption = | logo size = | logo alt = | screenshot = | caption = | screenshot_size = | screenshot_alt = | collapsible = | version of = | developer = Regnecentralen | family = | working state = Discontinued | source model = | released = {{Start date and age|1969}} | discontinued = | RTM date = | GA date = | latest release version = | latest release date = | latest preview version = | latest preview date = | marketing target = | programmed in = | language = | update model = | package manager = | supported platforms = RC 4000 | kernel type = Microkernel | userland = | ui = | license = | preceded by = | succeeded by = | website = | support status = | other articles = | prog_language = }} The RC 4000 Multiprogramming System is a discontinued operating system developed for the RC 4000 minicomputer in 1969. OverviewThe RC 4000 Multiprogramming System is historically notable for being the first attempt to break down an operating system into a group of interacting programs communicating via a message passing kernel. Although RC 4000 itself was not very successful it was nevertheless extremely influential, sparking the microkernel concept that dominated operating system research through the 1970s and 1980s. The system is also known as Monitor and, somewhat confusingly, simply RC 4000 depending on the reference. For clarity, this article will use the term Monitor. Monitor was created largely by one programmer, Per Brinch Hansen, who worked at Regnecentralen where the RC 4000 was being designed. Leif Svalgaard participated in the implementation and testing of Monitor. Brinch Hansen found that no existing operating system was suited to the new machine, and was tired of having to adapt existing systems. He felt that a better solution was to build an underlying kernel, which he referred to as the nucleus, that could be used to build up an operating system from interacting programs. Unix, for instance, uses small interacting programs for many tasks, transferring data through a system known as pipes. However a large amount of fundamental code is buried in the kernel itself, notably things like file systems and program control. Monitor would remove this code as well, making almost the entire system a set of interacting programs, reducing the kernel (nucleus) to a communications and support system only. Monitor used a pipe-like system of shared memory as the basis of its inter-process communications. Data to be sent from one process to another was copied into an empty memory buffer, and when the receiving program was ready, back out again. The buffer was then returned to the pool. Programs had a very simple API for passing data, using an asynchronous set of four methods. Client applications send data with Monitor divided the application space in two; internal processes were the execution of traditional programs, started on request, while external processes were effectively device drivers. External processes were actually handled outside of user space by the nucleus, although they could be started and stopped just like any other program. Internal processes were started in the context of the "parent" that launched them, so each user could effectively build up their own operating system by starting and stopping programs in their own context. Scheduling was left entirely to the programs, if required at all (in the 1960s, multitasking was a debatable feature). One user could start up a session in a pre-emptive multitasking environment, while another might start in a single-user mode to run batch processing at higher speed. Real-time scheduling could be supported by sending messages to a timer process that would only return at the appropriate time. Monitor proved to have truly terrible performance. Much of this was due to the cost of IPC, a problem that has since plagued most microkernels. Under Monitor data was copied twice for every message, and memory handling on the RC 4000 was not particularly fast. Another area of serious concern was launching and killing programs to handle requests, which happened all the time. These two areas have seen the vast majority of development since Monitor's release, driving newer designs to use hardware to support messaging, and supporting threads within applications to reduce launch times. For instance, Mach required a memory management unit to improve messaging by using the copy-on-write protocol and mapping (instead of copying) data from process to process. Mach also used threading extensively, allowing the external programs, or servers in more modern terms, to easily start up new handlers for incoming requests. Still, Mach IPC was too slow to make the microkernel approach practically useful. This only changed when Liedtke L4 microkernel demonstrated an order-of-magnitude improvement in IPC overheads. See also
References
3 : Operating systems|Microkernel-based operating systems|Microkernels |
| 随便看 |
|
开放百科全书收录14589846条英语、德语、日语等多语种百科知识，基本涵盖了大多数领域的百科知识，是一部内容自由、开放的电子版国际百科全书。