Основные функции и компоненты ядра ОС UNIX

Основные функции и компоненты ядра ОС UNIX В этой части курса мы более подробно остановимся на базовых функциях ядра ОС UNIX. Основная цель этой части - ввести слушателя курса и читателя этого документа в основные идеи ядра ОС UNIX, т.е. показать, чем руководствовались разработчики системы при выборе базовых проектных решений.При этом мы не стремимся излагать технические детали организации ядра, поскольку как это обычно бывает при попытках совместного идейно-технического изложения мы утратили бы явное различие между принципиальными и техническими решениями.

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

Именно эти вопросы мы рассмотрим в данной части курса применительно к ОС UNIX иногда к UNIX вообще, а иногда к UNIX System V . Управление памятьюОсновная или как ее принято называть в отечественной литературе и документации, оперативная память всегда была и остается до сих пор наиболее критическим ресурсом компьютеров.

Если учесть, что большинство современных компьютеров обеспечивает 32-разрядную адресацию в пользовательских программах, и все большую силу набирает новое поколение 64-разрядных компьютеров, то становится понятным, что практически безнадежно рассчитывать, что когда-нибудь удастся оснастить компьютеры основной памятью такого объема, чтобы ее хватило для выполнения произвольной пользовательской программы, не говоря уже об обеспечении мультипрограммного режима, когда в основной памяти, вообще говоря, могут одновременно содержаться несколько пользовательских программ.

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

Операционная система UNIX начинала свое существование с применения очень простых методов управления памятью простой своппинг , но в современных вариантах системы для управления памятью применяется весьма изощренная техника.

Виртуальная памятьИдея виртуальной памяти далеко не нова. Сейчас многие полагают, что в основе этой идеи лежит необходимость обеспечения при поддержке операционной системы видимости практически неограниченной 32- или 64-разрядной адресуемой пользовательской памяти при наличии основной памяти существенно меньших размеров.

Конечно, этот аспект очень важен.Но также важно понимать, что виртуальная память поддерживалась и на компьютерах с 16-разрядной адресацией, в которых объем основной памяти зачастую существенно превышал 64 Кбайта.

Вспомните хотя бы 16-разрядный компьютер PDP-11 70, к которому можно было подключить до 2 Мбайт основной памяти. Другим примером может служить выдающаяся отечественная ЭВМ БЭСМ-6, в которой при 15-разрядной адресации 6-байтовых 48-разрядных машинных слов объем основной памяти был доведен до 256 Кбайт. Операционные системы этих компьютеров тем не менее поддерживали виртуальную память, основным смыслом которой являлось обеспечение защиты пользовательских программ одной от другой и предоставление операционной системе возможности динамически гибко перераспределять основную память между одновременно поддерживаемыми пользовательскими процессами.

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

В наиболее простом и наиболее часто используемом случае страничной виртуальной памяти каждая виртуальная память виртуальная память каждого процесса и физическая основная память представляются состоящими из наборов блоков или страниц одинакового размера.Для удобства реализации размер страницы всегда выбирается равным числу, являющемуся степенью 2. Тогда, если общая длина виртуального адреса есть N в последние годы это тоже всегда некоторая степень 2 - 16, 32, 64 , а размер страницы есть 2M , то виртуальный адрес рассматривается как структура, состоящая из двух полей первое поле занимает N-M 1 разрядов адреса и задает номер страницы виртуальной памяти, второе поле занимает M-1 разрядов и задает смещение внутри страницы до адресуемого элемента памяти в большинстве случаев - байта . Аппаратная интерпретация виртуального адреса показана на рисунке 3.1. Рисунок иллюстрирует механизм на концептуальном уровне, не вдаваясь в детали по поводу того, что из себя представляет и где хранится таблица страниц.

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

При сегментной организации виртуальный адрес по-прежнему состоит из двух полей - номера сегмента и смещения внутри сегмента.

Отличие от страничной организации состоит в том, что сегменты виртуальной памяти могут быть разного размера.

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

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

С небольшими коррективами все обсуждаемые ниже методы и алгоритмы относятся и к сегментной, и сегментно-страничной организациям.

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

Английский термин demand paging листание по требованию достаточно точно характеризует функции, выполняемые этим компонентом.Когда программа обращается к виртуальной странице, отсутствующей в основной памяти, т.е. требует доступа к данным или программному коду, операционная система удовлетворяет это требование путем выделения страницы основной памяти, перемещения в нее копии страницы, находящейся во внешней памяти, и соответствующей модификации элемента таблицы страниц.

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

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

Существует большое количество разнообразных алгоритмов подкачки. Объем этого курса не позволяет рассмотреть их подробно. Соответствующий материал можно найти в изданных на русском языке книгах по операционным системам Цикритзиса и Бернстайна, Дейтела и Краковяка.Однако, чтобы вернуться к описанию конкретных методов управления виртуальной памятью, применяемых в ОС UNIX, мы все же приведем некоторую краткую классификацию алгоритмов подкачки.

