Н.В. Вдовикина, И.В. Машечкин, А.Н. Терехин, А.Н. Томилин - Операционные системы - взаимодействие процессов (2008), страница 7

Однако,обратная сторона данного решения в том, что оно несколькоснижает производительность процессов-читателей, так каквынуждает их ждать в тот момент, когда ресурс не занят вэксклюзивном режиме.2.2.3 Задача о «спящем парикмахере»Еще одна классическая задача на синхронизацию процессов –это так называемая «задача о спящем парикмахере» [2]. Рассмотримпарикмахерскую, в которой работает один парикмахер, имеется однокресло для стрижки и несколько кресел в приемной для посетителей,ожидающих своей очереди. Если в парикмахерской нет посетителей,30парикмахер засыпает прямо на своем рабочем месте.

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

Несмотряна кажущуюся простоту задачи, понадобится целых 3 семафора:customers – подсчитывает количество посетителей, ожидающих вочереди, barbers – обозначает количество свободных парикмахеров(в случае одного парикмахера его значение либо 0, либо 1) и mutex –используется для синхронизации доступа к разделяемой переменнойwaiting. Переменная waiting, как и семафор customers, содержитколичество посетителей, ожидающих в очереди, она используется впрограмме для того, чтобы иметь возможность проверить, имеетсяли свободное кресло для ожидания, и при этом не заблокироватьпроцесс, если кресла не окажется. Заметим, что как и в предыдущемпримере, эта переменная является разделяемым ресурсом, и доступ кней охраняется семафором mutex. Это необходимо, так как дляобычной переменной, в отличие от семафора, чтение и последующееизменение не являются неделимой операцией.#define CHAIRS 5typedef int semaphore;/* тип данных «семафор» */semaphore customers = 0;/*посетители,ожидающие в очереди */semaphore barbers = 0;/*парикмахеры,ожидающие посетителей */semaphore mutex = 1;/* контроль за доступомпеременной waiting */кint waiting = 0;void barber(){while (true) {down(customers);/* если customers == 0,т.е.посетителейнет,тозаблокируемся до появления посетителя*/31down(mutex);/*получаемwaiting */доступwaiting = wating – 1;/*уменьшаеможидающих клиентов */up(barbers);/*парикмахерработе */up(mutex);/*освобождаемwaiting */cut_hair();ккол-воготовкресурс/* процесс стрижки */}void customer(){down(mutex);/* получаем доступ к waiting */if (waiting < CHAIRS)/*естьместоожидания */для{waiting = waiting + 1; /* увеличиваем колво ожидающих клиентов */up(customers);up(mutex);/*еслипарикмахерспит, это его разбудит *//* освобождаемwaiting */ресурсdown(barbers); /* если парикмахер занят,переходимвсостояниеожидания, иначе – занимаемпарикмахера*/get_haircut();/* процесс стрижки */}else{up(mutex);/* нет свободного кресладляожидания–придетсяуйти */}}32ЧАСТЬ II.

РЕАЛИЗАЦИЯ ПРОЦЕССОВВ этой части пособия мы подробно рассмотрим практическоеприменение понятия процесса в ОС, а также реализацию механизмауправления процессами на примере ОС UNIX.Необходимо понимать, что конкретной ОС с названием UNIX,как таковой, не существует. Говоря об «операционной системеUNIX», мы подразумеваем целое семейство различныхоперационных систем2, в основу которых положены сходные общиеконцепции, структуры и алгоритмы.

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

