9. Взаимодействующие процессы

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

Классический пример для иллюстрации этого упрощения это преобразование записей Конвея. Проблема состоит в том, чтобы читать 80 символьные записи и записывать ту же информацию в 125 символьные записи.

После каждой входной записи должен вставляться дополнительный пробел, и каждая пара звездочек («**») должна заменяться на восклицательный знак («!»).

Каждая выходная запись должна завершаться символом конца записи (EOR).

Преобразование может быть проведено одной программой, но написание этой программы очень сложно.

Все функции, т.е. замена «**» на «!», вставка пробелов, и вставка символов EOR, должны осуществляться за один цикл.

Программу лучше структурировать как два взаимодействующих процесса.

Первый процесс, скажем р₁, читает входные карты и конвертирует входной поток в поток печатных символов, не разбивая на записи.

Второй процесс, скажем р2, получает поток символов и вставляет EOR после 125 символов.

Структура программы как набор двух процессов обычно предполагается для:

• операционных систем,

• телефонных переключающих центров

• коммуникационных программ в компьютерных сетях.

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

Конечно, в этом случае достигнуть физической распределенности легче именно для систем, которые логически распределены.

Операционная система компьютерной системы должна:

1) управлять конкурентным выполнением процессов 2) обеспечить средства коммуникации и синхронизации между процессами.

Процессы, которые выполняются на одном компьютере, имеют доступ к одной физической памяти, отсюда – естественно использование этой памяти для коммуникации. Один процесс пишет в определенное место памяти, и другой процесс читает из этого места.

Проблемы, которые встречаются рассматривались в модели конкурирующих процессов, включают следующие:

1. Атомичность операций с памятью.

Часто предполагается, что чтение и запись одного слова памяти атомичны, т.е. чтение и запись выполняемые процессом завершается перед тем как другая операция чтения или записи начнется.

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

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

Применение взаимного исключения с использованием разделяемых переменных усложнено из-за возможности нескольких процессов искать поле в этой структуре в это же время.

Условия ожидания, налагаемые доступом со взаимным исключением к разделяемым данным, могут понизить производительность процессов, например, если «быстрый» процесс должен ждать данные, в настоящее время используемые «медленным» процессом.

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

2. Проблема производитель-потребитель.

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

Проблема производитель-потребитель возникает, когда решение проблемы преобразования Конвея выработано: процесс р₁ производит промежуточный поток символов, и процесс р₂ потребляет его.

3. Сборка мусора.

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

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

Требуется сложное взаимодействие между приложением и сборщиком, т.к. приложение может модифицировать структуры указателей в памяти, в то время как сборщик решает какие ячейки являются недоступными.

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

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

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

Поэтому, операционные системы и языки программирования предлагают следующие примитивы для более структурной организации межпроцессовых коммуникаций:

1. Семафоры.

Семафор это неотрицательная переменная, чье значение может быть прочитано и записано за одну атомичную операцию.

V операция приращает значение этой переменной, а Р операция уменьшает ее значение, когда оно положительно ( и подвешивает выполнение процесса на этой операции, пока значение переменной нулевое).

Семафоры – подходящее средство для применения взаимного исключения над разделяемой структурой данных: семафор инициализируется в 1, и доступ к структуре предваряется операцией Р и завершается операцией V.

Семафоры накладывают большую ответственность на каждый процесс за правильное использование. Целостность разделяемых данных нарушается, если процесс манипулирует данными неправильно или не выполняет требуемых Р и V операций.

2. Мониторы.

Монитор состоит из структуры данных и набора процедур, которые могут выполняться над этими данными, с помощью их вызова процессами способом, использующим взаимное исключение.

Т.к. к данным доступ осуществляется полностью через процедуры, объявленные в мониторе, то гарантируется правильное использование данных, если монитор объявлен корректно. Монитор, таким образом, предотвращает не позволенный доступ к данным и синхронизирует доступ различных процессов.

3. Каналы.

Канал это механизм, который передает поток данных от одного процесса к другому и синхронизирует два коммутирующих процесса.

Это заранее запрограммированное решение проблемы производитель-потребитель.

Канал это основной механизм коммуникаций в операционной системе UNIX. Если программа р₁ выполняет процесс р₁ преобразования Конвея и р₂ выполняет р₂ , команда UNIX р₁ | р₂ вызывает две программы и соединяет их каналом. Вывод р₁ буферизируется и становится вводом р₂

р₁ подвешивается, когда буфер полон, и р₂ подвешивается, когда буфер пуст.

4. Передача сообщений.

Некоторые языки программирования, такие как OCCAM и ADA, обеспечивают передачу сообщений, как механизм для межпроцессовой коммуникации.

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

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