Во-первых, алгоритмы подкачки делятся на глобальные и локальные. При использовании глобальных алгоритмов операционная система при потребности замещения ищет страницу основной памяти среди всех страниц, независимо от их принадлежности к какой-либо виртуальной памяти.Локальные алгоритмы предполагают, что если возникает требование доступа к отсутствующей в основной памяти странице виртуальной памяти ВП1, то страница для замещения будет искаться только среди страниц основной памяти, приписанных к той же виртуальной памяти ВП1. Наиболее распространенными традиционными алгоритмами как в глобальном, так в локальном вариантах являются алгоритмы FIFO First In First Out и LRU Least Recently Used . При использовании алгоритма FIFO для замещения выбирается страница, которая дольше всего остается приписанной к виртуальной памяти.

Алгоритм LRU предполагает, что замещать следует ту страницу, к которой дольше всего не происходили обращения.

Хотя интуитивно кажется, что критерий алгоритма LRU является более правильным, известны ситуации, в которых алгоритм FIFO работает лучше и, кроме того, он гораздо более дешево реализуется . Заметим еще, что при использовании глобальных алгоритмов, вне зависимости от конкретного применяемого алгоритма, возможны и теоретически неизбежны критические ситуации, которые называются по-английски thrashing несмотря на множество попыток, хорошего русского эквивалента так и не удалось придумать . Рассмотрим простой пример.

Пусть на компьютере в мультипрограммном режиме выполняются два процесса - П1 в виртуальной памяти ВП1 и П2 в виртуальной памяти ВП2, причем суммарный размер ВП1 и ВП2 больше размеров основной памяти.Предположим, что в момент времени t1 в процессе П1 возникает требование виртуальной страницы ВС1. Операционная система обрабатывает соответствующее прерывание и выбирает для замещения страницу основной памяти С2, приписанную к виртуальной странице ВС2 виртуальной памяти ВП2 т.е. в элементе таблицы страниц, соответствующем ВС2, проставляется флаг отсутствия страницы . Для полной обработки требования доступа к ВС1 в общем случае потребуется два обмена с внешней памятью первый, чтобы записать текущее содержимое С2, второй - чтобы прочитать копию ВС1 . Поскольку операционная система поддерживает мультипрограммный режим работы, то во время выполнения обменов доступ к процессору получит процесс П2, и он, вполне вероятно, может потребовать доступа к своей виртуальной странице ВС2 которую у него только что отняли . Опять будет обрабатываться прерывание, и ОС может заменить некоторую страницу основной памяти С3, которая приписана к виртуальной странице ВС3 в ВП1. Когда закончатся обмены, связанные с обработкой требования доступа к ВС1, возобновится процесс П1, и он, вполне вероятно, потребует доступа к своей виртуальной странице ВС3 которую у него только что отобрали . И так далее.

Общий эффект состоит в том, что непрерывно работает операционная система, выполняя бесчисленные и бессмысленные обмены с внешней памятью, а пользовательские процессы П1 и П2 практически не продвигаются.

Понятно, что при использовании локальных алгоритмов ситуация thrashing, затрагивающая несколько процессов, невозможна.

Однако в принципе возможна аналогичная ситуация внутри одной виртуальной памяти ОС может каждый раз замещать ту страницу, к которой процесс обратится в следующий момент времени.Единственным алгоритмом, теоретически гарантирующим отсутствие thrashing, является так называемый оптимальный алгоритм Биледи по имени придумавшего его венгерского математика . Алгоритм заключается в том, что для замещения следует выбирать страницу, к которой в будущем наиболее долго не будет обращений.

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

Принцип локальности ссылок недоказуемый, но подтверждаемый на практике состоит в том, что если в период времени T-t, T программа обращалась к страницам С1, С2 Сn , то при надлежащем выборе t с большой вероятностью эта программа будет обращаться к тем же страницам в период времени T, T t . Другими словами, принцип локальности утверждает, что если не слишком далеко заглядывать в будущее, то можно хорошо его прогнозировать исходя из прошлого.

Набор страниц С1, С2 Сn называется рабочим набором программы или, правильнее, соответствующего процесса в момент времени T. Понятно, что с течением времени рабочий набор процесса может изменяться как по составу страниц, так и по их числу . Идея алгоритма подкачки Деннинга иногда называемого алгоритмом рабочих наборов состоит в том, что операционная система в каждый момент времени должна обеспечивать наличие в основной памяти текущих рабочих наборов всех процессов, которым разрешена конкуренция за доступ к процессору.

Мы не будем вдаваться в технические детали алгоритма, а лишь заметим следующее.Во-первых, полная реализация алгоритма Деннинга практически гарантирует отсутствие thrashing.

