DAY14 (Старые версии Машбука или нечто подобное)

6

Лекция №14

Лекция №14

Продолжим наш разговор. Мы с Вами рассматривали и рассматриваем проблемы, связанные с организацией и взаимодействием процессов в ОС. К сегодняшнему дню мы с Вами рассмотрели следующие механизмы.

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

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

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

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

Нелокальные переходы.

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

Это средство опирается на два механизма, на две функции:

int setjmp(jmp_buf env);

int longjmp(jmp_buf env, int val);

Обе функции продекларированы в файле setjmp.h. Функция setjmp фиксирует точку обращения к этой функции: в структуре данных (описанной также в файле setjmp.h), связанной с переменной env сохраняется текущее состояние процесса (все его основные атрибуты, например, состояние стека). При обращении к этой функции в таком контексте, setjmp возвращает ноль.

Функция longjmp имеет два параметра: 1-ый - env - структура, содержащая атрибуты процесса в фиксированный момент времени, 2-ой - val - некоторое целочисленное значение. При обращении к функции longjmp с параметрами происходит передача управления на точку, атрибуты которой зафиксированы в переменной env. При этом эмулируется возврат из функции setjmp, и эта функция в данном случае возвратит значение val, т. е. то значение, с которым мы обратились к longjmp.

Довольно сумбурная схемы работы, но все станет ясно на примере:

# include <setjmp.h>

jmp_buf save;

void main(void)

{ int ret;

switch(ret=setjmp(save)){ // при первой проверке ret будет равно нулю

case 0: printf("Text1\n"); // этот printf выведет некоторую строку

a(); // вызов функции a()

printf("Text2\n"); // этот printf никогда не сработает!

default: break;

}

}

void a(void)

{ longjmp(save, 1); // длинный переход на setjmp, ret будет равно 1

}

В нашем примере при первом обращении к setjmp функция возвратит 0, затем напечатается «Text1» и произойдет обращение к функции a(). В теле функции a() мы обращаемся к longjmp с атрибутом процесса save и числом 1. Произойдет переход на точку, в которой была вызвана функция setjmp, произойдет эмуляция выхода из этой функции при этом setjmp вернет значение 0, и мы выйдем из switch, никогда не напечатав «Text2».

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

Длинный переход корректно работает со стеком. При входе в точку, установленную с помощью setjmp, он восстанавливает все то состояние (в том числе и состояние стека), которое было при установке этой точки. Надо заметить, что longjmp восстанавливает не сам стек, а лишь указатель стека.

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

Вопрос: предположим мы установили setjmp в некоторой функции, мы вернулись из этой функции и затем выполнили переход longjmp (т.е. вошли в функцию не сначала). Куда при выходе из этой функции произойдет возврат, потому что в общем случае содержимое стекового кадра этой функции будет случайным (т.к. в буфере env содержится указатель стека, а не сам стек)? Возврат произойдет корректно, т.к. в буфере env адрес возврата будет сохранен, а вот значения автоматических и регистровых переменных этой функции действительно окажется случайным, потому что стек в буфере не сохраняется. Но это есть правила игры. Т.е. здесь на решение программиста налагается ответственность.

Вообще говоря, нелокальные переходы - несколько экзотическое, но достаточно мощное средство программирования. Но его возможностями нужно пользоваться предельно осторожно и аккуратно (Могут возникнуть проблемы со стеком и со значениями автоматических переменных).

Следующий объект нашего рассмотрения - т. н. «Система межпроцессного взаимодействия» (InterProcess Communications, коротко IPC).

Interprocess communication

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

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

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

Разделяемый ресурс создается некоторым процессом-автором. Автор определяет основные свойства ресурса (например, размер) и права доступа. Права доступа к ресурсу разделяются на три категории:

1. Права доступа самого автора.

2. Права доступ всех процессов, имеющих тот же идентификатор что и автор.

3. Права доступа остальных.

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

1. «Общая память»

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

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

1. «Очередь сообщений»

Если в первом типе разделяемых ресурсов процесс-автор создавал «общую» оперативную память, то здесь вводится понятие «очереди сообщений». Ее суть заключается в следующем. Образуется некоторая структура (в смысле организации данных, не в смысле языка C), объединяющая некоторые сообщения. Каждое сообщение может имеет кроме своего тела (содержимого) тип. Сообщения, попадают в эту очередь по правилу FIFO. Мы можем положить/взять сообщение в/из очереди.

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

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

1. «Семафор»

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

Мы рассмотрели основные концепции, лежащие в основе межпроцессного взаимодействия в IPC. Теперь рассмотрим способы реализации IPC средств в UNIX.

Для использования средств IPC в программе должны быть использованы include-файлы:

#include <sys/types.h>

#include <sys/ipc.h>

Рассмотрим первую функцию:

key_t ftok(char *s, char c);

Функция предназначена для генерирования уникального ключа разделяемого ресурса. Суть ее действия - по текстовой строке и символу генерируется уникальное для каждой такой пары значение ключа. После этого сгенерированным ключом можно пользоваться как для создания ресурса, так и для подтверждения использования ресурса. Более того, для исключения коллизий, рекомендуется указывать в качестве параметра "указателя на строку" путь к некоторому своему файлу. Второй аргумент - символьный, который позволяет создавать некоторые варианты ключа, связанного с этим именем, этот аргумент называется проектом (project). При таком подходе можно добиться отсутствия коллизий.

Рассмотрим функции, позволяющие организовывать работу с механизмом «Общая память».