RC 4000: Первая операционная система с микроядром

Введение

Технологическая система (снята с производства)

Многопрограммная система RC 4000 (также называемая Monitor или RC 4000 в зависимости от источника) — это устаревшая операционная система, разработанная для миникомпьютера RC 4000 в 1969 году. Для ясности в данной статье преимущественно используется термин Monitor.

Обзор

Мультипрограммная система RC 4000 исторически примечательна тем, что стала первой попыткой разбить операционную систему на группу взаимодействующих программ, общающихся посредством ядра передачи сообщений. RC 4000 не получила широкого распространения, но оказала значительное влияние, породив концепцию микроядра, которая доминировала в исследованиях операционных систем в 1970-х и 1980-х годах. Монитор был создан в основном одним программистом, Пером Бринчем Хансеном, который работал в Regnecentralen, где разрабатывалась RC 4000. Лейф Свальгаард участвовал в реализации и тестировании Монитора. Бринч Хансен обнаружил, что ни одна существующая операционная система не подходит для новой машины, и устал от необходимости адаптировать существующие системы. Он считал, что более эффективным решением будет создание базового ядра, которое он называл ядром (nucleus), на основе которого можно было бы построить операционную систему из взаимодействующих программ. Например, Unix использует небольшие взаимодействующие программы для многих задач, передавая данные через систему, называемую конвейерами или каналами. Однако значительный объем фундаментального кода интегрирован в ядро, в частности, такие компоненты, как файловые системы и управление программами. Монитор также предполагал переместить этот код, сделав почти всю систему набором взаимодействующих программ и сведя ядро (nucleus) лишь к системе связи и поддержки. Монитор использовал систему общей памяти, подобную каналам, в качестве основы для межпроцессного взаимодействия (IPC). Данные, предназначенные для отправки из одного процесса в другой, копировались в пустой буфер памяти, а когда принимающая программа была готова, извлекались обратно. Затем буфер возвращался в пул. Программы имели очень простой интерфейс прикладного программирования (API) для передачи данных, использующий асинхронный набор из четырех методов. Клиентские приложения отправляли данные с помощью команды "отправить сообщение" и могли опционально блокироваться с помощью команды "ждать ответа". Серверы использовали зеркальный набор вызовов: "ждать сообщения" и "отправить ответ". Важно отметить, что сообщения имели неявный "обратный путь" для каждого отправленного сообщения, что делало семантику более похожей на вызов удаленной процедуры, чем на полностью основанную на вводе-выводе (I/O) систему Mach. Монитор разделял адресное пространство приложения на две части: внутренние процессы представляли собой выполнение традиционных программ, запускаемых по запросу, а внешние процессы фактически являлись драйверами устройств. Внешние процессы обрабатывались вне пользовательского пространства ядром, хотя их можно было запускать и останавливать как любую другую программу. Внутренние процессы запускались в контексте родительского процесса, который их запустил, поэтому каждый пользователь мог эффективно создавать свою собственную операционную систему, запуская и останавливая программы в своем собственном контексте. Планирование было полностью предоставлено на усмотрение программ, если оно вообще требовалось (в 1960-х годах многозадачность компьютера была функцией сомнительной ценности). Один пользователь мог начать сеанс в среде с вытесняющей многозадачностью, в то время как другой мог начать работу в однопользовательском режиме для пакетной обработки с более высокой скоростью. Планирование в реальном времени можно было поддерживать путем отправки сообщений в процесс-таймер, который возвращал управление только в нужный момент времени. Эти две области получили наибольшее развитие после выпуска Монитора, что побудило новые проекты использовать аппаратное обеспечение для поддержки обмена сообщениями и поддержку потоков в приложениях для сокращения времени запуска. Например, Mach требовал блока управления памятью для улучшения обмена сообщениями с помощью протокола копирования при записи и отображения (вместо копирования) данных от процесса к процессу. Mach также широко использовал потоки, позволяя внешним программам или серверам (в более современных терминах) легко запускать новые обработчики для входящих запросов. Тем не менее, IPC в Mach был слишком медленным, чтобы сделать подход микроядра практически полезным. Это изменилось только тогда, когда микроядро L4, разработанное Йохеном Лидтке, продемонстрировало снижение накладных расходов на IPC на порядок величины.

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.