Разделяемые ресурсы и синхронизация доступа к ним

Одной[R14] из принципиальных заморочек, которые появились в современных операционных системах, является неувязка взаимодействия процессов.

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

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

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

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

Разглядим пример (Рис. 83). Пусть имеется некая общая переменная (разделяемый ресурс) in и два процесса, которые работают с этой переменной Разделяемые ресурсы и синхронизация доступа к ним. Пусть в некий момент времени процесс A присвоил переменной in значение X. Потом в некий момент процесс B ввел значение Y этой же переменной in. Дальше оба процесса читают эту переменную, и в обоих случаях процессы прочитают значение Y. Может быть, что процессы могли совершить эти деяния в ином Разделяемые ресурсы и синхронизация доступа к ним порядке (так как по-другому были бы обработаны на микропроцессоре), и итог был бы хорошим от этого. Соответственно, схожая ситуация, когда процессы соперничают за разделяемый ресурс, именуются гонкой процессов (race conditions).

Рис. 83. Гонка процессов.

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

Блокировка — это ситуация, когда доступ к разделяемому Разделяемые ресурсы и синхронизация доступа к ним ресурсу 1-го из взаимодействующих процессов не обеспечивается за счет активности более приоритетных процессов. Отметим последующее. Разглядим некую модель доступа к разделяемому ресурсу, построенную на ценностях, когда более приоритетный запрос на воззвание к ресурсу будет обработан резвее, чем наименее приоритетный. И пусть в этой модели работают два процесса, у которого ценности доступа Разделяемые ресурсы и синхронизация доступа к ним к разделяемому ресурсу различные. Тогда, если более приоритетный процесс будет «часто» выдавать запросы на воззвание к ресурсу, может появиться ситуация, когда 2-ой процесс будет «вечно» (либо довольно длительно) ждать обработки каждого собственного запроса, т.е. этот наименее приоритетный процесс будет блокирован.

Тупик, либо deadlock, — это ситуация «клинчевая», когда из-за неправильной Разделяемые ресурсы и синхронизация доступа к ним организации доступа к разделяемым ресурсам происходит взаимоблокировка. Разглядим пример тупиковой ситуации(Рис. 84).

Рис. 84. Пример тупиковой ситуации (deadlock).

Представим, что есть два процесса A и B, также пара критичных ресурсов. Пускай в некий момент времени процесс A вошел в критичную секцию работы с ресурсом 1. Это значит, что доступ хоть какого Разделяемые ресурсы и синхронизация доступа к ним другого процесса к данному ресурсу будет блокирован. Пусть также в это время процесс B войдет в критичную секцию ресурса 2. И этот ресурс также будет блокирован для доступа другим процессам. Пускай процесс A, не выходя из критичной секции ресурса 1, пробует захватить ресурс 2. Но последний уже захвачен процессом B Разделяемые ресурсы и синхронизация доступа к ним, и процесс A блокируется. Аналогично, пускай процесс B, не освобождая ресурс 2, пробует захватить ресурс 1 и также блокируется. Это пример простого тупика. Из него процессы никогда не сумеют выйти. Соответственно, решением в этом случае может быть перезапуск системы либо ликвидирование обоих либо 1-го из процессов.


razdelivayas-s-pregradami.html
razdelka-govyazhih-polutush-i-chetvertin.html
razdelka-tush-baranini-kozlyatini-telyatini.html