На этой лекции мы с вами обсудим некоторые дополнительные возможности по организации управления ходом процесса в UNIX. Возникает необходимость предоставления в процессе возможности перезапуска в процессе каких-то его веток при возникновении некоторых ситуаций.
Предположим, у нас есть процесс, который занимается обработкой достаточно больших наборов данных, и мы хотим написать процесс, который будет работать следующим образом. В начальный момент времени наш процесс получает некоторый набор данных, и начинает каким-то образом выполнять вычисления. Известно, что при некоторых наборах данных, возможно возникновение внештатных ситуаций, например, переполнение или деление на ноль. Мы бы хотели написать программу, которая обрабатывала бы внештатную ситуацию, и после обработки ее переходила бы снова в начальную точку процесса, загружала бы новые наборы данных и начинала работу с ними.
Для решения такой задачи, мы должны уметь обрабатывать сигналы, возникающие в процессе. Это можно сделать с помощью функции signal и ее возможностей. Кроме того, нам бы хотелось возвращаться в некоторые помеченные в программе точки, не через последовательность входов и выходов из функции, а с помощью безусловного перехода (как бы goto N), потому что механизм обработки сигналов не позволит корректно работать с такой задачей. Можно в принципе написать функцию обработки сигнала, которая при возникновении одного из сигналов делает повторный вызов всей программы. Но это не совсем корректно, т.к. при вызове функции-обработчика сигнала фиксируется состояние стека, и в общем случае система ожидает выхода из функции обработчика через return (при этом система возвращает нас в прерванное место и освобождает стек). Если не будет произведен выход через return, в стеке будет накапливаться ненужная информация, и все это приведет к деградации системы.
Для решения таких задач имеются т.н. нелокальные переходы. Достигаются они с использованием двух функций, которые продекларированы в setjmp.h и имеют следующий интерфейс:
int setjmp(jmp_buf env);
int longjmp(jmp_buf env, int val);
Функция setjmp фиксирует точку обращения к этой функции, т.е. в структуре данных, связанной с переменной env сохраняется текущее состояние процесса (все атрибуты и в т.ч. состояние стека) в точке обращения к setjmp. При обращении к этой функции здесь, setjmp возвращает нулевое значение.
При обращении к функции longjmp(env, val) происходит передача управления на точку, атрибуты которой зафиксированы в структуре env, т.е. в то место, где было обращение к setjmp(env). При этом, после этого перехода setjmp вернет значение val.
Рассмотрим маленький пример.
# include <setjmp.h>
jmp_buf save;
void main(void)
{ int ret;
switch(ret=setjmp(save)){ /* при первой проверке ret будет равно нулю */
case 0: printf("....."); /* этот printf выведет некоторую строку */
a(); /* вызов функции a() */
printf("....."); /* этот printf не сработает никогда */
default: break;
}
}
void a(void)
{ longjmp(save, 1); /* длинный переход на setjmp, ret будет равно 1 */
}
Нелокальный переход - это несколько некорректная возможность операционной системы, потому что нехорошо входить в блочные структуры не через начало и выходить не через конец. Здесь все нарушается. Однако для некоторых ситуаций эти возможности бывают полезны. В частности эти функции могут быть использованы для передачи управления из функции-обработчика сигнала в некоторую точку программы.
Длинный переход корректно работает со стеком. При входе в точку, установленную с помощью setjmp, он восстанавливает все то состояние (в том числе и состояние стека), которое было при установке этой точки. Надо заметить, что longjmp восстанавливает не сам стек, а лишь указатель стека.
Работа со стеком всегда должна удовлетворять правилу: перед обращением к функции и после возврата из нее, уровень стека должен быть одинаковым. Если уровень станет больше или меньше, это гарантировано приведет к проблемам, потому что рано или поздно стек либо переполнится, либо программа полезет за нижний его уровень, что тоже плохо.
Вопрос: предположим мы установили setjmp в некоторой функции, мы вернулись из этой функции, и затем выполнили переход longjmp (т.е. вошли в функцию не сначала). Куда при выходе из этой функции произойдет возврат, потому что в общем случае содержимое стекового кадра этой функции будет случайным (т.к. в буфере env содержится указатель стека, а не сам стек)? Возврат произойдет корректно, т.к. в буфере env адрес возврата будет сохранен, а вот значения автоматических и регистровых переменных этой функции действительно окажется случайным, потому что стек в буфере не сохраняется. Но это есть правила игры. Т.е. здесь на решение программиста налагается ответственность.

