Movatterモバイル変換


[0]ホーム

URL:


Jump to content
WikipediaThe Free Encyclopedia
Search

RC 4000 multiprogramming system

From Wikipedia, the free encyclopedia
Technological System (Discontinued)
This article includes alist of references,related reading, orexternal links,but its sources remain unclear because it lacksinline citations. Please helpimprove this article byintroducing more precise citations.(January 2019) (Learn how and when to remove this message)

Operating system
RC 4000 Multiprogramming System
DeveloperRegnecentralen
Working stateDiscontinued
Initial release1969; 57 years ago (1969)
Marketing targetResearch
Available inEnglish
Update methodCompile fromsource code
Supported platformsRC 4000
Kernel typeMicrokernel

TheRC 4000 Multiprogramming System (also termedMonitor orRC 4000 depending on reference) is a discontinuedoperating system developed for the RC-4000 third generation computer in 1969.[1] For clarity, this article mostly uses the term Monitor.

Overview

[edit]

The RC 4000 Multiprogramming System was the first attempt to break down an operating system into a group of interacting programs communicating via amessage passingkernel. RC 4000 was not widely used, but was highly influential, sparking themicrokernel concept that dominated operating system research through the 1970s and 1980s.

Monitor was created largely by one programmer,Per Brinch Hansen, who worked atRegnecentralen where the RC 4000 was being designed. Leif Svalgaard participated in implementing and testing 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 thenucleus, 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 calledpipelines or pipes. However, a large amount of fundamental code is integrated into the kernel, things likefile systems and program control. Monitor would relocate such code also, 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 itsinter-process communication (IPC). Data to be sent from one process to another was copied into an empty memorydata buffer, and when the receiving program was ready, back out again. The buffer was then returned to the pool. Programs had a very simple application programming interface (API) for passing data, using anasynchronous set of four methods. Client applications send data withsend message and could optionally block usingwait answer. Servers used a mirroring set of calls,wait message andsend answer. Note that messages had an implicit "return path" for every message sent, making the semantics more like aremote procedure call thanMach's completelyinput/output (I/O) based system.

Monitor divided the application space in two:internal processes were the execution of traditional programs, started on request, whileexternal processes were effectively device drivers. External processes were 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 theparent 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,computer multitasking was a feature of debatable value). One user could start a session in apre-emptive multitasking environment, while another might start in a single-user mode to runbatch 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.

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 amemory management unit to improve messaging by using thecopy-on-write protocol and mapping (instead of copying) data from process to process. Mach also used threading extensively, allowing the external programs, orservers 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 whenJochen Liedtke'sL4 microkernel demonstrated IPC overheads reduced by an order-of-magnitude.

See also

[edit]

References

[edit]
  1. ^"Nuclear · Lecture Note for 221".yutingwang.gitbooks.io. Retrieved10 April 2024.
Kernels
L4 family
Macintosh hosted
Psion
Amiga-type
Operating
systems
POSIX support
Unix-like
Partial
Capability-based
L4 kernel
Java virtual machine
Macintosh hosted
Unix-like
Psion
  • EPOCSymbian OS
  • Amiga-type
    Microsoft
    AIM alliance
    Frameworks,kits
    Developers
    Retrieved from "https://en.wikipedia.org/w/index.php?title=RC_4000_multiprogramming_system&oldid=1296955543"
    Categories:
    Hidden categories:

    [8]ページ先頭

    ©2009-2026 Movatter.jp