Во-вторых, алгоритм реализуем известна, по меньшей мере, одна его полная реализация, которая однако потребовала специальной аппаратной поддержки . В-третьих, полная реализация алгоритма Деннинга вызывает очень большие накладные расходы. Поэтому на практике применяются облегченные варианты алгоритмов подкачки, основанных на идее рабочего набора.Один из таких вариантов применяется и в ОС UNIX насколько нам известно, во всех версиях системы, относящихся к ветви System V . Мы кратко опишем этот вариант в п. 3.1.3. Аппаратно-независимый уровень управления памятьюМатериал, приведенный в данном разделе, хотя и не отражает в полном объеме все проблемы и решения, связанные с управлением виртуальной памятью, достаточен для того, чтобы осознать важность и сложность соответствующих компонентов операционной системы.

В любой операционной системе управление виртуальной памятью занимает центральное место. Когда-то Игорь Силин основной разработчик известной операционной системы Дубна для БЭСМ-6 выдвинул тезис, известный в народе как Тезис Силина Расходы, затраченные на управление виртуальной памятью, окупаются . Я думаю, что любой специалист в области операционных систем согласится с истинностью этого тезиса.

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

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

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

В чем же состоит это абстрактное представление виртуальной памяти? Во-первых, виртуальная память каждого процесса представляется в виде набора сегментов рисунок 3.3 . Рис. 3.3. Сегментная структура виртуального адресного пространства Как видно из рисунка, виртуальная память процесса ОС UNIX разбивается на сегменты пяти разных типов.

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

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

Этот сегмент, очевидно, должен быть динамическим т.е. доступным и по чтению, и по записи , и он, также очевидно, должен быть частным приватным сегментом процесса.

Разделяемый сегмент виртуальной памяти образуется при подключении к ней сегмента разделяемой памяти см. п. 3.4.1 . По определению, такие сегменты предназначены для координированного совместного использования несколькими процессами.

Поэтому разделяемый сегмент должен допускать доступ по чтению и по записи и может разделяться несколькими процессами. Сегменты файлов, отображаемых в виртуальную память см. п. 2.4.5 , представляют собой разновидность разделяемых сегментов.Разница состоит в том, что если при необходимости освободить оперативную память страницы разделяемых сегментов копируются откачиваются в специальную системную область подкачки swapping space на диске, то страницы сегментов файлов, отображаемых в виртуальную память, в случае необходимости откачиваются прямо на свое место в области внешней памяти, занимаемой файлом. Такие сегменты также допускают доступ и по чтению, и по записи и являются потенциально совместно используемыми.

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

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

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

Второй список - это список описателей свободных страниц, т.е. таких страниц, которые не подключены ни к одной виртуальной памяти.

Такие страницы свободны для использования и могут быть подключены к любой виртуальной памяти.Наконец, третий список страниц включает описатели так называемых анонимных страниц, т.е. таких страниц, которые могут изменяться, но для которых нет родного места во внешней памяти.

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

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

Конечно, в результате сложность переноса той части ОС UNIX, которая относится к управлению виртуальной памятью, определяется сложностью написания аппаратно-зависимой части.

Чем ближе архитектура аппаратуры, поддерживающей виртуальную память, к абстрактной модели виртуальной памяти ОС UNIX, тем проще перенос.Для справедливости заметим, что в подавляющем большинстве современных компьютеров аппаратура выполняет функции, существенно превышающие потребности модели UNIX, так что создание новой аппаратно-зависимой части подсистемы управления виртуальной памятью ОС UNIX в большинстве случаев не является чрезмерно сложной задачей. Страничное замещение основной памяти и swappingКак мы упоминали в конце п. 3.1.1, в ОС UNIX используется некоторый облегченный вариант алгоритма подкачки, основанный на использовании понятия рабочего набора.

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

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

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

Откачку страниц, не входящих в рабочие наборы процессов, производит специальный системный процесс-stealer. Он начинает работать, когда количество страниц в списке свободных страниц достигает установленного нижнего порога.Функцией этого процесса является анализ необходимости откачки страницы на основе признака изменения и запись копии страницы если это требуется в соответствующую область внешней памяти т.е. либо в системную область подкачки - swapping space для анонимных страниц, либо в некоторый блок файловой системы для страницы, входящей в сегмент отображаемого файла . Очевидно, рабочий набор любого процесса может изменяться во время его выполнения.