Некоторыеизвестные авторам различия оговорены в тексте явно. В случаесомнений мы рекомендуем обратиться к документации наконкретную ОС.Стандарт POSIXПо мере эволюции существующих и появления все новых иновых ОС семейства UNIX в UNIX-сообществе зрело стремлениеприйти к единому стандарту UNIX, что позволило бы добитьсяединого понимания средств и устройства ОС и обеспечило быпереносимость программ, написанных под разные ОС семействаUNIX.Стандартом де факто стал POSIX3, разработанный под эгидойавторитетного Института инженеров по электротехнике ирадиоэлектронике (IEEE) и поддержанный Международнойорганизацией по стандартизации (ISO) и Международнойэлектротехнической комиссией (IEC). Этот стандарт представляетсобой группу документов, описывающих такие аспекты ОС UNIX,как системные вызовы, команды UNIX и устройство командногоинтерпретатора, контекст процесса, файловая система, организация2в число которых входят различные версии System V, FreeBSD, Solaris, SunOS, linuxразных семейств и др,3Аббревиатура POSIX – это сокращение от Portable Operating System Interface, т.е.«описание интерсейса переносимых ОС»33защиты и прав доступа, планирование, средства межпроцессноговзаимодействия, а также расширения для ОС реального времени.343 Реализация процессов в ОС UNIX3.1 Понятие процесса в UNIXВыше уже говорилось, что в каждой конкретной ОСсуществует свое системно-ориентированное определение понятияпроцесса.

В UNIX процесс можно определить, с одной стороны, какединицу управления и потребления ресурсов, с другой стороны – какобъект, зарегистрированный в таблице процессов ядра UNIX.Каждому процессу в UNIX сопоставлено некое уникальное целоечисло, называемое идентификатором процесса – PID. Это числонаходится в диапазоне от нуля до некоторого предельного номера,характеризующегомаксимальновозможноеколичествоодновременно существующих процессов в данной ОС. Некоторыезначения идентификаторов являются зарезервированными иназначаются специальным процессам ОС, например, процесс сPID=0 ассоциируется с работой ядра ОС, а процесс с PID=1 – этопроцесс init, работа которого будет подробно рассмотрена ниже.3.1.1 Контекст процессаС точки зрения организации данных ядра ОС, идентификаторпроцесса фактически представляет собой номер записи в таблицепроцессов, соответствующей данному процессу.

Содержимое записитаблицы процессов позволяет получить доступ к контекступроцесса (часть информации, составляющей контекст процесса,хранится непосредственно в таблице процессов, а на структурыданных, содержащие оставшуюся часть контекста, в записи таблицыпроцессов имеются прямые или косвенные ссылки). Таблицапроцессов поддерживается ядром UNIX и находится в адресномпространстве ядра.С точки зрения логической структуры контекст процесса вUNIX состоит из:- пользовательской составляющей или тела процесса(для обозначения этой составляющей иногдаиспользуется термин «пользовательский контекст»)- аппаратной составляющей (иногда обозначаемойтермином «аппаратный контекст»)- системной составляющей ОС UNIX (иногданазываемой«системным контекстом» или«контекстом системного уровня»)35Иногда при рассмотрении контекста процесса два последнихкомпонента объединяют, в этом случае используется терминобщесистемная составляющая контекста.Рассмотрим подробнее каждую из составляющих контекстапроцесса.таблица процессовконтекст процессаPIDсистемныйконтекстаппаратныйконтексттелопроцессасегменткодасегментданныхСтатическиеданныеадресноепр-воядраадресноепр-вопроцессаРазделяемаяпамятьСтекРис.

6 Контекст процесса3.1.2 Тело процессаТело процесса состоит из сегмента кода и сегмента данных4.Сегмент кода содержит машинные команды и неизменяемыеконстанты соответствующей процессу программы. Данные в этомсегменте не подлежат изменению.Сегмент данных содержит данные, динамически изменяемыев ходе выполнения процесса. Сегмент данных содержит областьстатических переменных, область разделяемой с другимипроцессами памяти, а также область стека (обычно эта областьслужит основой для организации автоматических переменных,4Под сегментом здесь мы понимаем область памяти, которой система управляет какединым целым36передачи параметров в функции, организации динамическойпамяти).Некоторые современные ОС имеют возможность разделенияединого сегмента кода между разными процессами.

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

7 Разделение сегмента кода разными экземплярами программыСледует отметить, что при использовании динамическизагружаемых библиотек возможно разделение сегмента кода нанеизменную часть, которая может разделяться между процессами ичасть, соответствующую изменяемому в динамике кодуподгружаемых программ.3.1.3 Аппаратный контекстАппаратная составляющая содержит все регистры иаппаратные таблицы ЦП, используемые активным или исполняемымпроцессом (счетчик команд, регистр состояния процессора, аппаратвиртуальной памяти, регистры общего назначения и т.

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