Mach: различия между версиями

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску
[непроверенная версия][непроверенная версия]
Содержимое удалено Содержимое добавлено
Нет описания правки
м Удаление шаблонов: {{Нп5}}×1
 
(не показано 118 промежуточных версий 71 участника)
Строка 1: Строка 1:
{{otheruses|Мах}}
{{значения|Мах}}
{{плохой перевод}}
{{плохой перевод|язык=en|оригинал=Mach (kernel)}}
{{Карточка программы
{{нет ссылок|date=2008-05-16}}
|name = Mach
|logo =
|screenshot =
|caption =
|collapsible =
|author = [[Университет Карнеги — Меллона|Университет Карнеги — Меллона (CMU)]]
|developer =
|released = <!-- {{Start date|YYYY|MM|DD}} -->
|discontinued =
|latest_release_version = 3.0
|latest_release_date = <!-- {{Start date and age|YYYY|MM|DD}} -->
|latest_preview_version =
|latest_preview_date = <!-- {{Start date and age|YYYY|MM|DD}} -->
|frequently_updated =
|programming_language =
|operating_system =
|platform =
|size =
|language =
|status =
|genre = [[Микроядро]]
|license =
|website = http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html
}}
'''Mach''' — [[микроядро]] [[операционная система|операционной системы]], разработанное в [[Университет Карнеги — Меллона|Университете Карнеги — Меллона]] при проведении исследовательских работ в области операционных систем, главным образом распределённых и параллельных вычислений. Это один из самых первых примеров микроядра, но до сих пор он является стандартом для других подобных проектов.