Другими словами, возможна ситуация, когда процесс обращается к виртуальной странице, отсутствующей в основной памяти. В этом случае, как обычно, возникает аппаратное прерывание, в результате которого начинает работать операционная система. Дальнейший ход событий зависит от обстоятельств.Если список описателей свободных страниц не пуст, то из него выбирается некоторый описатель, и соответствующая страница подключается к виртуальной памяти процесса конечно, после считывания из внешней памяти содержимого копии этой страницы, если это требуется . Но если возникает требование страницы в условиях, когда список описателей свободных страниц пуст, то начинает работать механизм своппинга. Основной повод для применения другого механизма состоит в том, что простое отнятие страницы у любого процесса включая тот, который затребовал бы страницу потенциально вело бы к ситуации thrashing, поскольку разрушало бы рабочий набор некоторого процесса . Любой процесс, затребовавший страницу не из своего текущего рабочего набора, становится кандидатом на своппинг.

Ему больше не предоставляются ресурсы процессора, и описатель процесса ставится в очередь к системному процессу-swapper.

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

После завершения полного своппинга каждого процесса одному из процессов из очереди к процессу-swapper дается возможность попытаться продолжить свое выполнение в расчете на то, что свободной памяти уже может быть достаточно . Заметим, что мы описали наиболее сложный алгоритм, когда бы то ни было использовавшийся в ОС UNIX. В последней фактически стандартной версии ОС UNIX System V Release 4 используется более упрощенный алгоритм. Это глобальный алгоритм, в котором вероятность thrashing погашается за счет своппинга.

Используемый алгоритм называется NRU Not Recently Used или clock.Смысл алгоритма состоит в том, что процесс-stealer периодически очищает признаки обращения всех страниц основной памяти, входящих в виртуальную память процессов отсюда название clock . Если возникает потребность в откачке т.е. достигнут нижний предел размера списка описателей свободных страниц , то stealer выбирает в качестве кандидатов на откачку прежде всего те страницы, к которым не было обращений по записи после последней очистки и у которых нет признака модификации т.е. те, которые можно дешевле освободить . Во вторую очередь выбираются страницы, которые действительно нужно откачивать.

Параллельно с этим работает описанный выше алгоритм своппинга, т.е. если возникает требование страницы, а свободных страниц нет, то соответствующий процесс становится кандидатом на своппинг. В заключение затронем еще одну важную тему, непосредственно связанную с управлением виртуальной памятью - копирование страниц при попытке записи copy on write . Как мы отмечали в п. 2.1.7, при выполнении системного вызова fork ОС UNIX образует процесс-потомок, являющийся полной копией своего предка.

Тем не менее, у потомка своя собственная виртуальная память, и те сегменты, которые должны быть его частными сегментами, в принципе должны были бы полностью скопироваться.

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

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

Управление процессами и нитямиВ операционной системе UNIX традиционно поддерживается классическая схема мультипрограммирования.Система поддерживает возможность параллельного или квази-параллельного в случае наличия только одного аппаратного процессора выполнения нескольких пользовательских программ.

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

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

Любая программа ядра может начать работать только по инициативе некоторого пользовательского процесса при выполнении системного вызова , либо по причине внутреннего или внешнего прерывания примером внутреннего прерывания может быть прерывание из-за отсутствия в основной памяти требуемой страницы виртуальной памяти пользовательского процесса примером внешнего прерывания является любое прерывание процессора по инициативе внешнего устройства . В любом случае считается, что выполняется ядерная часть обратившегося или прерванного процесса, т.е. ядро всегда работает в контексте некоторого процесса.

В последние годы в связи с широким распространением так называемых симметричных мультипроцессорных архитектур компьютеров Symmetric Multiprocessor Architectures - SMP в ОС UNIX был внедрен механизм легковесных процессов light-weight processes , или нитей, или потоков управления threads . Говоря по-простому, нить - это процесс, выполняющийся в виртуальной памяти, используемой совместно с другими нитями того же тяжеловесного т.е. обладающего отдельной виртуальной памятью процесса.

В принципе, легковесные процессы использовались в операционных системах много лет назад. Уже тогда стало ясно, что программирование с неконтролируемым использованием общей памяти приносит больше хлопот и неприятностей, чем пользы, по причине необходимости использования явных примитивов синхронизации.

Однако, до настоящего времени в практику программистов так и не были внедрены более безопасные методы параллельного программирования, а реальные возможности мультипроцессорных архитектур для обеспечения распараллеливания нужно было как-то использовать.Поэтому опять в обиход вошли легковесные процессы, которые теперь получили название threads нити . Наиболее важно с нашей точки зрения то, что для внедрения механизма нитей потребовалась существенная переделка ядра. Разные производители аппаратуры и программного обеспечения стремились как можно быстрее выставить на рынок продукт, пригодный для эффективного использования на SMP-платформах.

Поэтому версии ОС UNIX опять несколько разошлись. Все эти вопросы мы обсудим более подробно в данном разделе.Пользовательская и ядерная составляющие процессовКаждому процессу соответствует контекст, в котором он выполняется.

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

