Отношения между взаимосвязанными процессами

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

Выделяют основные отношения:

· предшествования – процесс A должен переходить в активное состояние раньше процесса B;

· приоритетности – процесс, имеющий приоритет P₁, может быть переведен в активное состояние при соблюдении двух условий:

Ø в состоянии готовности к рассматриваемому процессору нет процессов с приоритетом P₂>P₁;

Ø процессор либо свободен, либо используется процессом с приоритетом P₃<P₁;

· взаимного исключения – два процесса используют обобщенный ресурс (например, память). Так образуется критическая область (КО) – часть ИСП, отражающая действия над этим обобщенным ресурсом в составе одного процесса. КО одного процесса не должна выполняться одновременно с КО над этим же ресурсом в составе другого процесса.

Формулировку конкретных синхронизирующих правил могут осложнять 3 фактора:

· динамика развития взаимосвязанных процессов (неопределенность и непредсказуемость порядка и частоты переходов процессов в различные состояния по мере их развития). Все зависит от конкретных ситуаций и условий;

· для каждой «связки» процессов (в простейшем случае – пары) возникает своя задача синхронизации;

· разных «связок» процессов может быть много.

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

Поток

Процесс может требовать для своего выполнения одной или нескольких более мелких работ – потоков. Рассмотрим принципиальные отличия потока от процесса [1-6].

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

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

Потоки возникли в ОС именно как средство распараллеливания вычислений. Конечно, задачу распараллеливания вычислений можно решать и следующими двумя традиционными способами [2].

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

2. Программист создает для одного приложения несколько процессов, по одному для каждой из параллельных работ. Но при использовании стандартных средств ОС нельзя учесть тот факт, эти процессы тесно взаимосвязаны (решают единую задачу, работают на одном поле данных, должны иметь равные права на ресурсы ВС). А ОС будет рассматривать эти процессы наравне с другими и с помощью универсальных механизмов обеспечивать их изоляцию друг от друга. В данном случае эти полезные механизмы ОС будут выполнять вредную для приложения работу, затрудняющую обмен данными между параллельными частями приложения. Кроме того, на создание каждого процесса ОС тратит определенные системные ресурсы, которые в данном случае неоправданно дублируются – каждому процессу выделяется собственное адресное пространство, ОП, закрепляются УВВ и т.п.

Таким образом, в ОС наряду с процессами нужен механизм распараллеливания вычислений, учитывающий тесные связи отдельных ветвей приложения. Для этих целей современные ОС предлагают механизм многопоточной обработки [1-6, 8-11, 14]. Понятию «поток» соответствует последовательный переход процессора от одной команды программы к другой. ОС распределяет процессорное время между потоками. ОС назначает процессу адресное пространство и набор ресурсов, которые совместно используются всеми его потоками.

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

Итак, мультипрограммирование более эффективно на уровне потоков, а не процессов [1-10]. Каждый поток имеет собственный счетчик команд и стек. Задача, оформленная в виде нескольких потоков в рамках одного процесса, может быть выполнена быстрее за счет псевдопараллельного (или параллельного в мультипроцессорной ВС) выполнения отдельных ее частей.

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

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