Разработчик | Росс Финлейсон, Apple Computer |
---|---|
Семейство ОС | V-система |
Рабочее состояние | Прекращено |
Исходная модель | Закрытый исходный код |
Первоначальный выпуск | 1993 ( 1993 ) |
Маркетинговая цель | Настольные компьютеры |
Доступно в | Английский |
Платформы | Motorola серии 68000 |
Тип ядра | Микроядро |
Предшествовал | V-система |
Vanguard — это прекращенное экспериментальное микроядро , разработанное в Apple Computer [1] в исследовательской группе Apple Advanced Technology Group (ATG) в начале 1990-х годов. Основанное на V-System , Vanguard представило стандартизированные идентификаторы объектов и уникальную систему цепочки сообщений для повышения производительности. Vanguard не использовался ни в одном коммерческом продукте Apple. Разработка завершилась в 1993 году, когда Росс Финлейсон, главный исследователь проекта, покинул Apple.
Vanguard в целом был очень похож на V-System, но добавил поддержку настоящего объектно-ориентированного программирования операционной системы . Это означало, что интерфейсы ядра и сервера экспортировались как объекты, которые могли наследоваться и расширяться в новом коде. Это изменение не имело видимого эффекта на систему, это в основном изменение в исходном коде , которое упрощает программирование.
Например, в Vanguard был класс ввода/вывода (I/O) , который поддерживался несколькими различными серверами, например, сетевыми и файловыми серверами , с которыми новые приложения могли взаимодействовать, импортируя интерфейс ввода/вывода и вызывая методы. Это также значительно упростило написание новых серверов, поскольку у них был стандарт для программирования, и они могли легче обмениваться кодом.
Ключевой концепцией почти всех микроядер является разбиение одного большого ядра на набор взаимодействующих серверов . Вместо того, чтобы одна большая программа управляла всем оборудованием компьютерной системы, различные обязанности распределяются между более мелкими программами, которым даны права на управление различными частями машины. Например, одному серверу может быть дано управление сетевым оборудованием, в то время как другому будет поручено управление жесткими дисками . Другой сервер будет управлять файловой системой , вызывая оба этих сервера более низкого уровня. Пользовательские приложения запрашивают услуги, отправляя сообщения этим серверам, используя некоторую форму межпроцессного взаимодействия (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-System объекты на серверах ссылались через специальный закрытый ключ некоторого рода, скажем, 32-битное целое число. Клиенты передавали эти ключи на серверы для поддержания разговора о конкретной задаче. Например, приложение могло запросить у ядра файловую систему и получить 32-битный ключ, представляющий идентификатор программы, а затем использовать этот ключ для отправки сообщения в файловую систему с просьбой открыть файл my addresses
, что привело бы к возврату 64-битного ключа. Ключи в этом примере являются собственностью серверов, в системе не было общего формата ключей.
Этот вид разрешения имен был настолько распространен в V, что авторы решили сделать эти ключи гражданами первого класса в Vanguard. Вместо использования любых идентификаторов объектов, которые серверы просто использовали, в Vanguard все серверы должны были понимать и возвращать глобально уникальный 128-битный ключ, первые 64 бита которого содержали идентификатор сервера, а вторые идентифицировали объект на этом сервере. Идентификатор сервера поддерживался в ядре, что позволяло ему передавать сообщение по сети, если сервер, на который ссылаются, находился на удаленной машине. Для клиента это было невидимо. Неясно, были ли идентификаторы назначены случайным образом, чтобы исключить успешное угадывание злонамеренным программным обеспечением.