Контекст процесса системного уровня в ОС UNIX состоит из статической и динамических частей. Для каждого процесса имеется одна статическая часть контекста системного уровня и переменное число динамических частей. Статическая часть контекста процесса системного уровня включает следующее 1. Описатель процесса, т.е. элемент таблицы описателей существующих в системе процессов.Описатель процесса включает, в частности, следующую информацию состояние процесса физический адрес в основной или внешней памяти u-области процесса идентификаторы пользователя, от имени которого запущен процесс идентификатор процесса прочую информацию, связанную с управлением процессом. 2. U-область u-area - индивидуальная для каждого процесса область пространства ядра, обладающая тем свойством, что хотя u-область каждого процесса располагается в отдельном месте физической памяти, u-области всех процессов имеют один и тот же виртуальный адрес в адресном пространстве ядра. Именно это означает, что какая бы программа ядра не выполнялась, она всегда выполняется как ядерная часть некоторого пользовательского процесса, и именно того процесса, u-область которого является видимой для ядра в данный момент времени.

U-область процесса содержит указатель на описатель процесса идентификаторы пользователя счетчик времени, в течение которого процесс реально выполнялся т.е. занимал процессор в режиме пользователя и режиме ядра параметры системного вызова результаты системного вызова таблица дескрипторов открытых файлов предельные размеры адресного пространства процесса предельные размеры файла, в который процесс может писать и т.д. Динамическая часть контекста процесса - это один или несколько стеков, которые используются процессом при его выполнении в режиме ядра. Число ядерных стеков процесса соответствует числу уровней прерывания, поддерживаемых конкретной аппаратурой.

Принципы организации многопользовательского режимаОсновной проблемой организации многопользовательского правильнее сказать, мультипрограммного режима в любой операционной системе является организация планирования параллельного выполнения нескольких процессов.

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

Однако в последнее время возрастает тенденция к использованию ОС UNIX в приложениях реального времени, что повлияло и на алгоритмы планирования. Ниже мы опишем общую без технических деталей схему планирования разделения ресурсов процессора ов между процессами в UNIX System V Release 4. Наиболее распространенным алгоритмом планирования в системах разделения времени является кольцевой режим round robin . Основной смысл алгоритма состоит в том, что время процессора делится на кванты фиксированного размера, а процессы, готовые к выполнению, выстраиваются в кольцевую очередь.

У этой очереди имеются два указателя - начала и конца. Когда процесс, выполняющийся на процессоре, исчерпывает свой квант процессорного времени, он снимается с процессора, ставится в конец очереди, а ресурсы процессора отдаются процессу, находящемуся в начале очереди.

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

Однако ОС UNIX всегда была рассчитана на то, чтобы обслуживать больше процессов, чем можно одновременно разместить в основной памяти.

Другими словами, часть процессов, потенциально готовых выполняться, размещалась во внешней памяти куда образ памяти процесса попадал в результате своппинга . Поэтому требовалась несколько более гибкая схема планирования разделения ресурсов процессора ов . В результате было введено понятие приоритета. В ОС UNIX значение приоритета определяет, во-первых, возможность процесса пребывать в основной памяти и на равных конкурировать за процессор.Во-вторых, от значения приоритета процесса, вообще говоря, зависит размер временного кванта, который предоставляется процессу для работы на процессоре при достижении своей очереди.

В-третьих, значение приоритета, влияет на место процесса в общей очереди процессов к ресурсу процессора ов . Схема разделения времени между процессами с приоритетами в общем случае выглядит следующим образом. Готовые к выполнению процессы выстраиваются в очередь к процессору в порядке уменьшения своих приоритетов.Если некоторый процесс отработал свой квант процессорного времени, но при этом остался готовым к выполнению, то он становится в очередь к процессору впереди любого процесса с более низким приоритетом, но вслед за любым процессом, обладающим тем же приоритетом. Если некоторый процесс активизируется, то он также ставится в очередь вслед за процессом, обладающим тем же приоритетом.

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

Традиционное решение ОС UNIX состоит в использовании динамически изменяющихся приоритетов. Каждый процесс при своем образовании получает некоторый устанавливаемый системой статический приоритет, который в дальнейшем может быть изменен с помощью системного вызова nice см. п. 3.1.3 . Этот статический приоритет является основой начального значения динамического приоритета процесса, являющегося реальным критерием планирования.Все процессы с динамическим приоритетом не ниже порогового участвуют в конкуренции за процессор по схеме, описанной выше . Однако каждый раз, когда процесс успешно отрабатывает свой квант на процессоре, его динамический приоритет уменьшается величина уменьшения зависит от статического приоритета процесса . Если значение динамического приоритета процесса достигает некоторого нижнего предела, он становится кандидатом на откачку своппинг и больше не конкурирует за процессор.

Процесс, образ памяти которого перемещен во внешнюю память, также обладает динамическим приоритетом.

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

