RC 4000 multiprogramming system: Difference between revisions
No edit summary |
Jerryobject (talk | contribs) MOS:DATETIES Template:Use dmy dates. Template:Infobox OS, WP:REFerence WP:CITations > parameters: updates, reorders, adds, fills, author > last + first. WP:LEADSENTENCE MOS:BOLDSYNonyms moved after title term 1st instance. Small WP:EoS WP:TERSE WP:COPYEDITs; WP:IDIOM > WP:FORMAL. WP:LINKs: adds, updates, fix needless WP:PIPEs (WP:NOPIPEs). MOS:FIRSTABBReviations define before WP:ABBRs in parentheses. WP:NAVBOX update. |
||
Line 1: | Line 1: | ||
{{No footnotes|date=January 2019}} |
{{No footnotes|date=January 2019}} |
||
{{Use dmy dates|date=September 2021}} |
|||
{{Infobox OS |
{{Infobox OS |
||
| name |
| name = RC 4000 Multiprogramming System<!-- Name of program or distribution --> |
||
| logo |
| logo = <!-- Filename only, no wikilink, Image:, or File: --> |
||
| logo caption |
| logo caption = |
||
| logo size |
| logo size = |
||
| logo alt |
| logo alt = |
||
| screenshot |
| screenshot = <!-- Filename only, no wikilink, Image:, or File: --> |
||
| caption |
| caption = |
||
| screenshot size = |
|||
| screenshot_size = |
|||
| screenshot alt = |
|||
| screenshot_alt = |
|||
| developer = [[Regnecentralen]] |
|||
| collapsible = |
|||
| family = <!-- "Unix-like" or "Microsoft Windows" --> |
|||
| version of = <!-- For articles about releases of operating systems ONLY --> |
|||
| working state = Discontinued |
|||
| developer = [[Regnecentralen]]<!-- Name of main developer or sponsor--> |
|||
| |
| source model = <!-- "Open source", "Closed source" --> |
||
⚫ | |||
| working state = Discontinued<!-- "Current", "Discontinued" (operating systems), or "No longer supported" (releases) --> |
|||
| discontinued = Yes |
|||
| source model = <!-- "Open source", "Closed source", or "Shared source" --> |
|||
⚫ | |||
| discontinued = <!-- DON'T use this for articles about releases of operating systems --> |
|||
| RTM date = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} ONLY for articles about OS releases --> |
|||
| GA date = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} ONLY for articles about OS releases --> |
|||
| latest release version = |
| latest release version = |
||
| latest release date = |
| latest release date = <!-- {{Start date and age|197y|mm|dd|df=yes}} --> |
||
⚫ | |||
| latest preview version = |
|||
⚫ | |||
| latest preview date = <!-- {{Start date and age|YYYY|MM|DD|df=yes/no}} --> |
|||
| language = English |
|||
⚫ | |||
| update model = Compile from [[source code]] |
|||
⚫ | |||
⚫ | |||
| language = <!-- Supported human languages (English, French, Italian, Arabic, ...) --> |
|||
| kernel type = [[Microkernel]] |
|||
| update model = <!-- APT, Windows Update, etc. --> |
|||
| userland = |
|||
| package manager = <!-- dpkg, rpm, Windows installer, etc. --> |
|||
| ui = |
|||
⚫ | |||
⚫ | |||
| kernel type = [[Microkernel]]<!-- Hybrid, Monolithic, Microkernel, Exokernel, Nanokernel, etc. --> |
|||
| |
| preceded by = |
||
| |
| succeeded by = |
||
⚫ | |||
⚫ | |||
⚫ | |||
| preceded by = |
|||
| succeeded by = |
|||
⚫ | |||
| support status = <!-- For articles about releases of operating systems ONLY --> |
|||
⚫ | |||
| prog_language = |
|||
}} |
}} |
||
The '''RC 4000 Multiprogramming System''' is a discontinued [[operating system]] developed for the |
The '''RC 4000 Multiprogramming System''' (also termed '''Monitor''' or '''RC 4000''' depending on reference) is a discontinued [[operating system]] developed for the RC 4000 [[minicomputer]] in 1969. For clarity, this article mostly uses the term Monitor. |
||
==Overview== |
==Overview== |
||
The 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]] [[ |
The 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 (operating system)|kernel]]. RC 4000 was not widely used, but was highly influential, sparking the [[microkernel]] concept that dominated operating system research through the 1970s and 1980s. |
||
Monitor was created largely by one programmer, [[Per Brinch Hansen]], who worked at [[Regnecentralen]] where the RC 4000 was being designed. |
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 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 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 called ''[[Pipeline (Unix)|pipelines or pipes]]''. However, a large amount of fundamental code is integrated into the kernel, notably things like [[file system]]s 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 its [[inter-process communication]] |
Monitor used a pipe-like system of shared memory as the basis of its [[inter-process communication]] (IPC). Data to be sent from one process to another was copied into an empty memory [[data 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 an [[wikt:asynchronous|asynchronous]] set of four methods. Client applications send data with <code>send message</code> and could optionally block using <code>wait answer</code>. Servers used a mirroring set of calls, <code>wait message</code> and <code>send answer</code>. Note that messages had an implicit "return path" for every message sent, making the semantics more like a [[remote procedure call]] than [[Mach (kernel)|Mach's]] completely [[input/output]] (I/O) based system. |
||
Monitor divided the application space in two |
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 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 (computing)|Scheduling]] was left entirely to the programs, if required at all (in the 1960s, [[computer |
[[Scheduling (computing)|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 a [[pre-emptive multitasking]] environment, while another might start in a single-user mode to run [[batch processing]] at higher speed. [[Real-time computing|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 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 family|L4 microkernel]] demonstrated an order-of-magnitude |
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 [[Jochen Liedtke]]'s [[L4 microkernel family|L4 microkernel]] demonstrated IPC overheads reduced by an order-of-magnitude. |
||
==See also== |
==See also== |
||
Line 61: | Line 53: | ||
==References== |
==References== |
||
*{{cite journal | |
*{{cite journal |last=Hansen |first=Per Brinch |year=1970 |title=The Nucleus of a Multiprogramming Operating System |url=http://www.brinch-hansen.net/papers/1970a.pdf |journal=Communications of the ACM |volume=13 |issue=4 |pages=238–250 |publisher=[[Association for Computing Machinery]] |doi=10.1145/362258.362278 |citeseerx=10.1.1.105.4204}} |
||
*[http://brinch-hansen.net/papers/1969a.pdf RC 4000 Software: Multiprogramming System] |
*[http://brinch-hansen.net/papers/1969a.pdf RC 4000 Software: Multiprogramming System] |
||
*[http://bitsavers.org/pdf/regnecentralen/RC_4000_Reference_Manual_Jun69.pdf RC 4000 Reference Manual] at bitsavers.org |
*[http://bitsavers.org/pdf/regnecentralen/RC_4000_Reference_Manual_Jun69.pdf RC 4000 Reference Manual] at bitsavers.org |
||
{{ |
{{Microkernel}} |
||
<!--[[Category:Operating systems]] delete. Mickrokernels is a subcat of this --> |
|||
[[Category:Microkernel-based operating systems]] |
[[Category:Microkernel-based operating systems]] |
||
[[Category:Microkernels]] |
[[Category:Microkernels]] |
Revision as of 10:23, 8 September 2021
![]() | This article includes a list of references, related reading, or external links, but its sources remain unclear because it lacks inline citations. (January 2019) |
RC 4000 Multiprogramming System | |
---|---|
Developer | Regnecentralen |
Working state | Discontinued |
Initial release | 1969 |
Marketing target | Research |
Available in | English |
Update method | Compile from source code |
Platforms | RC 4000 |
Kernel type | Microkernel |
The RC 4000 Multiprogramming System (also termed Monitor or RC 4000 depending on reference) is a discontinued operating system developed for the RC 4000 minicomputer in 1969. For clarity, this article mostly uses the term Monitor.
Overview
The 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. RC 4000 was not widely used, but was highly influential, sparking the microkernel concept that dominated operating system research through the 1970s and 1980s.
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 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 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 called pipelines or pipes. However, a large amount of fundamental code is integrated into the kernel, notably things like file 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 its inter-process communication (IPC). Data to be sent from one process to another was copied into an empty memory data 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 an asynchronous set of four methods. Client applications send data with send message
and could optionally block using wait answer
. Servers used a mirroring set of calls, wait message
and send answer
. Note that messages had an implicit "return path" for every message sent, making the semantics more like a remote procedure call than Mach's completely input/output (I/O) based system.
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 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, computer multitasking was a feature of debatable value). One user could start 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.
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 Jochen Liedtke's L4 microkernel demonstrated IPC overheads reduced by an order-of-magnitude.
See also
References
- Hansen, Per Brinch (1970). "The Nucleus of a Multiprogramming Operating System" (PDF). Communications of the ACM. 13 (4). Association for Computing Machinery: 238–250. CiteSeerX 10.1.1.105.4204. doi:10.1145/362258.362278.
- RC 4000 Software: Multiprogramming System
- RC 4000 Reference Manual at bitsavers.org