Авангард (микроядро)

Авангард

Разработчик	Росс Финлейсон, Apple Computer
Семейство ОС	V-System
Рабочее состояние	Снято с производства
Исходная модель	Закрытый исходный код
Первоначальный выпуск	1993 год ( 1993 )
Маркетинговая цель	Настольные компьютеры
Доступно в	Английский
Платформы	Моторола серии 68000
ядра Тип	Микроядро
Предшественник	V-System

Vanguard — снятое с производства экспериментальное микроядро, разработанное в Apple Computer . в исследовательской группе Apple Advanced Technology Group (ATG) в начале 1990-х годов. На основе V-System компания Vanguard представила стандартизированные идентификаторы объектов и уникальную систему цепочки сообщений для повышения производительности. Vanguard не использовался ни в одном коммерческом продукте Apple. Разработка завершилась в 1993 году, когда Росс Финлейсон, главный исследователь проекта, покинул Apple.

Основные понятия

Vanguard в целом был очень похож на V-System, но добавлял поддержку настоящего объектно-ориентированного программирования операционной системы . Это означало, что интерфейсы ядра и сервера экспортировались как объекты, которые можно было унаследовать и расширить в новом коде. Это изменение не оказывает видимого влияния на систему, в основном это изменение исходного кода , упрощающее программирование.

Например, в Vanguard был ввода-вывода (I/O) класс , который поддерживался несколькими различными серверами, например, сетевыми и файловыми серверами , с которыми новые приложения могли взаимодействовать, импортируя интерфейс ввода-вывода и вызывая методы. Это также значительно облегчило написание новых серверов, поскольку у них был стандарт для программирования, и им было легче обмениваться кодом.

Семантика обмена сообщениями V

Ключевой концепцией почти всех микроядер является разделение одного более крупного ядра на набор взаимодействующих серверов . Вместо одной более крупной программы, управляющей всем аппаратным обеспечением компьютерной системы, различные обязанности распределяются между более мелкими программами, которым даны права управлять различными частями машины. Например, одному серверу может быть предоставлен контроль над сетевым оборудованием, а другому — управление жесткими дисками . Другой сервер будет обрабатывать файловую систему , вызывая оба этих сервера нижнего уровня. Пользовательские приложения запрашивают услуги, отправляя сообщения на эти серверы, используя ту или иную форму межпроцессного взаимодействия (IPC), в отличие от того, чтобы просить ядро ​​выполнить эту работу через системный вызов (syscall) или ловушку .

В V система IPC концептуально моделируется на основе удаленных вызовов процедур (RPC) с точки зрения клиентского приложения. Клиент импортировал файл определения интерфейса, содержащий информацию о вызовах, поддерживаемых ядром или другими приложениями, а затем использовал это определение для упаковки запросов. При вызове ядро ​​немедленно возьмет на себя управление, проверит результаты и передаст информацию нужному обработчику, возможно, внутри ядра. Любые результаты затем передавались обратно через ядро ​​клиенту.

Работа системы в том виде, в каком она видится клиентскому приложению, очень похожа на работу с обычным монолитным ядром . Хотя переданные результаты могли исходить от стороннего обработчика, это было практически незаметно для клиента. Серверы, обрабатывающие эти запросы, работали аналогично клиентам, открывая соединения с ядром для передачи данных. Однако серверы обычно создавали новые потоки, необходимые для обработки более длительных запросов. Когда они были обработаны и ответы опубликованы, поток можно было освободить, а серверы могли перейти в режим приема в ожидании дальнейших запросов.

Напротив, большинство микроядерных систем основано на модели асинхронной связи , а не на синхронных вызовах процедур . Каноническая система микроядра Mach моделировала сообщения как ввод-вывод, что имеет несколько важных побочных эффектов. Главным из них является то, что обычные планировщики задач в Unix-подобных системах обычно блокируют клиента, ожидающего запроса ввода-вывода, поэтому действия по приостановке и перезапуску приложений, ожидающих сообщений, уже встроены в базовую систему. . Обратной стороной этого подхода является то, что планировщик довольно тяжеловесен , и его вызов стал серьезным узким местом в производительности и привел к масштабным усилиям разработчиков по улучшению его производительности. В модели V-System накладные расходы на передачу сообщений сокращаются, поскольку нет необходимости обращаться к планировщику процессов, и нет вопроса о том, что следует запускать дальше, а именно к какому серверу обращаться. Недостатком подхода V является то, что он требует больше работы от сервера, если обработка ответа может занять некоторое время.

Цепочка

Одним из основных дополнений к системе IPC в Vanguard, в отличие от V, стала концепция цепочек сообщений , позволяющая отправлять одно сообщение между несколькими взаимодействующими серверами за один круговой путь. Теоретически цепочка может улучшить производительность обычных многоэтапных операций.

Рассмотрим случай, когда клиентское приложение должно прочитать файл. Обычно для этого требуется одно сообщение ядру, чтобы найти файловый сервер, затем еще три сообщения файловому серверу: одно для преобразования имени файла в идентификатор объекта, другое для открытия этого идентификатора и, наконец, еще одно для чтения файла. Используя цепочку Vanguard, клиент мог создать одно сообщение, содержащее все эти запросы. Сообщение будет отправлено ядру, а затем передано файловому серверу, который обработает все три запроса, прежде чем окончательно вернуть данные.

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

Именование объектов

V также представил простую распределенную службу имен . В сервисе хранятся хорошо известные имена персонажей, представляющие различные объекты в распределенной системе V, например: 2nd floor laser printer. Приложения могут запрашивать у сервера имен объекты по имени и получать обратно идентификатор, который позволит им взаимодействовать с этим объектом. Служба имен не была отдельным сервером и управлялась кодом ядра. Сравните это с сервером полных имен в операционной системе Spring , который не только знал об объектах внутри системы, но также использовался другими серверами в системе для трансляции своих частных имен, например, имен файлов и IP-адресов.

В V-системе к объектам на серверах обращались через какой-то специальный закрытый ключ , скажем, 32-битное целое число. Клиенты передавали эти ключи на серверы для поддержания разговора о конкретной задаче. Например, приложение может запросить у ядра файловую систему и получить 32-битный ключ, представляющий идентификатор программы, а затем использовать этот ключ для отправки сообщения в файловую систему с просьбой открыть файл. my addresses, что приведет к 64-битного возврату ключа. Ключи в этом примере являются собственностью серверов, в системе не использовался общий формат ключей.

Такое разрешение имен было настолько распространено в V, что авторы решили сделать эти ключи первоклассными гражданами в Vanguard. Вместо того, чтобы использовать тот идентификатор объекта, который серверы только что использовали, в рамках Vanguard все серверы должны были понимать и возвращать глобально уникальный 128-битный ключ, первый 64-битный ключ содержал идентификатор сервера, второй идентифицировал объект на этом сервере. Идентификатор сервера сохранялся в ядре, что позволяло ему передавать сообщение по сети, если сервер, на который ссылаются, находился на удаленном компьютере. Для клиента это было незаметно. Неясно, были ли идентификаторы присвоены случайным образом, чтобы предотвратить успешное угадывание злонамеренным программным обеспечением.