После того, как в результате своппинга будет освобождена достаточная по размерам область основной памяти, процесс с приоритетом, достигшим критического значения, будет перемещен в основную память и будет в соответствии со своим приоритетом конкурировать за процессор. Как вписываются в эту схему процессы реального времени? Прежде всего, нужно разобраться, что понимается под концепцией реального времени в ОС UNIX. Известно, что существуют по крайней мере два понимания термина - мягкое реальное время soft realtime и жесткое реальное время hard realtime . Жесткое реальное время означает, что каждое событие внутреннее или внешнее , происходящее в системе обращение к ядру системы за некоторой услугой, прерывание от внешнего устройства и т.д должно обрабатываться системой за время, не превосходящее верхнего предела времени, отведенного для таких действий.

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

Режим мягкого реального времени, в отличие от этого, предполагает, что некоторые процессы процессы реального времени получают права на получение ресурсов основной памяти и процессора ов , существенно превосходящие права процессов, не относящихся к категории процессов реального времени.

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

Это делается способом, не выходящим за пределы основополагающего принципа разделения времени. Как мы отмечали выше, имеется некоторый диапазон значений статических приоритетов процессов.Некоторый поддиапазон этого диапазона включает значения статических приоритетов процессов реального времени.

Процессы, обладающие динамическими приоритетами, основанными на статических приоритетах процессов реального времени, обладают следующими особенностями 1. Каждому из таких процессов предоставляется неограниченный сверху квант времени на процессоре.Другими словами, занявший процессор процесс реального времени не будет с него снят до тех пор, пока сам не заявит о невозможности продолжения выполнения например, задав обмен с внешним устройством . 2. Процесс реального времени не может быть перемещен из основной памяти во внешнюю, если он готов к выполнению, и в оперативной памяти присутствует хотя бы один процесс, не относящийся к категории процессов реального времени т.е. процессы реального времени перемещаются во внешнюю память последними, причем в порядке убывания своих динамических приоритетов . 3. Любой процесс реального времени, перемещенный во внешнюю память, но готовый к выполнению, переносится обратно в основную память как только в ней образуется свободная область соответствующего размера. Выбор процесса реального времени для возвращения в основную память производится на основании значений динамических приоритетов.

Тем самым своеобразным, но логичным образом в современных вариантах ОС UNIX одновременно реализована как возможность разделения времени для интерактивных процессов, так и возможность мягкого реального времени для процессов, связанных с реальным управлением поведением объектов в реальном времени.

Традиционный механизм управления процессами на уровне пользователяКак свойственно операционной системе UNIX вообще, имеются две возможности управления процессами - с использованием командного языка того или другого варианта Shell и с использованием языка программирования с непосредственным использованием системных вызовов ядра операционной системы.

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

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

Наконец, каждый процесс может повлиять на значение своего статического а тем самым и динамического приоритета с помощью системного вызова nice. Для создания нового процесса используется системный вызов fork. В среде программирования нужно относиться к этому системному вызову как к вызову функции, возвращающей целое значение - идентификатор порожденного процесса, который затем может использоваться для управления в ограниченном смысле порожденным процессом.

Реально, все процессы системы UNIX, кроме начального, запускаемого при раскрутке системы, образуются при помощи системного вызова fork. Вот что делает ядро системы при выполнении системного вызова fork 1. Выделяет память под описатель нового процесса в таблице описателей процессов. 2. Назначает уникальный идентификатор процесса PID для вновь образованного процесса. 3. Образует логическую копию процесса, выполняющего системный вызов fork, включая полное копирование содержимого виртуальной памяти процесса-предка во вновь создаваемую виртуальную память, а также копирование составляющих ядерного статического и динамического контекстов процесса-предка. 4. Увеличивает счетчики открытия файлов процесс-потомок автоматически наследует все открытые файлы своего родителя . 5. Возвращает вновь образованный идентификатор процесса в точку возврата из системного вызова в процессе-предке и возвращает значение 0 в точке возврата в процессе-потомке.

Понятно, что после создания процесса предок и потомок начинают жить своей собственной жизнью, произвольным образом изменяя свой контекст.

В частности, и предок, и потомок могут выполнить какой-либо из вариантов системного вызова exec см. ниже , приводящего к полному изменению контекста процесса. Чтобы процесс-предок мог синхронизовать свое выполнение с выполнением своих процессов-потомков, существует системный вызов wait. Выполнение этого системного вызова приводит к приостановке выполнения процесса до тех пор, пока не завершится выполнение какого-либо из процессов, являющихся его потомками.

В качестве прямого параметра системного вызова wait указывается адрес памяти указатель , по которому должна быть возвращена информация, описывающая статус завершения очередного процесса-потомка, а ответным возвратным параметром является PID идентификатор процесса завершившегося процесса-потомка.

