Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

RC 4000 Multiprogramming системы является прекращенной операционной системой , разработанной для RC 4000 миникомпьютера в 1969 году.

Обзор [ править ]

Многопрограммная система RC 4000 исторически известна тем, что была первой попыткой разбить операционную систему на группу взаимодействующих программ, взаимодействующих через ядро передачи сообщений . Хотя сам RC 4000 не был очень успешным, он, тем не менее, был чрезвычайно влиятельным, положив начало концепции микроядра, которая доминировала в исследованиях операционных систем в 1970-х и 1980-х годах. Система также известна как Monitor и, что несколько сбивает с толку, просто RC 4000, в зависимости от ссылки. Для ясности в этой статье будет использоваться термин «Монитор».

Монитор был создан в основном одним программистом Пером Бринчем Хансеном , который работал в Regnecentralen, где разрабатывался RC 4000. Лейф Свальгаард участвовал во внедрении и тестировании Monitor. Бринч Хансен обнаружил, что никакая существующая операционная система не подходит для новой машины, и устал от необходимости адаптировать существующие системы. Он считал, что лучшим решением было создание базового ядра, которое он называл ядром , которое можно было бы использовать для создания операционной системы из взаимодействующих программ. Unix , например, использует небольшие взаимодействующие программы для многих задач, передавая данные через систему, известную как каналы.. Однако в самом ядре похоронен большой объем фундаментального кода, особенно такие вещи, как файловые системы и управление программами. Monitor также удалит этот код, превратив почти всю систему в набор взаимодействующих программ, сократив ядро ​​(ядро) только до системы связи и поддержки.

В качестве основы межпроцессного взаимодействия Monitor использовал конвейерную систему разделяемой памяти . Данные, которые должны были быть отправлены от одного процесса к другому, были скопированы в пустой буфер памяти, и когда принимающая программа была готова, снова вернулись обратно. Затем буфер был возвращен в пул. У программ был очень простой API для передачи данных с использованием асинхронного набора из четырех методов. Клиентские приложения отправляют данные с помощью send messageи могут дополнительно блокировать использование wait answer. Серверы использовали зеркальный набор вызовов, wait messageи send answer. Обратите внимание, что сообщения имеют неявный «путь возврата» для каждого отправленного сообщения, что делает семантику больше похожей на удаленный вызов процедуры, чем на систему Mach , полностью основанную на вводе-выводе.

Монитор разделил пространство приложения на две части; внутренние процессы представляют собой выполнение традиционных программ, запускаемых по запросу, в то время как внешние процессы фактически являются драйверами устройств. Внешние процессы фактически обрабатывались ядром вне пользовательского пространства, хотя их можно было запускать и останавливать, как и любую другую программу. Внутренние процессы запускались в контексте «родительского», запустившего их, поэтому каждый пользователь мог эффективно создавать свою собственную операционную систему, запуская и останавливая программы в своем собственном контексте.

Планирование полностью оставалось на усмотрение программ, если оно вообще требовалось (в 1960-х годах многозадачность была спорной функцией). Один пользователь может запустить сеанс в среде с преимущественной многозадачностью , а другой - в однопользовательском режиме, чтобы выполнить пакетную обработку на более высокой скорости. Планирование в реальном времени может поддерживаться путем отправки сообщений процессу таймера, который будет возвращаться только в соответствующее время.

С момента выпуска Monitor эти две области претерпели большую часть разработок: в новых проектах используется оборудование для поддержки обмена сообщениями, а в приложениях поддерживаются потоки для сокращения времени запуска. Например, Mach требовался блок управления памятью для улучшения обмена сообщениями за счет использования протокола копирования при записи и сопоставления (вместо копирования) данных от процесса к процессу. Mach также широко использовал потоки, позволяя внешним программам или серверам, говоря более современным языком, легко запускать новые обработчики входящих запросов. Тем не менее, Mach IPC был слишком медленным, чтобы сделать подход микроядра практически полезным. Это изменилось только тогда, когда микроядро Liedtke L4 продемонстрировало улучшение на порядок накладных расходов IPC.

См. Также [ править ]

Ссылки [ править ]