До сих пор мы с вами рассматривали взаимодействия, связанные с родственными процессами. Реально, система UNIX имеет набор средств, поддерживающих взаимодействие произвольных процессов. Одно из таких средств - Система Межпроцессного Взаимодействия IPC (InterProcess Communications). Суть этой системы заключается в следующем.
Имеется некоторое количество ресурсов, которые называются в системе разделяемыми. К одному и тому же разделяемому ресурсу может быть организован доступ со стороны произвольного количества произвольных процессов. При этом возникает проблема именования этих разделяемых ресурсов. Если мы вспомним неименованные каналы, за счет того, что каналы передавались по родственному наследованию, всегда в процессе были известны дескрипторы, ассоциированные с каналом. Фактически, если процесс получал доступ к каналу, он уже знал, как именовать этот канал. Здесь использовалось свойство родственной связи, когда какая-то информация, какие-то средства передаются по наследству при формировании сыновьего процесса.
В системе IPC ситуация другая. Есть некоторый ресурс, в общем случае произвольный, и к этому ресурсу могут добираться все, кто может именовать этот ресурс. Для именования такого рода ресурсов в системе предусмотрен механизм генерации т.н. ключей. Суть его заключается в следующем. По некоторым общеизвестным данным (это могут быть текстовые строки или цифровые комбинации) в системе генерируется уникальный ключ, который ассоциируется с разделяемым ресурсом. Если процесс подтверждает этот ключ и созданный разделяемый ресурс доступен для него, то после этого он может работать с указанным разделяемым ресурсом по своему усмотрению.
Разделяемый ресурс создается некоторым процессом-автором. Автор определяет основные свойства ресурса (предположим, размер) и права доступа. Права доступа к ресурсу разделяются на три категории:
1. Права доступа самого автора.
2. Права доступ всех процессов, имеющих тот же идентификатор что и автор.
3. Права доступа остальных.
Итак, система позволяет некоторому процессу создать разделяемый ресурс, защитить его некоторым ключом и забыть о его существовании. После этого все те, кто знают ключ, который открывает этот ресурс, могут работать с содержимым этого ресурса. Возникают проблемы синхронизации доступа к разделяемому ресурсу. Решение этих проблем и другие концептуальные возможности предоставляет система IPC. Начиная со следующей лекции, мы будем рассматривать конкретные средства системы IPC.
Система IPC поддерживает три разновидности разделяемых ресурсов:
1. Разделяемая память. Концептуально - это возможность нескольких процессов иметь общее поле оперативной памяти, и соответственно работать с этим полем, как с неким массивом, на который имеется указатель. Проблема синхронизации здесь стоит особенно остро, но базово средства работы с разделяемой памяти никакой синхронизации не предполагают.
2. Механизм передачи сообщений. Разделяемым ресурсом здесь является очередь сообщений. Эта очередь может содержать произвольное количество (в пределах разумного) сообщений разной длины и разного типа. Тип сообщения - это некоторый атрибут сообщения. Очередь сообщений может рассматриваться как единая очередь всех сообщений в хронологическом порядке, и как множество очередей, содержащих сообщения определенного типа, где в каждой очереди также есть хронологический порядок. Здесь также возникают проблемы синхронизации.
3. Семафоры. Семафоры - это нечто, что позволяет синхронизовать доступ к разделяемым ресурсам.