Сигнал - это способ информирования процесса со стороны ядра о происшествии некоторого события. Смысл термина сигнал состоит в том, что сколько бы однотипных событий в системе не произошло, по поводу каждой такой группы событий процессу будет подан ровно один сигнал.Т.е. сигнал означает, что определяемое им событие произошло, но не несет информации о том, сколько именно произошло однотипных событий.

Примерами сигналов не исчерпывающими все возможности являются следующие окончание процесса-потомка по причине выполнения системного вызова exit или системного вызова signal с параметром death of child смерть потомка возникновение исключительной ситуации в поведении процесса выход за допустимые границы виртуальной памяти, попытка записи в область виртуальной памяти, которая доступна только для чтения и т.д. превышение верхнего предела системных ресурсов оповещение об ошибках в системных вызовах несуществующий системный вызов, ошибки в параметрах системного вызова, несоответствие системного вызова текущему состоянию процесса и т.д. сигналы, посылаемые другим процессом в пользовательском режиме см. ниже сигналы, поступающие вследствие нажатия пользователем определенных клавишей на клавиатуре терминала, связанного с процессом например, Ctrl-C или Ctrl-D сигналы, служащие для трассировки процесса. Для установки реакции на поступление определенного сигнала используется системный вызов oldfunction signal signum, function , где signum - это номер сигнала, на поступление которого устанавливается реакция все возможные сигналы пронумерованы, каждому номеру соответствует собственное символическое имя соответствующая информация содержится в документации к каждой конкретной системе UNIX , а function - адрес указываемой пользователем функции, которая должна быть вызвана системой при поступлении указанного сигнала данному процессу.

Возвращаемое значение oldfunction - это адрес функции для реагирования на поступление сигнала signum, установленный в предыдущем вызове signal.

Вместо адреса функции во входных параметрах можно задать 1 или 0. Задание единицы приводит к тому, что далее для данного процесса поступление сигнала с номером signum будет игнорироваться это допускается не для всех сигналов . Если в качестве значения параметра function указан нуль, то после выполнения системного вызова signal первое же поступление данному процессу сигнала с номером signum приведет к завершению процесса будет проинтерпретировано аналогично выполнению системного вызова exit, см. ниже . Система предоставляет возможность для пользовательских процессов явно генерировать сигналы, направляемые другим процессам.

Для этого используется системный вызов kill pid, signum Этот системный вызов называется kill , потому что наиболее часто применяется для того, чтобы принудительно закончить указанный процесс.

Параметр signum задает номер генерируемого сигнала в системном вызове kill можно указывать не все номера сигналов . Параметр pid имеет следующие смысл если в качестве значения pid указано целое положительное число, то ядро пошлет указанный сигнал процессу, идентификатор которого равен pid если значение pid равно нулю, то указанный сигнал посылается всем процессам, относящимся к той же группе процессов, что и посылающий процесс понятие группы процессов аналогично понятию группы пользователей полный идентификатор процесса состоит из двух частей - идентификатора группы процессов и индивидуального идентификатора процесса в одну группу автоматически включаются все процессы, имеющие общего предка идентификатор группы процесса может быть изменен с помощью системного вызова setpgrp если значение pid равно -1, то ядро посылает указанный сигнал всем процессам, действительный идентификатор пользователя которых равен идентификатору текущего выполнения процесса, посылающего сигнал см. п. 2.5.1 . Для завершения процесса по его собственной инициативе используется системный вызов exit status , где status - это целое число, возвращаемое процессу-предку для его информирования о причинах завершения процесса-потомка как описывалось выше, для получения информации о статусе завершившегося процесса-потомка в процессе-предке используется системный вызов wait . Системный вызов называется exit т.е. выход , поскольку считается, что любой пользовательский процесс запускается ядром системы собственно, так оно и есть , и завершение пользовательского процесса - это окончательный выход из него в ядро. Системный вызов exit может задаваться явно в любой точке процесса, но может быть и неявным.

В частности, при программировании на языке Си возврат из функции main приводит к выполнению неявно содержащегося в программе системного вызова exit с некоторым предопределенным статусом.

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

Возможности управления процессами, которые мы обсудили до этого момента, позволяют образовать новый процесс, являющийся полной копией процесса-предка системный вызов fork дожидаться завершения любого образованного таким образом процесса системный вызов wait порождать сигналы и реагировать на них системные вызовы kill и signal завершать процесс по его собственной инициативе системный вызов exit . Однако пока остается непонятным, каким образом можно выполнить в образованном процессе произвольную программу.

Понятно, что в принципе этого можно было бы добиться с помощью системного вызова fork, если образ памяти процесса-предка заранее построен так, что содержит все потенциально требуемые программы. Но, конечно, этот способ не является рациональным хотя бы потому, что заведомо приводит к перерасходу памяти . Для выполнения произвольной программы в текущем процессе используются системные вызовы семейства exec. Разные варианты exec слегка различаются способом задания параметров.

