Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Операционные системы реального времени и технологии разработки кроссплатформенного программного обеспечения. Ч.1. Учебное пособие
.pdf
4.3. Особенности управления процессами в операционных системах реального…
81
очень важно наличие механизмов, позволяющих гарантировать, что событие с высоким приоритетом будет иметь возможность отработать перед событием с более низким приоритетом. Все это сводится к тому, что ОС РВ
встраивают не только механизмы планирования и механизмы прерывания,
но также и механизмы обслуживания и управления прерываниями.
Более того современные ОС РВ имеют возможность блокировать об-
работку прерываний в тот момент, когда необходимо обрабатывать критическую ситуацию или выполнять критически важный код. Естественно, что
этот код нельзя будет прерывать.
Однако длительность обработки любого прерывания необходимо
сводить к минимуму.
Если поток не относится к типу “реального времени”, то его можно
обработать не в режиме DMS, а в режиме циклического планирования, т.е.
в RMS. Когда выделенный ему квант времени заканчивается, то контекст
процессора сохраняется в особом сегменте памяти, а сам поток ставится в
конец очереди.
В этом жизненном цикле системы существует две основные про-
блемы, которые должен решать планировщик:
1. обеспечение выполнения процессов с наивысшим приоритетом;
2. исключение инверсии приоритетов, когда задача с высоким при-
оритетом ожидает освобождение ресурсов, захваченных задачами с более
низким приоритетом.
Как правило, при разработке операционных систем реального вре-
мени стараются применять наиболее простые и надежные конфигурации,
даже “в ущерб” эффективности и оптимальности распределения ресурсов.
Это логичное решение, если принимать во внимание, что сложные и динамические системы сложно настраивать, тестировать, отлаживать и поэтому
лучше поставить в компьютер более мощный и дорогой процессор, чем
иметь проблемы вследствие непредвиденного поведения системы.
Как показывает практика, большинство реализуемых ныне систем
являются статическими с фиксированными уровнями привилегий или приоритетов. А проблему “статичности” решают путем введения нескольких
режимов работы. Каждый из этих режимов имеет свой набор задач, иногда
несовместимых с другими режимами работы. Для этих задач характерным
является процесс фиксации приоритета при запуске.
4. Управление задачами
82
4.4. Переключение контекста
Ранее мы упоминали процесс переключения контекста задачи, так
что необходимо рассмотреть, что это такое и зачем применяется.
Под контекстом задачи будем понимать некоторое множество дан-
ных, которые определят состояние процессора на момент выполнения задачи. Обычно контекст задачи фиксируется, т.е. сохраняется, при переключении (т.е. при переходе процессора от выполнения одной задачи к другой).
Стандартный контекст задачи в первую очередь определяет состояние регистров процессора. Самыми важными являются регистры, отвечающие
именно за переключение и трансляцию адресов.
Переключение задач может быть инициировано либо планировщи-
ком задач, либо внешним прерыванием, либо возникшим исключением в
работе программы.
Планировщик задач может вызвать переключение, например, в связи
с освобождением ресурса и с попаданием в очередь новой задачи с более
высоким приоритетом, которая ожидает этот ресурс. Прерывание может
вызвать переключение, если пришел запрос на обслуживание от внешнего
устройства или программа напрямую вызвала прерывание. Исключение
может повести себя как прерывание, осуществив системный вызов.
Часто оба термина: переключение задач и переключение контекста
применяют как синонимы.
За переключение контекста отвечает специальная программа или
модуль – диспетчер. Этой программе необходимо выполнить следующие
действия:
корректно остановить выполняющуюся задачу;
найти и подготовить к запуску новую задачу;
запустить новую задачу.
Каждое из этих действий состоит из нескольких фаз. Например,
остановка работающей задачи выполняется как минимум в два шага: выполнение инструкций текущей задачи, которые уже загружены в процессор
и находятся в его конвейере выполнения (стандартная емкость такого конвейера – 10 инструкций), и сохранение в оперативной памяти состояние регистров процессора в особых переменных. Для того чтобы найти и подготовить к запуску новую задачу, диспетчеру требуется найти задачу в памяти, подготовить ее контекст (если она запускалась ранее) или создать
4.4. Переключение контекста
83
контекст (если задача запускается впервые), определить источник задачи
(если это обработчик прерывания, то определить источник прерывания).
Для запуска новой задачи нужно восстановить из оперативной памяти подготовленные ранее регистры новой задачи, загрузить в процессор начальные инструкции новой задачи, запустив тем самым конвейер с новой
“точки”. Часть действия выполняется программно, а часть – аппаратно.
Каждая стадия и каждый шаг работы диспетчера вносит определен-
ную задержку в работу системы. Логично, что диспетчер (равно как и вся
система в целом) должен обеспечить минимизацию задержки на переключение задач. Более того, даже минимальная задержка должна быть детерминирована, т.е. для нее должен быть определен интервал (квант) времени.
Обработчик и другие приложения должны точно знать, сколько времени
потребуется на загрузку и переключение задачи в наихудшем случае (максимальное время).
5. Синхронизация и взаимодействие процессов
84
5. СИНХРОНИЗАЦИЯ И ВЗАИМОДЕЙСТВИЕ
ПРОЦЕССОВ
В данном разделе будут рассмотрены проблемы синхронизации и
взаимодействия процессов, описаны системные механизмы для синхронизации потоков, объекты синхронизации POSIX, а также рассмотрены типовые модели синхронизации.
5.1. Проблемы синхронизации и взаимодействия
процессов между собой
Решение проблем запуска и контроля многих потоков, т.е. проекти-
рование, разработка и внедрение многопоточных программы – это одно из
самых сложных, но востребованных направлений разработки программного обеспечения. Здесь необходимо правильно понимать механику взаимодействия процессов, строить логику одновременного и отложенного запуска процессов, настройку взаимодействия и обмена данными между потоками. Это требует как теоретических, так и практических навыков и высокой квалификации разработчика, так как любая ошибка может рано или
поздно привести к сбою всей системы в целом.
Современные операционные системы реального времени, запускае-
мые в более сложных системах, чем встраиваемые, требуют применения
многопоточности. В этой связи ОС РВ должны поддерживать механизмы
межпроцессорного взаимодействия, которые должны полностью обеспечивать надежность и синхронизацию запущенных задач без взаимоисключений и с минимальными задержками.
В идеальной системе все процессы, которые выполняются одновременно, т.е. параллельно, должны быть независимы друг от друга. Такая независимость процессов называется асинхронностью. На практике средства
асинхронности внедрены практически во все языки системного уровня и
поддерживаются аппаратно.
Рано или поздно возникает ситуация, когда даже асинхронным процессам нужен доступ к разделяемым ресурсам. Для этого в ОС РВ внедряются дополнительные инструменты, предоставляющие такие возможности.
5.1. Проблемы синхронизации и взаимодействия процессов между собой
85
При выполнении параллельных процессов основной проблемой яв-
ляется ситуация, когда один процесс должен обратиться к разделяемым
данным, тем самым блокируя доступ к ним для других элементов системы.
Эта ситуация называется “взаимное исключение” или “мьютекс”
(mutual exclusion).
Ресурс, участвующий в таком обращении и являющийся причиной
мьютекса, называется “критическим ресурсом”. В случае, когда такой ресурс выделяется в системе, для него создаются дополнительные условия
синхронизации для процессов. В любом случае этот ресурс находится в
распоряжении только одного процесса, а все остальные должны ждать.
Элементы процесса, которым нужно обратиться к критическому ресурсу, называются “критическими областями” (рис. 8).
Рис. 8. Критическая область
Рассмотрим пример, где у нас есть два или более процессов, которые
требуют доступа к критическому неразделяемому ресурсу. Пусть в качестве ресурса будет принтер, который в одно и то же время может выполнять
только одно задание печати и имеет достаточно длительное время выполнения задачи (особенно по сравнению со временем выполнения стандартной задачи операционной системы).
Здесь под синхронизацией процессов будем понимать механизм, который может обеспечить невозможность одновременного выполнения сегмента программы с одним ресурсом.
Доступ в критическую секцию можно осуществить только с помощью методов синхронизации. Если синхронизация содержит ошибки или
5. Синхронизация и взаимодействие процессов
86
неточности, то может возникнуть цепочка событий непредсказуемого поведения, т.е. состояние “гонки”.
В состоянии гонки значения переменных или даже последователь-
ность выполнения задач могут меняться непредсказуемым образом.
Кроме указанных выше проблем, необходимо решать и другие за-
дачи в области синхронизации процессов. Например:
установление и контроль порядка совершения действий в си-
стеме;
взаимная блокировка задач и процессов;
удовлетворение “ресурсного голода” системы;
решение проблемы возможной инверсии приоритетов;
управление нагруженным ожиданием и так далее.
Дадим некоторые комментарии указанным выше примерам.
Установление и контроль порядка совершения действий в системе –
это гарантия того, что все действия будут выполнены в правильной, и иногда в заранее установленной последовательности действий. Этот процесс
напоминает классический алгоритм с соответствующими последовательностями блоков, условиями, переходами и циклами.
Взаимная блокировка задач и процессов заключается в возможной
ситуации, когда несколько задач или процессов блокируют выполнение
друг друга. То есть один процесс блокирует выполнение другого процесса,
который блокирует выполнение третьего, который блокирует выполнение
первого и так далее. Достаточно распространенная ситуация в сложных системах с большим количеством казалось бы независимых процессов, программ и аппаратных блоков. Для решения этой проблемы существуют специальные алгоритмы поиска и удаления взаимных блокировок. Однако
также возможна ситуация, когда блокировка найдена, устранена, но через
некоторое время возникла снова и чуть ли не в тот же самый момент жизненного цикла системы. Это называется livelock.
Единственный надежный способ борьбы с взаимными блокировками,
как не странно, это обнаружение их возможного появления на этапе проектирования системы. Если концепция операционной системы не допускает избегания взаимных блокировок, то стараются модифицировать ресурсы и запросы к ним так, чтобы снятие блокировок и перезапуск процессом минимально негативно сказывался на “здоровье” процессов и самой ОС.
5.1. Проблемы синхронизации и взаимодействия процессов между собой
87
“Ресурсный голод” системы – это достаточно интересное понятие,
которое описывает ситуацию, когда некоторый ресурс монопольно (постоянно) занимается другим ресурсом, но нужен еще некоторому количеству
ресурсов. В этом случае часть процессов постоянно получают отказ в необходимых ресурсах, т.е. испытывают некий “голод”. Причиной постоянных отказов в ресурсах, приводящих к “голоду”, так же могут быть: ошибки
в самих ресурсах или в алгоритмах их распределения, “утечка” ресурсов
или их недостаток, погрешности планирования ресурсов, внешние деструктивные воздействия типа вирусных или DDoS-атак. Очень часто причиной
ресурсного “голода” является простота или “костность” алгоритма распределения. Например, если планировщик всегда предоставляет ресурс потоку
с большим приоритетом, то при высокой интенсивности работы, для
остальных, менее приоритетных потоков, ресурс будет редко доступен, и
они будет испытывать “голод”. “Ресурсный голод” несколько напоминает
взаимную блокировку, но в данном случае часть потоков так и не смогут
получить доступ к дефицитному ресурсу.
Возможная инверсия приоритетов возникает тогда, когда менее приоритетное задание может заблокировать ресурсы, которые используются совместно и могут быть необходимы более приоритетной задаче. Такая ситуация ведет к блокировке более приоритетной задачи до тех пор, когда менее
приоритетная задача не освободит данный ресурс. В точке освобождения с
точки зрения ресурса происходит “инверсия” приоритетов. В этот момент
другая задача, приоритет которой, например, находится между приоритетами первой и второй задач, сможет получить доступ к рассматриваемому
ресурсу, так как в момент переключения приоритет не определен.
В современных ОС РВ есть несколько способов решения этой проблемы: отключение всех прерываний, если проблема происходит в критической секции (в этой ситуации исключается сама возможность получения
запроса на ресурс), максимизация приоритетов (когда оба конкурирующих
процесса временно получают максимально возможный в системе уровень
приоритета), наследование приоритетов.
Управление нагруженным ожиданием здесь понимается как способ
организации программы, при котором процесс ожидает ситуации, когда
происходят несколько определенных событий. Ожидающий процесс не
5. Синхронизация и взаимодействие процессов
88
имеет другой возможности “ждать” события, чем прямой опрос или проверка ситуации в цикле. Такой опрос называется поллинг (polling) и состоит из фаз начала, проверки и возврата к началу. При этом он не имеет
никакой полезной работы и выполняется как бы “в холостую”. То есть в
этот момент наблюдается фактический “простой” системы.
Далее рассмотрим средства межпроцессного взаимодействия.
5.2. Средства межпроцессного взаимодействия
Для организации обмена данными между процессами и для передачи
между ними сигналов управления применяются так называемые “средства
межпроцессного взаимодействия”. В оригинальных источниках они носят
совокупное название IPC (InterProcess Communications) и для них выделяются три уровня:
локальное межпроцессное взаимодействие;
высокоуровневое межпроцессное взаимодействие;
удаленное межпроцессное взаимодействие.
Локальное взаимодействие привязано к процессору и возможно
только внутри одного вычислительного устройства, например, компьютера. К этому типу принадлежат практически все известные стандартные
механизмы IPC систем типа UNIX.
Следуя современной терминологии, для них существуют понятия:
каналы;
очереди и шины сообщений;
разделяемая память.
Для локального взаимодействия характерны простые и быстрые программные интерфейсы и шины.
Высокоуровневое взаимодействие подразумевает использование отдельных пакетов прикладного и системного программного обеспечения,
которые работают как промежуточный слой между системой и приложениями. Они переносят опыт и функционал протоколов коммуникаций отдельных приложений на новую архитектуру.
Простые высокоуровневые взаимодействия реализуются при помощи сигналов и каналов. Более сложные средства высокоуровневого взаимодействия носят названия:
5.2. Средства межпроцессного взаимодействия
89
очередей сообщения;
семафоров;
разделяемых областей памяти.
Наряду с организацией взаимодействия процессов на высоком
уровне программные компоненты должны решать и проблему параллельных вычислений, как подвида высокоуровневого взаимодействия.
К инструментам организации параллельных вычислений относятся:
синхронный доступ;
дисциплина доступа;
голодание процессов;
управление потоком;
тупики.
Под синхронным доступом будем понимать ситуацию, когда все
процессы совершают с ресурсом одну и ту же операцию (например, чтение). Если один из процессов пытается совершить операцию другого типа,
изменяющую данные, то возникает проблема, конфликт.
Под дисциплиной доступа будем понимать ситуацию, когда, в зависимости от требований к функционалу системы, организуют дополнительные механизмы последовательного выполнения с определенным порядком.
Примером может быть обычная очередь для организации доступа к файлу
или к базе данных, когда сначала один процесс получает доступ на запись,
а в следующий момент несколько процессов получают доступ на чтение.
Потом все повторяется, но никак иначе. При этом формируются так называемые “барьеры” операций, пересечь которые невозможно.
Под голоданием процессов будем понимать ситуацию дисциплины
доступа, когда один процесс монополизировал запись в файл и его освобождения ждут много других процессов. При этом обычно проблема решается организацией очередей с приоритетами на чтение и запись данных.
Под управлением потоками будем понимать ситуацию, когда невозможно точно определить, какой процесс фактически являлся первым в последовательности запросов на чтение данных или возврат данных. Обычно
такая ситуация возникает при организации клиент-серверного взаимодействия. Здесь запрос от процесса Х, посланный ранее запроса от процесса Y,
может прийти на источник данных позже запроса от Y в силу особенностей
5. Синхронизация и взаимодействие процессов
90
сетевого общения, занятости среды передачи или, например, неполадок
сети. Естественно, что в клиент-серверной системе один сервер и множество клиентов. Одновременно сервер может обслуживать десятки тысяч
или даже миллионы соединений. Каждый клиент посылает запрос в соответствии со своим алгоритмом, а сервер выдает на него ответ. Клиент дожидается ответа от сервера, чтобы продолжить дальше решение своей задачи. Такое поведение в плане организации фаз запрос-ожидание-ответ и
называется управление потоком. Здесь могут использоваться очереди сообщений с различными приоритетами.
Под тупиком будем понимать ситуацию, когда процесс Х получает
доступ к ресурсу Х и ждет освобождения ресурса Y. В то же самое время,
процесс Y, получив доступ к ресурсу Y, ждет освобождения ресурса Х.
В этот момент они оба будут находиться в тупике, так как они оба ждут
освобождения ресурсов друг друга, но не освобождают в то же самое время
свои собственные ресурсы. Тупика можно избежать, если все ресурсы в системе будут иметь свои собственные уникальные номера и будут предоставляться только в порядке следования номеров, организованном по возрастанию. Кроме того, любой ресурс должен освобождаться в принудительном порядке сразу после окончания использования.
Удаленное взаимодействие реализуется механизмами, которые
обеспечивают коммуникацию как в пределах одной вычислительной системы (в этом они повторяют инструменты локального взаимодействия,
только с дополнительными возможностями), так и между разными вычислительными системами (например, посредством локальной сети или сети
Интернет). К таким инструментам относятся:
удаленные вызовы процедур RPC (Remote Procedure Call);
сокетные соединения;
транспортные интерфейсы TLI (Transport Layer Interface).
Далее рассмотрим механизмы синхронизации потоков.
5.3. Современные механизмы синхронизации потоков
Механизмы синхронизации служат для того, чтобы программы, использующие несколько потоков или процессов, выполняли свои функции
без сбоев и в нужной последовательности.
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]