Проект существовал с 1985 по 1994 годы и был закончен выпуском Mach 3.0. Несколько исследовательских групп продолжили разработку Mach; например, [[Университет Юты]] некоторое время вёл проект Mach 4<ref>[http://www.cs.utah.edu/flux/mach4/html/Mach4-proj.html The Mach 4 Project] {{Wayback|url=http://www.cs.utah.edu/flux/mach4/html/Mach4-proj.html |date=20170923185023 }}{{ref-en}}</ref>. Mach разрабатывался как замена ядру BSD UNIX, поэтому не было необходимости в разработке нового операционного окружения. Дальнейшие научно-исследовательские работы по проекту Mach, похоже, закончены; несмотря на это, Mach и его производные используются в ряде коммерческих операционных систем, например, [[NeXTSTEP]], наиболее заметной из которых является [[macOS]], в которой используется ядро [[XNU]], вобравшее в себя Mach 2.5. Система управления виртуальной памятью Mach была перенята разработчиками BSD в CSRG и используется в современных UNIX-системах, производных от BSD, например, FreeBSD. Ни macOS, ни FreeBSD не сохранили микроядерной архитектуры, используемой в Mach, хотя macOS предлагает для использования в приложениях микроядерную систему межпроцессного взаимодействия и примитивы управления.
'''Mach''' — [[микроядро]] [[операционная система|операционной системы]], разработанное в [[Carnegie Mellon University]] в исследовательских целях для решения задач с использованием распределенных вычислений. Это одно из первых микроядер, которое до сих пор используется во множестве операционных систем.


Mach является логическим продолжением ядра [[Accent (ядро операционной системы)|Accent]], также разработанного в [[Carnegie Mellon University]]. Ведущий разработчик проекта Ричард Рашид с 1991 года работает в [[Microsoft]] в подразделении Microsoft Research. Ещё один из основных разработчиков, [[Теванян, Аветис|Аветис Теванян]], работал главой отдела разработки программ в [[NeXT]], затем, до марта 2006.
Проект в Carnegie Mellon University разрабатывался с 1985 по 1994 год, закончился на Mach 3.0. Некоторое число разработчиков продолжило Mach исследования. Mach был разработан как замена ядру в BSD версии Unix, поэтому ни одна новая операционная система не создана вокруг него. Сегодня экспериментальные исследования Mach закончены, однако Mach и его потомки используются в нескольких коммерческих операционных системах, таких как [[NEXTSTEP]] и [[OPENSTEP]], а также [[Mac OS X]] (включая [[XNU]]).

Mach является логическим продолжением ядра [[Accent]], также разработанного в Carnegie Mellon University. Главный разработчик Mach, Эви Теваниан (англ. Avie Tevanian), являлся бывшим главой отдела программного обеспечения в [[NeXT]], а затем работал в [[Apple]] до марта 2006. Другой разработчик Mach, Ричард Рашид (англ. Richard Rashid), с 1991 года работал в [[Microsoft]] и занимал высокие должности, связанные в основном с отделением Microsoft Research.


== Концепция ==
== Концепция ==
Так как [[Mach]] был спроектирован как быстрая замена традиционному ядру [[Unix]], мы рассмотрим в основном отличия [[Mach]] от [[Unix]]. Стало понятным, что Unix-концепция "всё&nbsp;— файл" больше не работает на современных системах{{факт}}<!--Если переводите с английского, то хотя бы переводите правильно.-->, но такие системы, как [[Plan 9]] от [[Bell Labs]], всё же пытаются следовать по этому пути. Разработчики [[Mach]] заметили негибкость такого подхода, и предположили, что другой уровень [[Виртуализация|виртуализации]] может заставить систему «работать» снова.
Так как Mach был разработан как быстрая замена традиционному ядру [[Unix]], мы рассмотрим преимущественно отличия Mach от [[Unix]]. Стало понятным, что Unix-концепция «всё — файл» больше не работает на современных системах, но такие системы, как [[Plan 9]] от [[Bell Labs]], всё же пытаются следовать по этому пути. Разработчики Mach заметили негибкость такого подхода, и предположили, что другой уровень [[Виртуализация|виртуализации]] может заставить систему «работать» снова.


Одна из важнейших абстракций в [[Unix]] — это [[конвейер]]ы (pipe). Что похоже на конвейеры и позволит на более общем уровне сделать доступным различные перемещения информации между программами? Такая система может существовать, используя [[межпроцессное взаимодействие]] ([[IPC]])&nbsp;— похожий на конвейеры принцип организации взаимодействия процессов, позволяющий перемещать любую файлоподобную информацию между двумя программами. В то время как во многих системах, включая различные Unix, уже несколько лет существовали различные реализации [[IPC]], но они были предназначены для специальных целей и не могли обеспечить то, что создатели Mach от них ждали.
Одна из важнейших абстракций в [[Unix]] — это [[Конвейер (UNIX)|конвейеры]] (pipe). Какой механизм, похожий на конвейеры, позволит сделать более универсальный способ передачи информации между программами? Такая система может функционировать, используя [[межпроцессное взаимодействие]] (IPC) — похожий на конвейеры принцип организации взаимодействия процессов, позволяющий перемещать любые данные, подобные файлам между двумя программами. В то время как во многих системах, включая различные Unix, уже несколько лет существовали различные реализации IPC, они были предназначены для специальных целей и не могли обеспечить того, что создатели Mach от них ждали.


В [[Carnegie Mellon University]] начали разработку ядра [[Accent]], используя IPC, базирующийся на [[разделяемой памяти]]. Accent был экспериментальной системой со множеством возможностей, разрабатываемых по веянию моды за всё время разработки. Дополнительно, полезность Accent для исследования была ограничена, потому что он не был Unix-совместимым, а [[Unix]] был уже стандартом де-факто во всех исследовательских ОС. Также, [[Accent]] был жёстко привязан к платформе, на которой разрабатывался, и на начало 1980-х похоже, что скоро будет много новых платформ, многие из которых очень различны.
В [[Carnegie Mellon University]] начали разработку ядра Accent, используя IPC, основанный на [[разделяемая память|разделяемой памяти]]. Accent был экспериментальной системой со множеством возможностей, разрабатываемых по веянию моды за всё время разработки. Дополнительно, полезность Accent для исследования была ограничена, потому что он не был Unix-совместимым, а [[Unix]] был уже стандартом де-факто во всех исследовательских ОС. Кроме того, Accent был жёстко привязан к платформе, на которой разрабатывался. Но в начале 1980-х казалось, что вскоре появится множество новых платформ, многие из которых будут поддерживать массовый параллелизм.


Mach был начат как попытка создать легко-определяемый, Unix-основанный, портируемый [[Accent]]. В результате получился короткий список основных концепций:
В начале разработки Mach рассматривалась в основном как попытка создать концептуально «чистый» основанный на Unix легко портируемый Accent. Были сформулированы следующие основные концепции:


* «задача» — набор ресурсов которые позволяют «потокам» исполняться
* «задача» — набор ресурсов, которые позволяют «потокам» исполняться
* «поток» — единица, исполняющаяся на процессоре
* «поток» — единица, исполняющаяся на процессоре
* «порт» определяет защищённый конвейер для IPC между задачами
* «порт» определяет защищённый конвейер для IPC между задачами
* «сообщение» перемещается между программами через порт
* «сообщение» перемещается между программами через порт


Mach разработан на концепциях IPC Accent'а, но сделан системой, больше похожей на Unix, которая позволяет запускать Unix-программы с минимальными изменениями или вовсе без них. Для достижения этой цели в [[Mach]] появилась концепция «порта», представляющего конец в двухстороннем IPC. Порты были защищены и имели права , подобные правам доступа на файлы в Unix, а также использовали очень похожую на [[Unix]] модель защиты. Дополнительно Mach разрешал любой программе владеть привилегиями, которыми обычно владеет только ядро, позволяя [[непривилегированному уровню]] (user-space) обращаться к аппаратному обеспечению.
Mach разработан на концепциях IPC Accent’а, но сделан системой, больше похожей на Unix, которая позволяет запускать Unix-программы с минимальными изменениями или вовсе без них. Для достижения этой цели в Mach появилась концепция «порта», представляющего конец в двухстороннем IPC. Порты были защищены и имели права, подобные правам доступа на файлы в Unix, а также использовали очень похожую на [[Unix]] модель защиты. Дополнительно Mach разрешал любой программе владеть привилегиями, которыми обычно владеет только ядро, позволяя [[Пользовательское пространство|непривилегированному уровню]] (user-space) обращаться к аппаратному обеспечению.


В [[Mach]], как в [[Unix]], [[ОС]] опять стала главным образом набором утилит. Как и [[Unix]], в [[Mach]] есть концепция "драйвера" как посредника между собственно ядром и аппаратным обеспечением. Однако все драйверы для существующего аппаратного обеспечения должны быть включены в микроядро. Другие архитектуры, базирующиеся на [[Слои Абстракции от Оборудования|слоях абстракции от оборудования]] или [[Экзоядро|экзоядрах]] могут отделять драйверы из микроядра.
Как и в Unix, операционная система в Mach снова сводится в основном к набору утилит. Как и [[Unix]], в Mach есть концепция «драйвера» как посредника между собственно ядром и аппаратным обеспечением. Однако все драйверы для существующего аппаратного обеспечения должны быть включены в микроядро. Другие архитектуры, базирующиеся на [[слои абстракции от оборудования|слоях абстракции от оборудования]] или [[Экзоядро|экзоядрах]], могут отделять драйверы от микроядра.


Главным отличием от Unix было то, что утилиты должны были работать не с файлами, а с задачами. Больше кода было перемещено из ядра в непривилегированный режим. Ядро за счёт этого стало существенно меньше, отсюда термин [[микроядро]] для обозначения ядра Mach. В отличие от традиционных систем, под Mach процесс (или «задача») может состоять из набора потоков. Mach был первой ОС, которая определила понятие поток в этом смысле. Задачи ядра были сведены к работе с оборудованием и поддержке утилит.
Главным отличием от Unix было то, что утилиты должны были работать не с файлами, а с задачами. Больше кода было перемещено из ядра в непривилегированный режим. Ядро за счёт этого стало существенно меньше, отсюда термин [[микроядро]] для обозначения ядра Mach. В отличие от традиционных систем, под Mach процесс (или «задача») может состоять из набора потоков. Mach был первой ОС, которая определила понятие «поток» в этом смысле. Задачи ядра были сведены к работе с оборудованием и поддержке утилит.


Существование портов и использование IPC определяет большинство различие между Mach и традиционными ядрами. В Unix для обращения к ядру используются «[[системный вызов|системные вызовы]]» или «[[сигналы (UNIX)|сигнал]]». Программа использует [[Библиотека (программирование)|библиотеку]], чтобы разместить данные в известном месте в памяти, и затем вызывает специальное программное [[Прерывание|прерывание]]. Когда система впервые запускает ядро, она устанавливает обработчик этого [[Прерывание|прерывания]], поэтому программа, порождающая [[Прерывание|прерывание]], вызывает ядро, которое исследует пришедшую информацию и совершает действия.
Существование портов и использование IPC определяет большинство различий между Mach и традиционными ядрами. В Unix для обращения к ядру используются «[[системный вызов|системные вызовы]]» или «[[сигналы (UNIX)|сигнал]]». Программа использует [[Библиотека (программирование)|библиотеку]], чтобы разместить данные в известном месте в памяти, и затем вызывает специальное программное [[прерывание]]. Когда система впервые запускает ядро, она устанавливает обработчик этого [[Прерывание|прерывания]], поэтому программа, порождающая [[прерывание]], вызывает ядро, которое исследует пришедшую информацию и совершает действия.


В Mach для этой цели используется IPC. Программа запрашивает у ядра доступ к порту, а затем использует механизм IPC для посылки сообщений в порт. В других ядрах эти сообщения обрабатываются системными вызовами; в Mach практически все запросы обрабатываются другой программой.
В Mach для этой цели используется IPC. Программа запрашивает у ядра доступ к порту, а затем использует механизм IPC для посылки сообщений в порт. В других ядрах эти сообщения обрабатываются системными вызовами; в Mach практически все запросы обрабатываются другой программой.


Использование IPC для передачи сообщений поддерживает потоки и конкуренцию. Так как задачи состоят из множества потоков, и их код в потоках использует механизм IPC. Mach может заморозить или разморозить поток, пока сообщение обрабатывается. Это позволяет системе быть распределённой на множество процессоров, используя разделяемую память прямо в большинстве сообщений Mach, или путём добавления кода для копирования сообщения в другой процессор, если требуется. В традиционном ядре это трудно реализовать, потому что система должна быть уверена, что различные программы не пытаются писать в туже самую память на различных процессорах. В Mach это хорошо определено и легко реализуется; процесс совершающий доступ к памяти, портам делается гражданином системы.
Использование IPC для передачи сообщений поддерживает потоки и конкуренцию. Так как задачи состоят из множества потоков и их код в потоках использует механизм IPC, Mach может заморозить или разморозить поток, пока сообщение обрабатывается. Это позволяет системе быть распределённой на множество процессоров, используя разделяемую память непосредственно в большинстве сообщений Mach, или путём добавления кода для копирования сообщения в другой процессор, если требуется. В традиционном ядре это трудно реализовать, потому что система должна быть уверена, что различные программы не пытаются писать в одну и ту же память на различных процессорах. В Mach это хорошо определено и легко реализуется; процесс, совершающий доступ к памяти, портам, делается «гражданином» системы.


Система IPC имеет проблемы с производительностью, для преодоления которых было разработано несколько стратегий. В частности, Mach использует единый механизм разделения памяти для физической передачи сообщений от одной программы к другой. Физически копирования сообщения будет медленным, поэтому Mach обращается к [[Блок управления памятью|блоку управления памятью]] (MMU) для быстрого соотнесения данных в одной программе и в другой. Только если данные записываются они будут физически скопированы, процесс называющийся [[копирование-при-записи]] (copy-on-write; cow).
Система IPC имеет проблемы с производительностью, для преодоления которых было разработано несколько стратегий. В частности, Mach использует единый механизм разделения памяти для физической передачи сообщений от одной программы к другой. Физическое копирование сообщения будет медленным, поэтому Mach обращается к [[Блок управления памятью|блоку управления памятью]] (MMU) для быстрого соотнесения данных в одной программе и в другой. Только если данные записываются, они будут физически скопированы, процесс, называющийся «[[копирование при записи]]» (copy-on-write; cow).


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


По сравнению с более традиционными ОС разработка такой системы становится проще. Большая часть системы может быть запущена, отлажена и создана с помощью тех же утилит, что и программы для традиционной системы. С [[монолитное ядро|монолитным ядром]] ошибка в коде требует выключения целой машины и перезагрузки, в то время как в Mach требуется только перезапуск программы. Дополнительно пользователь может указывать системе включить или выключить возможности по своему желанию. Так как ОС — это коллекция программ, разработчики могут добавлять или удалять её части, просто запуская или убивая их, как и любую другую программу.
По сравнению с более традиционными ОС разработка такой системы становится проще. Большая часть системы может быть запущена, отлажена и создана с помощью тех же утилит, что и программы для традиционной системы. С [[монолитное ядро|монолитным ядром]] ошибка в коде требует выключения целой машины и перезагрузки, в то время как в Mach требуется только перезапуск программы. Дополнительно пользователь может указывать системе, включить или выключить возможности по своему желанию. Так как ОС — это коллекция программ, разработчики могут добавлять или удалять её части, просто запуская или останавливая их, как и любую другую программу.


== Разработка ==
== Разработка ==
Mach изначально располагался как дополнительный код, написанный к существующему 4.2BSD-ядру, который позволял команде работать на системе задолго до того, как она была завершена. Работа началась с уже готовой Accent [[Межпроцессное взаимодействие|IPC]]/порт системы и переместилась на другие ключевые части OS, задачи, потоки и виртуальную память. Эти части были переписаны на вызов функций в Mach; параллельно с этим велась работа над 4.3BSD.


В 1986 система была завершена и могла запускаться на [[DEC VAX]]. Несмотря на малое практическое значение, цель создать микроядро была воплощена в жизнь. Вскоре последовал выпуск версий для [[IBM PC/RT]] и рабочих станций [[Sun Microsystems]] [[68030]], предоставляя портируемость системы. К 1987 в список включены [[Encore Multimax]] и [[Sequent Computer Systems|Sequent Balance]]. Release 1 вышел в этот год, а Release 2 — в следующий.
Mach изначально располагался, как дополнительный код, написанный к существующему 4.2BSD ядру, который позволял команде работать на системе задолго до того, как она была завершена. Работа началась с уже готовой [[Accent]] IPC/порт системы, и переместилась на другие ключевые части OS, задачи, потоки и виртуальная память. Эти части были переписаны на вызов функций в Mach; параллельно с этим велась работа над 4.3BSD.


Все это время обещанное «настоящее» микроядро не было создано. Эти ранние версии Mach - прототипы, доказывающие её работоспособность, включали большую часть ядра [[BSD]] 4.3, в результате чего это ядро было фактически больше, чем Unix, на котором оно базировалось. Однако, цель переместить Unix-слой из ядра, где оно более просто разрабатывалось и заменялось, была достигнута. Производительность оставляла желать лучшего, и был осуществлен ряд архитектурных изменений, чтобы решить эту проблему.
В 1986 система была завершена и могла запускатся на [[DEC VAX]]. Несмотря на малое практичное значение, цель создать микроядро была воплощена в жизнь. Вскоре последовал выпуск версий для [[IBM PC/RT]] и [[Sun Microsystems]] [[68030]] рабочих станций, предоставляя портируемость системы. К 1987 в список включены [[Encore Multimax]] и [[Sequent Computer Systems|Sequent Balance]]. Release 1 вышел в этот год, а Release 2 в следующий.


В результате Mach 3 вышел в 1990 и вызвал большой интерес. Маленькая команда, которая сделала Mach, портировала его на множество платформ, включая сложные мультипроцессорные системы, которые создавали серьёзные проблемы для старомодных ядер. Также был активирован интерес в коммерческом сегменте рынка, где нашлись компании, которые хотели бы иметь возможность менять платформы, и, если бы они портировали свои ОС на Mach, то могли бы безболезненно менять платформы.
Все это время обещанное «настоящее» микроядро не было создано. Эти ранние версии Mach включали большую часть 4.3BSD ядра, системы известные как [[POE]], в результате это ядро было фактически больше чем Unix на котором оно базировалось. Однако, цель переместить Unix слой из ядра, где оно более просто разрабатывалось и заменялось была достигнута. К сожалению, производительность оставляла желать лучшего, и был осуществлен ряд архитектурных изменений чтобы решить эту проблему.


Mach получил ускорение развития, когда [[Open Source Foundation]] анонсировало, что они будут создавать следующую версию [[OSF/1]] на Mach 2.5, и были бы рады использовать Mach 3. Mach 2.5 также был выбран для [[NeXTSTEP]]-систем и некоторым количеством коммерческих мультипроцессорных производителей. При помощи Mach 3 было совершено некоторое число попыток портировать другие ОС на это ядро, включая [[IBM]] [[Workplace OS]] и несколько попыток от [[Apple Computer]] создать кросс-платформенную версию [[Mac OS]].
В результате Mach 3 вышел в 1990, и произвел интенсивный интерес. Маленькая команда, которая сделала Mach, портировала его на множество платформ, включая сложные мультипроцессорные системы которые создавали серьезные проблемы для старомодных ядер. Также был вызван интерес в коммерческом рынке, где нашлись компании которые хотели бы иметь возможность менять платформы, и если бы они портировали свои ОС на Mach, то могли бы безболезненно менять платформы.


Некоторое время казалось, что каждая ОС, созданная в конце 1990-х, будет базироваться на Mach.
Mach получил видимое ускорение когда [[Open Source Foundation]] анонсировало что они будут создавать будущую версию [[OSF/1]] на Mach 2.5, и были бы рады использовать Mach 3. Mach 2.5 так же был выбран для [[NeXTSTEP]] систем и некоторым количеством коммерческих мультипроцессорных производителей. При помощи Mach 3 было совершено некоторое число попыток портировать другие ОС на это ядро, включая [[IBM]] [[Workplace OS]] и несколько попыток от [[Apple Computer]] создать кросс-платформенную версию [[Mac OS]].

Некоторое время казалось что каждая ОС созданная в конце 1990ых будет базироватся на Mach.


== Проблемы с производительностью ==
== Проблемы с производительностью ==
Mach изначально позиционировался как замена классическому Unix, и по этой причине содержит множество Unixовых идей. К примеру, Mach использует систему прав и безопасности основанную на Unixовой файловой системе. Так как ядро исполняется в привелигированом режиме (kernel-mode) и возможно, что некоторая программа пошлет команду, которая повредит систему, и поэтому ядро проверяет каждое сообщение. Также большинство функциональности было расположено в программах исполняющихся в непривилегированном режиме (user-space), это значит что необходим некоторый способ разрешения таким программам дополнительных действий, например работа с аппаратным обеспечением.
Mach изначально позиционировался как замена классическому Unix, и по этой причине содержит множество Unіх'овых идей. К примеру, Mach использует систему прав и безопасности, основанную на Unix’овой файловой системе. Так как ядро исполняется в привилегированом режиме (kernel-mode) и возможно, что некоторая программа пошлет команду, которая повредит систему, ядру приходится проверять каждое сообщение. Также большинство функционала было расположено в программах, исполняющихся в непривилегированном режиме (user-space), это значит, что необходим некоторый способ разрешения таким программам дополнительных действий, например работу с аппаратным обеспечением.


Некоторые возможности Mach базировались на тех же механизмах IPC. К примеру, Mach с легкостью может поддерживать многопроцессорные компьютеры. В традиционном ядре экстенсивная работа проделывается, чтобы обеспечить [[реентерабельность]] или прерываемость программ запущенных на разных процессорах, которые могут вызывать ядро в одно и тоже время. В Mach кусочки операционной системы изолированы в серверах, которые могут запускаться, также как и другие программы, на любом процессоре. Потому теоретически ядро Mach также должно быть реентерабельным, но на практике это не проблема, так как все что нужно Mach — это направить запрос какой-нибудь непривилегированной программе. Mach так же включал сервер который может перенаправлять сообщения не только между программами, но и по сети. Работа в этой области была продела в конце 1980-х и начале 1990-х.
Некоторые возможности Mach базировались на тех же механизмах IPC. К примеру, Mach с лёгкостью может поддерживать многопроцессорные компьютеры. В традиционном ядре экстенсивная работа проделывается, чтобы обеспечить [[реентерабельность]] или прерываемость программ, запущенных на разных процессорах и способных вызывать функции ядра в одно и то же время. В Mach кусочки операционной системы изолированы в серверах, которые могут запускаться так же, как и другие программы — на любом процессоре. Потому теоретически ядро Mach также должно быть реентерабельным, но на практике это не проблема, так как все, что нужно Mach — это направить запрос какой-нибудь непривилегированной программе. Mach также включал сервер, который может перенаправлять сообщения не только между программами, но и по сети. Работа в этой области была проделана в конце 1980-х и начале 1990-х.


К сожалению использование IPC для большинства задач снижает производительность. Сравнения проведенные в 1997 году показали, что Unix построенный на Mach 3.0 на 50 % медленнее чем традиционный Unix.
Использование IPC для большинства задач снижает производительность<ref name="condict94">{{статья |заглавие=Microkernel modularity with integrated kernel performance |издание=Technical report, OSF Research Institute, Cambridge, MA |язык=en |тип=journal |автор=M. Condict, D. Bolinger, E. McManus, D. Mitchell, S. Lewontin |месяц=4 |год=1994}}</ref>. Сравнения, проведенные в 1997 году, показали, что Unix, построенный на Mach 3.0, на 50 % медленнее, чем традиционный Unix<ref name="hartig97p67">{{статья |doi=10.1145/269005.266660 |заглавие=The performance of μ-kernel-based systems |издание=Proceedings of the 16th ACM symposium on Operating systems principles (SOSP), Saint-Malo, France |том=31 |id=ISBN 0-89791-916-5 |номер=5 |ссылка=http://portal.acm.org/citation.cfm?id=266660&dl=ACM&coll=&CFID=15151515&CFTOKEN=6184618 |страницы=67 |язык=und |автор=Hermann Härtig, Michael Hohmuth, [[Jochen Liedtke]], Sebastian Schönberg, Jean Wolter |месяц=10 |год=1997}} [http://os.inf.tu-dresden.de/pubs/sosp97/ url2] {{Wayback|url=http://os.inf.tu-dresden.de/pubs/sosp97/ |date=20200217211614 }}</ref>.


Исследования показали, что производительность падает из-за IPC и достичь ускорения за счет раздробления ОС на маленькие сервера не возможно. Было сделано множество попыток улучшить производительность Mach, но в середине 1990 интерес пропал. Концепция системы основанной на IPC похоже умерла.
Исследования показали, что производительность падает из-за IPC, и достичь ускорения за счет раздробления ОС на маленькие серверы невозможно. Было сделано множество попыток улучшить производительность Mach, но в середине 1990 интерес пропал.


Фактически исследование природы проблем производительности выявило несколько интересных фактов: один — IPC сам по себе это не проблема, проблема в том что необходимо отображать память для его поддержки, но это добавляет только небольшое количество времени. Большинство (около 80 %) тратится на дополнительные задачи в ядре на обработку сообщения. В первую очередь проверку прав порта и целостность сообщения. В тестах на Intel 80486DX-50 стандартный Unix вызов занимает около 21 микросекунды, соответствующий вызов в Mach занимает 114 микросекунд. Из них 18 микросекунд относятся к аппаратному обеспечению; остальное относится к различным функциям ядра Mach.
Фактически, исследование природы проблем производительности выявило несколько интересных фактов: один — IPC сам по себе не является проблемой, проблема - в необходимости отображения памяти для его поддержки, что добавляет небольшие временные затраты. Большинство времени (около 80 %) тратится на дополнительные задачи в ядре — на обработку сообщения, в первую очередь - проверку прав порта и целостность сообщения. В тестах на Intel 80486DX-50 стандартный Unix-вызов занимает около 21 микросекунды, соответствующий вызов в Mach занимает 114 микросекунд, из них 18 микросекунд относятся к аппаратному обеспечению, остальное относится к различным функциям ядра Mach.


Когда Mach впервые был использован в серьезных разработках (2.x версия), производительность была ниже чем в традиционных ядрах примерно на 25 %. Эта цена не вызывала беспокойство, потому что система хорошо портировалась и работала на множестве процессоров. Фактически система скрыла серьезные проблемы с производительностью до выхода Mach 3, когда множество разработчиков попыталось создать системы запускаемые в непривилегированном режиме.
Когда Mach впервые был использован в серьёзных разработках (2.x версия), производительность была ниже, чем в традиционных ядрах, примерно на 25 %. Эта цена не вызывала беспокойства, потому что система хорошо портировалась и работала на множестве процессоров. Фактически, система скрыла серьёзные проблемы с производительностью до выхода Mach 3, когда множество разработчиков попыталось создать системы, запускаемые в непривилегированном режиме.


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


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


Многие из этих проблем существуют в любой системе которым необходимо работать на многопроцессорной машине, и в середине 1980ых казалось что будущий рынок будет наполнен ими. Фактически эволюция не работает как ожидается. Мультипроцессорные машины использовались в серверных приложениях в начале 1990ых, но затем исчезли. Тем временем производительность CPU возрастала на 60 % в год, умножая неэффективность кода. Плохо, что скорость доступа к памяти растет только на 7 % в год, это значит что цена обращения к памяти не уменьшилась, и вызовы IPC Mach’а которые не сохраняются в кеше работают очень медленно.
Многие из этих проблем существуют в любой системе, которой необходимо работать на многопроцессорной машине, и в середине 1980-х казалось, что будущий рынок будет наполнен ими. Фактически эволюция не работает, как ожидается. Мультипроцессорные машины использовались в серверных приложениях в начале 1990-х, но затем исчезли. Тем временем производительность CPU возрастала на 60 % в год, умножая неэффективность кода. Плохо, что скорость доступа к памяти растет только на 7 % в год, это значит, что цена обращения к памяти не уменьшилась, и вызовы IPC Mach’а, которые не сохраняются в кэше, работают очень медленно.


Несмотря на возможности Mach, такие потери производительности в реальном мире не применимы. Поэтому большинство сообщества разработчиков ОС посчитало что использование IPC в качестве основы ОС изначально неудачно.
Несмотря на возможности Mach, такие потери производительности в реальном мире неприемлемы, поэтому большая часть сообщества разработчиков ОС посчитала, что использование IPC в качестве основы ОС изначально провально.


== Возможные решения ==
== Возможные решения ==


Как мы установили выше большинство производительности Mach 3 теряется на IPC вызовах. Однако концепция «многосерверной системы» все еще обещающая, поэтому оно требует исследований. Разработчикам необходимо аккуратно изолировать код в модули, которые не делают вызовов от сервера к серверу. К примеру, большая часть кода для работы с сетью должна быть помещена в отдельный сервер. Под Unix это не так то просто, потому что система базируется на использовании файловой системы для всего от сети до безопасности.
Как мы установили выше, большинство производительности Mach 3 теряется на IPC-вызовах. Однако концепция «многосерверной системы» все ещё многообещающая, поэтому она требует исследований. Разработчикам необходимо аккуратно изолировать код в модули, которые не делают вызовов от сервера к серверу. К примеру, большая часть кода для работы с сетью должна быть помещена в отдельный сервер. Под Unix это не так-то просто, потому что система базируется на использовании файловой системы для всего, от сети до безопасности.


Большинство разработчиков застряло на оригинальной концепции единого большого сервера, который предоставляет функциональность ОС. Также для простоты разработки, они разрешили операционной системе работать в привилегированные и непривилегированном режиме. Это позволяет им разрабатывать в непривилегированном режиме и иметь все невозможности идеи Mach, и затем перемещать отлаженный сервер в привилегированный режим чтобы иметь лучшую производительность. Несколько операционных систем разработано подобным методом, известным как «ко-локейшн» (co-location), это используется в Lites (порт 4.4BSD Lite), [[MkLinux]], [[OSF/1]] и [[NeXTSTEP]]/[[OPENSTEP]]/[[Mac OS X]]. В [[ChorusOS]] сделали это возможностью базовой системы, разрешив северам переходить в привилегированный режим с помощью встроенных механизмов.
Большинство разработчиков застряло на оригинальной концепции единого большого сервера, который предоставляет функциональность ОС. Также для простоты разработки они разрешили операционной системе работать в привилегированном и непривилегированном режимах. Это позволяет им разрабатывать в непривилегированном режиме и иметь все возможности идеи Mach, и затем перемещать отлаженный сервер в привилегированный режим, чтобы иметь лучшую производительность. Несколько операционных систем разработано подобным методом, известным как «ко-локейшн» (co-location), это используется в Lites (порт 4.4BSD Lite), [[MkLinux]], [[OSF/1]] и [[NeXTSTEP]]/[[OpenStep]]/[[Mac OS X]]. В [[ChorusOS]] эту возможность сделали частью базовой системы, разрешив серверам переходить в привилегированный режим с помощью встроенных механизмов.


Mach 4 пытался решить эту проблему, с помощью радикального набора улучшений. В частности, он находил программный код, который обычно не записываем, и поэтому копирование при записи случается редко. Это делало возможным не сопоставлять память между процессами (map memory) для IPC, а вместо этого использовать локальные места программ. Это создало концепцию «шаттлов» и увеличило производительность, но разработчикам досталась сложность с управлением состояниями. Mach 4 также включил встроенные механизмы колокейшна.
В Mach 4 пытались решить эту проблему с помощью радикального набора улучшений. В частности, он находил программный код, который обычно не записываем, и поэтому копирование при записи случается редко. Это делало возможным не сопоставлять память между процессами (map memory) для IPC, а вместо этого использовать локальные области памяти программ. Это создало концепцию «шаттлов» и увеличило производительность, но разработчикам досталась сложность с управлением состояниями. В Mach 4 также включили встроенные механизмы колокейшна.


Во всех тестах IPC производительность была названа источником проблемы, ей причисляется 73 % потерянных циклов.
Во всех тестах IPC производительность была названа источником проблемы, ей причисляется 73 % потерянных циклов.


В середине 90ых работа над микроядерными системами повседневно остановилась. Хотя рынок верил что все новые системы будут микроядерными в 90ых, сегодня только одна широко используемая система Mac OS X, использует колокейшн сервер поверх сильно модифицированной Mach 3.
В середине 90-х работа над микроядерными системами остановилась. Хотя рынок верил, что все новые системы будут микроядерными в 90-х, сегодня только одна широко используемая система Mac OS X использует колокейшн-сервер поверх сильно модифицированного ядра Mach 3.


== Следующее поколение ==
== Следующее поколение ==


Исследования показали, что проблема производительности IPC не такая страшная как выглядит. Напоминаем что односторонний вызов на BSD занимает 20 микросекунд, в то время как на Mach 114. Из 114, 11 это переключение контекста, идентичного BSD. Дополнительно 18 используется менеджером памяти для отображения сообщения между непривилегированной средой исполнения и привилегированной (user-space и kernel-space). Это добавляет только 31 микросекунду, больше чем традиционный вызов, но не намного.
Исследования показали, что проблема производительности IPC не так страшна, как считается. Напоминаем, что односторонний вызов на BSD занимает 20 микросекунд, в то время как на Mach — 114, 11 из которых — это переключение контекста, идентичного BSD. Дополнительно 18 используется менеджером памяти для отображения сообщения между непривилегированной средой исполнения и привилегированной (user-space и kernel-space). Это добавляет 31 микросекунду, что дольше традиционного вызова, но не намного.


Оставшаяся часть проблемы это проверки прав доступа к порту у сообщений. В то время как это выглядит очень важным, фактически, это требуется только на Unix системах. К примеру однопользовательская система, запущенная на [[мобильный телефон|мобильном телефоне]], может не нуждаться в таких возможностях, и это тип систем, в которых Mach может быть использован. Однако Mach создает проблемы когда память перемещается в ОС, другие задачи могут не нуждаться в этом. [[DOS]] и ранние [[Mac OS]] имели [[единое адресное пространство]], разделяемое всеми процессами, поэтому в таких системах отображение памяти пустая трата времени.
Оставшаяся часть проблемы — это проверки прав доступа к порту сообщений. В то время, как это выглядит очень важным, фактически, это требуется только на Unix-системах. К примеру, однопользовательская система, запущенная на [[мобильный телефон|мобильном телефоне]], может не нуждаться в таких возможностях, и это тот тип систем, в которых Mach может быть использован. Однако Mach создает проблемы: когда память перемещается в ОС, другие задачи могут не нуждаться в этом. [[DOS]] и ранние [[Mac OS]] имели [[единое адресное пространство]], разделяемое всеми процессами, поэтому в таких системах отображение памяти — пустая трата времени.


Эти реализации положили начало [[второе поколение микроядер|второму поколению микроядер]], которое уменьшает сложность системы размещая большинство функциональности в непривилегированном режиме исполнения. Например, ядро [[L4]] включает только 7 функций и использует 12 килобайт памяти, когда Mach 3 ввключает около 140 функций и использует 330 килобайт памяти. IPC вызов на L4 на 486DX-50 занимает только 5 микросекунд, быстрее чем Unix вызов на этой же системе, и в 20 раз быстрее чем Mach. Конечно, если игнорировать факт, что L4 не обрабатывает разрешения и безопасность, но оставляя это для непривилегированных программ, которые могут выбирать сколько времени им требуется.
Эти реализации положили начало [[Микроядро#Второе поколение|второму поколению микроядер]], которое уменьшает сложность системы, размещая большую часть функциональности в непривилегированном режиме исполнения. Например, ядро [[L4 (микроядро)|L4]] включает только 7 функций и использует 12 килобайт памяти, тогда как Mach 3 включает около 140 функций и использует 330 килобайт памяти. IPC-вызов на L4 на 486DX-50 занимает только 5 микросекунд — быстрее, чем Unix-вызов на этой же системе, и в 20 раз быстрее, чем Mach. Конечно здесь не учитывается тот факт, что L4 не оперирует разрешениями и безопасностью, оставляя их на усмотрение непривилегированным программам.


«Потенциальные» ускорения L4 основаны на факте, что непривилегированные приложения часто предоставляют множество функций, которые формально поддерживаются ядром. Сравнивая конечную производительность, MkLinux в колокейшн режиме по сравнению с L4 портом запущенным в непривилегированном режиме. L4 добавляет только 5% - 10% потерь, в то время как Mach 15%, все это более интересно учитывая двойные переключения контекста.
«Потенциальные» ускорения L4 основаны на факте, что непривилегированные приложения часто предоставляют множество функций, которые формально поддерживаются ядром. Можно сравнить производительность MkLinux в колокейшн-режиме и порт L4, запущенный в непривилегированном режиме. L4 добавляет только около 5-10 % накладных расходов, в то время как Mach добавляет 15 %, что весьма интересно, если учитывать двойные переключения контекста.


Новые микроядра изменили индустрию в целом, множество умерших проектов, таких как [[GNU Hurd]] получили новое внимание.
В результате новые микроядра изменили индустрию в целом, множество некогда мертвых проектов вроде [[GNU Hurd]] снова привлекло к себе внимание.


== Операционные системы и ядра, основанные на Mach ==
== Операционные системы и ядра, основанные на Mach ==
* [[GNU Hurd]]/[[GNU Mach]]
* [[GNU Hurd]]
* [[Lites]]
* [[Lites]]
* [[MkLinux]]
* [[MkLinux]]
Строка 107: Строка 129:
* [[MachTen]]
* [[MachTen]]
* [[MacMach]]
* [[MacMach]]
* [[Mac OS X]]
* [[macOS]] ([[Darwin]])
* [[NEXTSTEP]]
* [[NeXTSTEP]]
* [[OSF/1]]
* [[OSF/1]]
* [[Workplace OS]]
* [[Workplace OS]]
Строка 116: Строка 138:
== См. также ==
== См. также ==
* [[Микроядро]]
* [[Микроядро]]
* [[L4 (микроядро)|L4]]

== Примечания ==
{{примечания}}


== Ссылки ==
{{Compu-stub}}
* Статья на сайте CITforum.ru: [http://www.citforum.ru/operating_systems/sos/glava_23.shtml «Микроядро Mach»].
* Статья С. Кузнецова на сайте CITforum.ru: [http://www.citforum.ru/database/articles/art_21.shtml «Исследования и разработки в области операционных систем»].
* [http://www-2.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html The Mach project at Carnegie Mellon]
* [https://web.archive.org/web/20130511223918/http://codex.cs.yale.edu/avi/os-book/OS8/os8e/appendices-dir/b.pdf The Mach System] — Appendix to ''Operating System Concepts'' (8th ed) by Avi Silberschatz, Peter Baer Galvin and Greg Gagne
* [https://web.archive.org/web/20050513191623/http://www.cdk3.net/oss/Ed2/Comparison.pdf A comparison of Mach, Amoeba and Chorus]
* [http://os.inf.tu-dresden.de/pubs/sosp97/ The Performance of µ-Kernel-Based Systems] — Contains an excellent performance comparison of Linux running as a monokernel, on Mach 3 and on L4
* [http://fxr.watson.org/fxr/source/?v=MK84 Mach kernel source code] — Browsable version of the Mach Kernel source code on the FreeBSD/Linux kernel cross reference site


{{Mach-like}}
[[Категория:Mac OS X]]
[[Категория:Ядра операционных систем]]


[[Категория:MacOS]]
[[de:Mach (Kernel)]]
[[Категория:Микроядра]]
[[en:Mach (kernel)]]
[[es:Mach (núcleo)]]
[[fr:Mach (informatique)]]
[[it:Kernel Mach]]
[[ja:Mach]]
[[nl:Machkernel]]
[[pl:Mach (system operacyjny)]]
[[pt:Mach (kernel)]]
[[sv:Mach (operativsystem)]]
[[zh:Mach]]

Текущая версия от 14:32, 24 ноября 2024

Mach
Тип Микроядро
Автор Университет Карнеги — Меллона (CMU)
Написана на Си и язык ассемблера
Первый выпуск 1985[1]
Последняя версия 3.0
Сайт cs.cmu.edu/afs/cs/projec…

Mach — микроядро операционной системы, разработанное в Университете Карнеги — Меллона при проведении исследовательских работ в области операционных систем, главным образом распределённых и параллельных вычислений. Это один из самых первых примеров микроядра, но до сих пор он является стандартом для других подобных проектов.

Проект существовал с 1985 по 1994 годы и был закончен выпуском Mach 3.0. Несколько исследовательских групп продолжили разработку Mach; например, Университет Юты некоторое время вёл проект Mach 4[2]. Mach разрабатывался как замена ядру BSD UNIX, поэтому не было необходимости в разработке нового операционного окружения. Дальнейшие научно-исследовательские работы по проекту Mach, похоже, закончены; несмотря на это, Mach и его производные используются в ряде коммерческих операционных систем, например, NeXTSTEP, наиболее заметной из которых является macOS, в которой используется ядро XNU, вобравшее в себя Mach 2.5. Система управления виртуальной памятью Mach была перенята разработчиками BSD в CSRG и используется в современных UNIX-системах, производных от BSD, например, FreeBSD. Ни macOS, ни FreeBSD не сохранили микроядерной архитектуры, используемой в Mach, хотя macOS предлагает для использования в приложениях микроядерную систему межпроцессного взаимодействия и примитивы управления.

Mach является логическим продолжением ядра Accent, также разработанного в Carnegie Mellon University. Ведущий разработчик проекта Ричард Рашид с 1991 года работает в Microsoft в подразделении Microsoft Research. Ещё один из основных разработчиков, Аветис Теванян, работал главой отдела разработки программ в NeXT, затем, до марта 2006.

Так как Mach был разработан как быстрая замена традиционному ядру Unix, мы рассмотрим преимущественно отличия Mach от Unix. Стало понятным, что Unix-концепция «всё — файл» больше не работает на современных системах, но такие системы, как Plan 9 от Bell Labs, всё же пытаются следовать по этому пути. Разработчики Mach заметили негибкость такого подхода, и предположили, что другой уровень виртуализации может заставить систему «работать» снова.

Одна из важнейших абстракций в Unix — это конвейеры (pipe). Какой механизм, похожий на конвейеры, позволит сделать более универсальный способ передачи информации между программами? Такая система может функционировать, используя межпроцессное взаимодействие (IPC) — похожий на конвейеры принцип организации взаимодействия процессов, позволяющий перемещать любые данные, подобные файлам между двумя программами. В то время как во многих системах, включая различные Unix, уже несколько лет существовали различные реализации IPC, они были предназначены для специальных целей и не могли обеспечить того, что создатели Mach от них ждали.

В Carnegie Mellon University начали разработку ядра Accent, используя IPC, основанный на разделяемой памяти. Accent был экспериментальной системой со множеством возможностей, разрабатываемых по веянию моды за всё время разработки. Дополнительно, полезность Accent для исследования была ограничена, потому что он не был Unix-совместимым, а Unix был уже стандартом де-факто во всех исследовательских ОС. Кроме того, Accent был жёстко привязан к платформе, на которой разрабатывался. Но в начале 1980-х казалось, что вскоре появится множество новых платформ, многие из которых будут поддерживать массовый параллелизм.

В начале разработки Mach рассматривалась в основном как попытка создать концептуально «чистый» основанный на Unix легко портируемый Accent. Были сформулированы следующие основные концепции:

  • «задача» — набор ресурсов, которые позволяют «потокам» исполняться
  • «поток» — единица, исполняющаяся на процессоре
  • «порт» определяет защищённый конвейер для IPC между задачами
  • «сообщение» перемещается между программами через порт

Mach разработан на концепциях IPC Accent’а, но сделан системой, больше похожей на Unix, которая позволяет запускать Unix-программы с минимальными изменениями или вовсе без них. Для достижения этой цели в Mach появилась концепция «порта», представляющего конец в двухстороннем IPC. Порты были защищены и имели права, подобные правам доступа на файлы в Unix, а также использовали очень похожую на Unix модель защиты. Дополнительно Mach разрешал любой программе владеть привилегиями, которыми обычно владеет только ядро, позволяя непривилегированному уровню (user-space) обращаться к аппаратному обеспечению.

Как и в Unix, операционная система в Mach снова сводится в основном к набору утилит. Как и Unix, в Mach есть концепция «драйвера» как посредника между собственно ядром и аппаратным обеспечением. Однако все драйверы для существующего аппаратного обеспечения должны быть включены в микроядро. Другие архитектуры, базирующиеся на слоях абстракции от оборудования или экзоядрах, могут отделять драйверы от микроядра.

Главным отличием от Unix было то, что утилиты должны были работать не с файлами, а с задачами. Больше кода было перемещено из ядра в непривилегированный режим. Ядро за счёт этого стало существенно меньше, отсюда термин микроядро для обозначения ядра Mach. В отличие от традиционных систем, под Mach процесс (или «задача») может состоять из набора потоков. Mach был первой ОС, которая определила понятие «поток» в этом смысле. Задачи ядра были сведены к работе с оборудованием и поддержке утилит.

Существование портов и использование IPC определяет большинство различий между Mach и традиционными ядрами. В Unix для обращения к ядру используются «системные вызовы» или «сигнал». Программа использует библиотеку, чтобы разместить данные в известном месте в памяти, и затем вызывает специальное программное прерывание. Когда система впервые запускает ядро, она устанавливает обработчик этого прерывания, поэтому программа, порождающая прерывание, вызывает ядро, которое исследует пришедшую информацию и совершает действия.

В Mach для этой цели используется IPC. Программа запрашивает у ядра доступ к порту, а затем использует механизм IPC для посылки сообщений в порт. В других ядрах эти сообщения обрабатываются системными вызовами; в Mach практически все запросы обрабатываются другой программой.

Использование IPC для передачи сообщений поддерживает потоки и конкуренцию. Так как задачи состоят из множества потоков и их код в потоках использует механизм IPC, Mach может заморозить или разморозить поток, пока сообщение обрабатывается. Это позволяет системе быть распределённой на множество процессоров, используя разделяемую память непосредственно в большинстве сообщений Mach, или путём добавления кода для копирования сообщения в другой процессор, если требуется. В традиционном ядре это трудно реализовать, потому что система должна быть уверена, что различные программы не пытаются писать в одну и ту же память на различных процессорах. В Mach это хорошо определено и легко реализуется; процесс, совершающий доступ к памяти, портам, делается «гражданином» системы.

Система IPC имеет проблемы с производительностью, для преодоления которых было разработано несколько стратегий. В частности, Mach использует единый механизм разделения памяти для физической передачи сообщений от одной программы к другой. Физическое копирование сообщения будет медленным, поэтому Mach обращается к блоку управления памятью (MMU) для быстрого соотнесения данных в одной программе и в другой. Только если данные записываются, они будут физически скопированы, процесс, называющийся «копирование при записи» (copy-on-write; cow).

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

По сравнению с более традиционными ОС разработка такой системы становится проще. Большая часть системы может быть запущена, отлажена и создана с помощью тех же утилит, что и программы для традиционной системы. С монолитным ядром ошибка в коде требует выключения целой машины и перезагрузки, в то время как в Mach требуется только перезапуск программы. Дополнительно пользователь может указывать системе, включить или выключить возможности по своему желанию. Так как ОС — это коллекция программ, разработчики могут добавлять или удалять её части, просто запуская или останавливая их, как и любую другую программу.

Разработка

[править | править код]

Mach изначально располагался как дополнительный код, написанный к существующему 4.2BSD-ядру, который позволял команде работать на системе задолго до того, как она была завершена. Работа началась с уже готовой Accent IPC/порт системы и переместилась на другие ключевые части OS, задачи, потоки и виртуальную память. Эти части были переписаны на вызов функций в Mach; параллельно с этим велась работа над 4.3BSD.

В 1986 система была завершена и могла запускаться на DEC VAX. Несмотря на малое практическое значение, цель создать микроядро была воплощена в жизнь. Вскоре последовал выпуск версий для IBM PC/RT и рабочих станций Sun Microsystems 68030, предоставляя портируемость системы. К 1987 в список включены Encore Multimax и Sequent Balance. Release 1 вышел в этот год, а Release 2 — в следующий.

Все это время обещанное «настоящее» микроядро не было создано. Эти ранние версии Mach - прототипы, доказывающие её работоспособность, включали большую часть ядра BSD 4.3, в результате чего это ядро было фактически больше, чем Unix, на котором оно базировалось. Однако, цель переместить Unix-слой из ядра, где оно более просто разрабатывалось и заменялось, была достигнута. Производительность оставляла желать лучшего, и был осуществлен ряд архитектурных изменений, чтобы решить эту проблему.

В результате Mach 3 вышел в 1990 и вызвал большой интерес. Маленькая команда, которая сделала Mach, портировала его на множество платформ, включая сложные мультипроцессорные системы, которые создавали серьёзные проблемы для старомодных ядер. Также был активирован интерес в коммерческом сегменте рынка, где нашлись компании, которые хотели бы иметь возможность менять платформы, и, если бы они портировали свои ОС на Mach, то могли бы безболезненно менять платформы.

Mach получил ускорение развития, когда Open Source Foundation анонсировало, что они будут создавать следующую версию OSF/1 на Mach 2.5, и были бы рады использовать Mach 3. Mach 2.5 также был выбран для NeXTSTEP-систем и некоторым количеством коммерческих мультипроцессорных производителей. При помощи Mach 3 было совершено некоторое число попыток портировать другие ОС на это ядро, включая IBM Workplace OS и несколько попыток от Apple Computer создать кросс-платформенную версию Mac OS.

Некоторое время казалось, что каждая ОС, созданная в конце 1990-х, будет базироваться на Mach.

Проблемы с производительностью

[править | править код]

Mach изначально позиционировался как замена классическому Unix, и по этой причине содержит множество Unіх'овых идей. К примеру, Mach использует систему прав и безопасности, основанную на Unix’овой файловой системе. Так как ядро исполняется в привилегированом режиме (kernel-mode) и возможно, что некоторая программа пошлет команду, которая повредит систему, ядру приходится проверять каждое сообщение. Также большинство функционала было расположено в программах, исполняющихся в непривилегированном режиме (user-space), это значит, что необходим некоторый способ разрешения таким программам дополнительных действий, например работу с аппаратным обеспечением.

Некоторые возможности Mach базировались на тех же механизмах IPC. К примеру, Mach с лёгкостью может поддерживать многопроцессорные компьютеры. В традиционном ядре экстенсивная работа проделывается, чтобы обеспечить реентерабельность или прерываемость программ, запущенных на разных процессорах и способных вызывать функции ядра в одно и то же время. В Mach кусочки операционной системы изолированы в серверах, которые могут запускаться так же, как и другие программы — на любом процессоре. Потому теоретически ядро Mach также должно быть реентерабельным, но на практике это не проблема, так как все, что нужно Mach — это направить запрос какой-нибудь непривилегированной программе. Mach также включал сервер, который может перенаправлять сообщения не только между программами, но и по сети. Работа в этой области была проделана в конце 1980-х и начале 1990-х.

Использование IPC для большинства задач снижает производительность[3]. Сравнения, проведенные в 1997 году, показали, что Unix, построенный на Mach 3.0, на 50 % медленнее, чем традиционный Unix[4].

Исследования показали, что производительность падает из-за IPC, и достичь ускорения за счет раздробления ОС на маленькие серверы невозможно. Было сделано множество попыток улучшить производительность Mach, но в середине 1990 интерес пропал.

Фактически, исследование природы проблем производительности выявило несколько интересных фактов: один — IPC сам по себе не является проблемой, проблема - в необходимости отображения памяти для его поддержки, что добавляет небольшие временные затраты. Большинство времени (около 80 %) тратится на дополнительные задачи в ядре — на обработку сообщения, в первую очередь - проверку прав порта и целостность сообщения. В тестах на Intel 80486DX-50 стандартный Unix-вызов занимает около 21 микросекунды, соответствующий вызов в Mach занимает 114 микросекунд, из них 18 микросекунд относятся к аппаратному обеспечению, остальное относится к различным функциям ядра Mach.

Когда Mach впервые был использован в серьёзных разработках (2.x версия), производительность была ниже, чем в традиционных ядрах, примерно на 25 %. Эта цена не вызывала беспокойства, потому что система хорошо портировалась и работала на множестве процессоров. Фактически, система скрыла серьёзные проблемы с производительностью до выхода Mach 3, когда множество разработчиков попыталось создать системы, запускаемые в непривилегированном режиме.

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

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

Многие из этих проблем существуют в любой системе, которой необходимо работать на многопроцессорной машине, и в середине 1980-х казалось, что будущий рынок будет наполнен ими. Фактически эволюция не работает, как ожидается. Мультипроцессорные машины использовались в серверных приложениях в начале 1990-х, но затем исчезли. Тем временем производительность CPU возрастала на 60 % в год, умножая неэффективность кода. Плохо, что скорость доступа к памяти растет только на 7 % в год, это значит, что цена обращения к памяти не уменьшилась, и вызовы IPC Mach’а, которые не сохраняются в кэше, работают очень медленно.

Несмотря на возможности Mach, такие потери производительности в реальном мире неприемлемы, поэтому большая часть сообщества разработчиков ОС посчитала, что использование IPC в качестве основы ОС изначально провально.

Возможные решения

[править | править код]

Как мы установили выше, большинство производительности Mach 3 теряется на IPC-вызовах. Однако концепция «многосерверной системы» все ещё многообещающая, поэтому она требует исследований. Разработчикам необходимо аккуратно изолировать код в модули, которые не делают вызовов от сервера к серверу. К примеру, большая часть кода для работы с сетью должна быть помещена в отдельный сервер. Под Unix это не так-то просто, потому что система базируется на использовании файловой системы для всего, от сети до безопасности.

Большинство разработчиков застряло на оригинальной концепции единого большого сервера, который предоставляет функциональность ОС. Также для простоты разработки они разрешили операционной системе работать в привилегированном и непривилегированном режимах. Это позволяет им разрабатывать в непривилегированном режиме и иметь все возможности идеи Mach, и затем перемещать отлаженный сервер в привилегированный режим, чтобы иметь лучшую производительность. Несколько операционных систем разработано подобным методом, известным как «ко-локейшн» (co-location), это используется в Lites (порт 4.4BSD Lite), MkLinux, OSF/1 и NeXTSTEP/OpenStep/Mac OS X. В ChorusOS эту возможность сделали частью базовой системы, разрешив серверам переходить в привилегированный режим с помощью встроенных механизмов.

В Mach 4 пытались решить эту проблему с помощью радикального набора улучшений. В частности, он находил программный код, который обычно не записываем, и поэтому копирование при записи случается редко. Это делало возможным не сопоставлять память между процессами (map memory) для IPC, а вместо этого использовать локальные области памяти программ. Это создало концепцию «шаттлов» и увеличило производительность, но разработчикам досталась сложность с управлением состояниями. В Mach 4 также включили встроенные механизмы колокейшна.

Во всех тестах IPC производительность была названа источником проблемы, ей причисляется 73 % потерянных циклов.

В середине 90-х работа над микроядерными системами остановилась. Хотя рынок верил, что все новые системы будут микроядерными в 90-х, сегодня только одна широко используемая система Mac OS X использует колокейшн-сервер поверх сильно модифицированного ядра Mach 3.

Следующее поколение

[править | править код]

Исследования показали, что проблема производительности IPC не так страшна, как считается. Напоминаем, что односторонний вызов на BSD занимает 20 микросекунд, в то время как на Mach — 114, 11 из которых — это переключение контекста, идентичного BSD. Дополнительно 18 используется менеджером памяти для отображения сообщения между непривилегированной средой исполнения и привилегированной (user-space и kernel-space). Это добавляет 31 микросекунду, что дольше традиционного вызова, но не намного.

Оставшаяся часть проблемы — это проверки прав доступа к порту сообщений. В то время, как это выглядит очень важным, фактически, это требуется только на Unix-системах. К примеру, однопользовательская система, запущенная на мобильном телефоне, может не нуждаться в таких возможностях, и это тот тип систем, в которых Mach может быть использован. Однако Mach создает проблемы: когда память перемещается в ОС, другие задачи могут не нуждаться в этом. DOS и ранние Mac OS имели единое адресное пространство, разделяемое всеми процессами, поэтому в таких системах отображение памяти — пустая трата времени.

Эти реализации положили начало второму поколению микроядер, которое уменьшает сложность системы, размещая большую часть функциональности в непривилегированном режиме исполнения. Например, ядро L4 включает только 7 функций и использует 12 килобайт памяти, тогда как Mach 3 включает около 140 функций и использует 330 килобайт памяти. IPC-вызов на L4 на 486DX-50 занимает только 5 микросекунд — быстрее, чем Unix-вызов на этой же системе, и в 20 раз быстрее, чем Mach. Конечно здесь не учитывается тот факт, что L4 не оперирует разрешениями и безопасностью, оставляя их на усмотрение непривилегированным программам.

«Потенциальные» ускорения L4 основаны на факте, что непривилегированные приложения часто предоставляют множество функций, которые формально поддерживаются ядром. Можно сравнить производительность MkLinux в колокейшн-режиме и порт L4, запущенный в непривилегированном режиме. L4 добавляет только около 5-10 % накладных расходов, в то время как Mach добавляет 15 %, что весьма интересно, если учитывать двойные переключения контекста.

В результате новые микроядра изменили индустрию в целом, множество некогда мертвых проектов вроде GNU Hurd снова привлекло к себе внимание.

Операционные системы и ядра, основанные на Mach

[править | править код]

Примечания

[править | править код]
  1. http://www.cs.cmu.edu/afs/cs/project/mach/public/www/mach.html
  2. The Mach 4 Project Архивная копия от 23 сентября 2017 на Wayback Machine (англ.)
  3. M. Condict, D. Bolinger, E. McManus, D. Mitchell, S. Lewontin. Microkernel modularity with integrated kernel performance (англ.) // Technical report, OSF Research Institute, Cambridge, MA : journal. — 1994. — April.
  4. Hermann Härtig, Michael Hohmuth, Jochen Liedtke, Sebastian Schönberg, Jean Wolter. The performance of μ-kernel-based systems (неопр.) // Proceedings of the 16th ACM symposium on Operating systems principles (SOSP), Saint-Malo, France. — 1997. — October (т. 31, № 5). — С. 67. — doi:10.1145/269005.266660. url2 Архивная копия от 17 февраля 2020 на Wayback Machine