Здесь мы не будем вдаваться в детали за ними лучше обращаться к документации по конкретной реализации . Рассмотрим некоторый обобщенный случай системного вызова exec filename, argv, argc, envp Вот что происходит при выполнении этого системного вызова.

Берется файл с именем filename может быть указано полное или сокращенное имя файла . Этот файл должен быть выполняемым файлом, т.е. представлять собой законченный образ виртуальной памяти.

Если это на самом деле так, то ядро ОС UNIX производит реорганизацию виртуальной памяти процесса, обратившегося к системному вызову exec, уничтожая в нем старые сегменты и образуя новые сегменты, в которые загружаются соответствующие разделы файла filename.

После этого во вновь образованном пользовательском контексте вызывается функция main, которой, как и полагается, передаются параметры argv и argc, т.е. некоторый набор текстовых строк, заданных в качестве параметра системного вызова exec. Через параметр envp обновленный процесс может обращаться к переменным своего окружения.

Следует заметить, что при выполнении системного вызова exec не образуется новый процесс, а лишь меняется содержимое виртуальной памяти существующего процесса. Другими словами, меняется только пользовательский контекст процесса.Полезные возможности ОС UNIX для общения родственных или независимо образованных процессов рассматриваются ниже в разделе 3.4. Понятие нити threads Понятие легковесного процесса light-weight process , или, как принято называть его в современных вариантах ОС UNIX, thread нить, поток управления давно известно в области операционных систем.

Интуитивно понятно, что концепции виртуальной памяти и потока команд, выполняющегося в этой виртуальной памяти, в принципе, ортогональны.Ни из чего не следует, что одной виртуальной памяти должен соответствовать один и только один поток управления.

Поэтому, например, в ОС Multics раздел 1.1 допускалось и являлось принятой практикой иметь произвольное количество процессов, выполняемых в общей разделяемой виртуальной памяти. Понятно, что если несколько процессов совместно пользуются некоторыми ресурсами, то при доступе к этим ресурсам они должны синхронизоваться например, с использованием семафоров, см. п. 3.4.2 . Многолетний опыт программирования с использованием явных примитивов синхронизации показал, что этот стиль параллельного программирования порождает серьезные проблемы при написании, отладке и сопровождении программ наиболее трудно обнаруживаемые ошибки в программах обычно связаны с синхронизацией . Это явилось одной из причин того, что в традиционных вариантах ОС UNIX понятие процесса жестко связывалось с понятием отдельной и недоступной для других процессов виртуальной памяти.

Каждый процесс был защищен ядром операционной системы от неконтролируемого вмешательства других процессов.

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

Поэтому традиционный подход ОС UNIX препятствовал использованию системы в приложениях реального времени.Второй и может быть более существенной проблемой явилось появление так называемых симметричных мультипроцессорных компьютерных архитектур SMP - Symmetric Multiprocessor Architectures . В таких компьютерах физически присутствуют несколько процессоров, которые имеют одинаковые по скорости возможности доступа к совместно используемой основной памяти.

Появление подобных машин на мировом рынке, естественно, поставило проблему их эффективного использования.Понятно, что при применении традиционного подхода ОС UNIX к организации процессов от наличия общей памяти не очень много толка хотя при наличии возможностей разделяемой памяти см. п. 3.4.1 об этом можно спорить . К моменту появления SMP выяснилось, что технология программирования все еще не может предложить эффективного и безопасного способа реального параллельного программирования.

Поэтому пришлось вернуться к явному параллельному программированию с использованием параллельных процессов в общей виртуальной а тем самым, и основной памяти с явной синхронизацией.Что же понимается под нитью thread ? Это независимый поток управления, выполняемый в контексте некоторого процесса.

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

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

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

Всегда трудно внедрить в программу средства, для поддержки которых она не была изначально приспособлена. Подходы к организации нитей и управлению ими в разных вариантах ОС UNIXХотя концептуально реализации механизма нитей в разных современных вариантах практически эквивалентны да и что особенное можно придумать по поводу легковесных процессов технически и, к сожалению, в отношении интерфейсов эти реализации различаются.Мы не ставим здесь перед собой цели описать в деталях какую-либо реализацию, однако постараемся в общих чертах охарактеризовать разные подходы.

Начнем с того, что разнообразие механизмов нитей в современных вариантах ОС UNIX само по себе представляет проблему.Сейчас достаточно трудно говорить о возможности мобильного параллельного программирования в среде UNIX-ориентированных операционных систем. Если программист хочет добиться предельной эффективности а он должен этого хотеть, если для целей его проекта приобретен дорогостоящий мультипроцессор , то он вынужден использовать все уникальные возможности используемой им операционной систем