- •Н.В.Вдовикина, а.В.Казунин, и.В.Машечкин, а.Н.Терехин Системное программное обеспечение: взаимодействие процессов.
- •Часть I. Теоретические основы. 5
- •Часть II. Реализация процессов. 34
- •Часть III. Реализация взаимодействия процессов. 62
- •6.4Семафоры. 116
- •Часть I. Теоретические основы.
- •Введение.
- •Понятие процесса.
- •Некоторые типы процессов.
- •«Полновесные процессы»
- •«Легковесные процессы»
- •Жизненный цикл процесса.
- •Синхронизация параллельных процессов.
- •Способы реализации взаимного исключения.
- •Запрещение прерываний и специальные инструкции.
- •Алгоритм Петерсона.
- •Активное ожидание.
- •Семафоры.
- •Мониторы.
- •Дополнительная синхронизация: переменные-условия.
- •Обмен сообщениями.
- •Синхронизация.
- •Адресация.
- •Длина сообщения.
- •Классические задачи синхронизации процессов.
- •«Обедающие философы»
- •Задача «читателей и писателей»
- •Задача о «спящем парикмахере»
- •Часть II. Реализация процессов.
- •Реализация процессов в ос unix
- •Понятие процесса в unix.
- •Контекст процесса.
- •Тело процесса.
- •Аппаратный контекст.
- •Системный контекст.
- •Аппарат системных вызов в oc unix.
- •Порождение новых процессов.
- •Порождение сыновнего процесса. Идентификаторы процессов.
- •Порождение сыновнего процесса. Одновременное выполнение.
- •Механизм замены тела процесса.
- •Запуск на выполнение команды ls.
- •Вызов программы компиляции.
- •Использование схемы fork-exec
- •Завершение процесса.
- •Использование системного вызова wait()
- •Использование системного вызова wait()
- •Жизненный цикл процесса в ос unix.
- •Начальная загрузка. Формирование о и 1 процессов.
- •Планирование процессов в ос unix.
- •Планирование процессов.
- •Принципы организация свопинга.
- •Часть III. Реализация взаимодействия процессов.
- •Элементарные средства межпроцессного взаимодействия.
- •Сигналы.
- •Обработка сигнала.
- •Удаление временных файлов при завершении программы.
- •Программа “Будильник”.
- •Двухпроцессный вариант программы “Будильник”.
- •Надежные сигналы.
- •Работа с сигнальной маской.
- •Использование надежных сигналов.
- •Программные каналы
- •Использование канала.
- •Реализация конвейера.
- •Совместное использование сигналов и каналов – «пинг-понг».
- •Именованные каналы (fifo)
- •Модель «клиент-сервер».
- •Нелокальные переходы.
- •Использование нелокальных переходов.
- •Трассировка процессов.
- •Общая схема использования механизма трассировки.
- •Трассировка процессов.
- •Средства межпроцессного взаимодействия System V.
- •Организация доступа и именования в разделяемых ресурсах.
- •Именование разделяемых объектов.
- •Генерация ключей: функция ftok().
- •Общие принципы работы с разделяемыми ресурсами.
- •Очередь сообщений.
- •Доступ к очереди сообщений.
- •Отправка сообщения.
- •Получение сообщения.
- •Управление очередью сообщений.
- •Использование очереди сообщений.
- •Основной процесс.
- •Очередь сообщений. Модель «клиент-сервер»
- •Разделяемая память
- •Создание общей памяти.
- •Доступ к разделяемой памяти.
- •Открепление разделяемой памяти.
- •Управление разделяемой памятью.
- •Общая схема работы с общей памятью в рамках одного процесса.
- •Семафоры.
- •Доступ к семафору
- •Операции над семафором
- •Управление массивом семафоров.
- •Работа с разделяемой памятью с синхронизацией семафорами.
- •1Й процесс:
- •2Й процесс:
- •Взаимодействие процессов в сети.
- •Механизм сокетов.
- •Типы сокетов. Коммуникационный домен.
- •Создание и конфигурирование сокета. Создание сокета.
- •Связывание.
- •Предварительное установление соединения. Сокеты с установлением соединения. Запрос на соединение.
- •Сервер: прослушивание сокета и подтверждение соединения.
- •Прием и передача данных.
- •Завершение работы с сокетом.
- •Резюме: общая схема работы с сокетами.
- •Работа с локальными сокетами.
- •Пример работы с сокетами в рамках сети.
- •Среда параллельного программирования mpi
- •Краткий обзор параллельных архитектур.
- •Системы с распределенной памятью – mpp.
- •Системы с общей памятью – smp.
- •Системы с неоднородным доступом к памяти – numa.
- •Кластерные системы.
- •Модель программирования mpi.
- •Функции общего назначения. Общая структура программы.
- •Коммуникаторы и группы.
- •Обрамляющие функции. Инициализация и завершение.
- •Синхронизация: барьеры.
- •Использование барьерной синхронизации.
- •Прием и передача данных. Общие замечания.
- •Сообщения и их атрибуты.
- •Поддержка типов данных в mpi.
- •Коммуникации «точка-точка». Блокирующий режим.
- •Отправка сообщений в блокирующем режиме.
- •Режимы буферизации.
- •Прием сообщений в блокирующем режиме.
- •Mpi: прием сообщения, размер которого неизвестен заранее.
- •Коммуникации «точка-точка». Неблокирующий режим.
- •Отсылка и прием сообщений в неблокирующем режиме.
- •Работа с квитанциями.
- •Mpi: коммуникации «точка-точка». «Пинг-понг».
- •Коллективные коммуникации.
- •Коллективный обмен данными.
- •Коллективный обмен, совмещенный с обработкой данных.
- •Mpi: применение коллективных коммуникаций.
- •Алфавитный указатель упоминаемых библиотечных функций и системных вызовов.
- •Список литературы
-
Задача «читателей и писателей»
Другой классической задачей синхронизации доступа к ресурсам является задача «читателей и писателей» [2], иллюстрирующая широко распространенную модель совместного доступа к данным. Представьте себе ситуацию, например, в системе резервирования билетов, когда множество конкурирующих процессов хотят читать и обновлять одни и те же данные. Несколько процессов могут читать данные одновременно, но когда один процесс начинает записывать данные (обновлять базу данных проданных билетов), ни один другой процесс не должен иметь доступ к данным, даже для чтения. Возникает вопрос, как спланировать работу такой системы? Одно из решений представлено ниже:
typedef int semaphore; /* тип данных «семафор» */
semaphore mutex = 1; /* контроль за доступом к «rc» (разделямый ресурс) */
semaphore db = 1; /* контроль за доступом к базе данных */
int rc = 0; /* кол-во процессов читающих или пишущих */
void reader (void)
{
while (TRUE) /* бесконечный цикл */
{
down(&mutex); /* получить эксклюзивный доступ к «rc»*/
rc = rc + 1; /* еще одним читателем больше */
if (rc == 1) down(&db); /* если это первый читатель, нужно заблокировать эксклюзивный доступ к базе */
up(&mutex); /*освободить ресурс rc */
read_data_base(); /* доступ к данным */
down(&mutex); /*получить эксклюзивный доступ к «rc»*/
rc = rc - 1: /* теперь одним читателем меньше */
if (rc == 0) up(&db); /*если это был последний читатель, разблокировать эксклюзивный доступ к базе данных */
up(&mutex); /*освободить разделяемый ресурс rc */
use_data_read(); /* некритическая секция */
}
}
void writer (void)
{
while(TRUE) /* бесконечный цикл */
{
think_up_data(); /* некритическая секция */
down(&db); /* получить эксклюзивный доступ к данным*/
write_data_base(); /* записать данные */
up(&db); /* отдать эксклюзивный доступ */
}
}
В этом примере, первый процесс, обратившийся к базе данных по чтению, осуществляет операцию down() над семафором db, тем самым блокируя эксклюзивный доступ к базе, который нужен для записи. Число процессов, осуществляющих чтение в данный момент, определяется переменной rc (обратите внимание! Так как переменная rc является разделяемым ресурсом – ее изменяют все процессы, обращающиеся к базе данных по чтению – то доступ к ней охраняется семафором mutex). Когда читающий процесс заканчивает свою работу, он уменьшает значение rc на единицу. Если он является последним читателем, он также совершает операцию up над семафором db, тем самым разрешая заблокированному писателю, если таковой имелся, получить эксклюзивный доступ к базе для записи.
Надо заметить, что приведенный алгоритм дает преимущество при доступе к базе данных процессам-читателям, так как процесс, ожидающий доступа по записи, будет ждать до тех пор, пока все читающие процессы не окончат работу, и если в это время появляется новый читающий процесс, он тоже беспрепятственно получит доступ. Это может привести к неприятной ситуации в том случае, если в фазе, когда ресурс доступен по чтению, и имеется ожидающий процесс-писатель, будут появляться новые и новые читающие процессы. К примеру, представим себе, что новый читающий процесс появляется каждую секунду и чтение длится в среднем 2 секунды. Количество читающих процессов в этом случае будет приблизительно константным, и процесс-писатель никогда не получит доступ к данным.
Чтобы этого избежать, можно модифицировать алгоритм таким образом, чтобы в случае, если имеется хотя бы один ожидающий процесс-писатель, новые процессы-читатели не получали доступа к ресурсу, а ожидали, когда процесс-писатель обновит данные. В этой ситуации процесс-писатель должен будет ожидать окончания работы с ресурсом только тех читателей, которые получили доступ раньше, чем он его запросил. Однако, обратная сторона данного решения в том, что оно несколько снижает производительность процессов-читателей, так как вынуждает их ждать в тот момент, когда ресурс не занят в эксклюзивном режиме.