Наборы сигналов

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

#include <signal.h>

int sigemptyset(sigset_t *set);//инициализирует набор сигналов, и помечает его как пустой. Возвращает 0

int sigfillset(sigset_t *set); //инициализирует набор сигналов, и помечает его как полный(все присутствуют). Возвращает 0

int sigaddset(sigset_t *set, int signo);//добавить сигнал в набор

int sigdelset(sigset_t *set, int signo);//удалить сигнал из набора. Возвращает 0 – успешно. -1 если ошибка.

int sigismember(const sigset_t *set, int signo)// 1 – если проверяемый сигнал находится в наборе. 0 если сигнал отсутствует в наборе. -1 при ошибке.

Блокировка сигналов

Для реализации блокировки сигналов используется сигнальная маска. Это набор сигналов, принятие которых будет блокироваться (не обрабатываться) до тех пор, пока они не будут обратно разблокированы. Для управления используется функция

Int sigprocmask(int how, const sigset_t *set, sigset_t, *oldset);

выполнение функции зависит от первого аргумента:

SIG_SETMASK маска меняется на значение второго аргумента.

SIG_BLOCK маска set добавляется к текущему (маски объединяются по ИЛИ)

SIG_UNBLOCK сигналы из set удаляются из вызывающего процесса.

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

#include <signal.h>

Int sigaсtion(int signo, const struct sigactoin *act, struct sigaction *oldact);

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

Void my_handler(int signo)

Void my_handler(int signo, siginfo_t *si, void ucontext )

siginfo_t

{int si_signo;//номер сигнала

int si_errno;//значение ошибки

int si_code;//информация о том, откуда процесс получил сигнал.

…

}

Поле si_code может иметь значения:

SI_KERNEL//сигнал был сгенерирован ядром

SI_TIMER//был сгенерирован по истечении временного интервала.

SI_USER //сигнал был отправлен SIGKILL & raise

Если обрабатывался сигнал SIGCHLD:

CLD_EXITED//потомок завершился нормально, через exit()

CLD_KILLED //потомок был уничтожен

CLD_STOPPED//потомок был остановлен.

2. Проблема тупиков. Алгоритм банкира (13)

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

1. Их требования к объему памяти не будут превышать определенного предела.

2. Каждый вычислительный процесс завершится при условии, что требуемый процессу объем па­мяти будет предоставлен в его распоряжение. Завершение вычислительного процесса будет означать, что его требование к памяти уменьшилось до нуля.

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

Если на вычислительной машине выполняется один процесс, или они последо­вательно следуют один за другим, единственным условием является то, чтобы запрашиваемый процессом объём памяти не превышал доступный объём памяти вычислительной машины. Если параллельно развиваются несколько про­цессов, то могут возникнуть проблемы с выделением им ресурсов и надо преду­смотреть выделение памяти таким образом, чтобы все начатые процессы смогли завершить свое выполнение. Ситуация, когда какой-либо из процессов может быть завершён лишь при условии уничтожения какого-либо другого процесса, называется «смертельными объятиями» или тупиком(рис.).

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

Алгоритм банкира

Банкир обладает конечным капиталом, например, талерами. Он решает при­нимать клиентов, которые могут занимать у него талеры на следующих условиях:

1. Клиент делает заем для совершения сделки, которая будет завершена за определенный про­межуток времени.

2. Клиент должен указать максимальное количество талеров для этой сделки.

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

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

5. Гарантия для клиента, что такой момент наступит, основана на предусмотрительности банкира и на том факте, что остальные клиенты работают по таким же правилам.

Основными вопросами при решении такой задачи являются:

1. При каких условиях банкир может заключить контракт с новым клиентом?

2. При каких условиях банкир может выплатить (следующий) запрашиваемый талер клиенту, не опасаясь попасть в тупик?

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

потребность[i] <= капитал, для всех i.

0 <= заем[i] <= потребность[i], для всех i.

требование[i] = потребность[i] - заем[i], для всех i.

наличные = капитал - СУММА_по_i заем[i].

0 <= наличные <= капитал.

В такой ситуации алгоритм принятия решения о том, будет ли безопасной выдача следующего та­лера, выглядит след образом:

integer Св_Деньги; boolean Безопасно;

boolean array Завершение_под_сомнением [1..N];

Св_Деньги := наличные;

for i := 1 step 1 until N do Завершение_под_сомнением[i] := true;

L: for i :=1 step 1 until N do

begin

if ( (Завершение_под_сомнением [i]) and

(Требован[i] <= Св_Деньги) ) then

begin

Завершение_под_сомнением [i] := false;

Св_Деньги := Cв_Деньги + Заем[i];

goto L;

end;

end;

if (Св_Деньги = капитал) then Безопасно := true

else Безопасно := false;

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

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

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

Если более глубоко анализировать эту проблему, то можно показать, что решение о выделении следующего запрашиваемого талера клиенту будет принято тогда, когда хотя бы для одного клиента выполниться условие ((Завершение_под_сомнением[i]) and (Треб[i]<=Св_Деньги)) и это говорит о безо­пасности ситуации и проверку можно приостановить.