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