← Предыдущая

Версия 00:03, 21 октября 2018

Строка 33:

В этом примере мы показали проблему, известную как состязание (гонка) за ресурсы. Другая известная проблема, связанная с одновременным изменением данных – повреждение данных. Обычно данные повреждаются, когда несколько задач одновременно обновляют сложные структуры данных, доступ к которым не атомарен на уровне процессора. Например, на платформе x86 такой структурой данных будут 64-битные целые числа. После такого обновления в подобной структуре могут содержаться данные всех процессов, производивших обновление, и, соответственно, сама структура содержит данные, которые в ней не появились бы, если бы все процессы обновляли ее последовательно. Возникает вполне логичный вопрос: что надо делать, чтобы подобных ситуаций не возникало? Ответ вполне очевиден: если несколько процессов одновременно обращаются к некоторым данным, причем некоторые из этих процессов изменяют общие данные, то для доступа к этим данным необходимо использовать средства синхронизации.

+

{{Врезка|right|Заголовок= Реентерабельность блокировок|Ширина=50%|Содержание= Реентерабельность – это возможность повторного использования какого-либо объекта или вызова функции в момент, когда данный объект используется или функция вызвана. В случае объектов блокировки это означает, может ли одна и та же сторона «захватить» объект блокировки несколько раз. Если да, то такой объект блокировки является реентерабельным (при этом, если мы N раз «захватили» объект блокировки, его необходимо «освободить» также N раз); если же нет – нереентерабельным (при попытках «захватить» такой объект блокировки несколько раз мы в итоге получим самоблокировку). Блокировки, поддерживаемые модулем global, являются реентерабельными. }}

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

Строка 49:

Строка 50:

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

−

+

{{Врезка|left|Заголовок= Блокировки на перекрывающихся подмножествах узлов|Ширина=60%|Содержание=

+

Функции global:set_lock/1,2,3 и global:del_lock/1,2 позволяют «захватывать» и «освобождать» блокировки, заданные идентификатором на множестве узлов, определяемых пользователем. Идентификатор блокировки – это пара, состоящая из идентификатора ресурса и идентификатора стороны, запрашивающей блокировку (в качестве идентификаторов могут выступать любые объекты языка Erlang). Может встать вопрос: а что будет, если попытаться захватить один и тот же ресурс двумя разными сторонами на двух разных, но перекрывающихся подмножествах узлов? Например, мы делаем вызов global:set_lock({res_id, side_id1}, [‘n1@stdstring’, ‘n2@stdstring’], 0), который возвращает true. Что в таком случае вернет вызов global:set_lock({res_id, side_id2}, [‘n2@stdstring’, ‘n3@stdstring’], 0)? Если бы мы запрашивали блокировку {res_id, side_id2} только на узле n3@stdstring, мы, очевидно, ее «захватили» бы (и вызов вернул бы true). Однако мы запросили блокировку на узлах ‘n2@stdstring’ и ‘n3@stdstring’; а значит, блокировки только на узле ‘n3@stdstring’ нам не достаточно. Блокировку {res_id, side_id2} на узле ‘n2@stdstring’ «захватить» нельзя (она «захвачена» другой стороной). Соответственно, нельзя захватить эту блокировку и на узлах ‘n2@stdstring’ и ‘n3@stdstring’. Тогда второй вызов global:set_lock/3 вернет false.}}

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

Строка 119:

Строка 121:

Вполне возможна ситуация, что два разных процесса пытаются «захватить» блокировку на какой-то ресурс, используя один и тот же идентификатор запрашивающей стороны. В этом случае (естественно, если блокировка свободна) они оба ее «захватят»; однако и освобождать эту блокировку необходимо им обоим. Область действия этих блокировок – все известные узлы; однако область действия блокировки можно изменить, задав список узлов, для которых данная блокировка будет действительна. Если процесс, владеющей блокировкой, завершится без ее освобождения или же узел, на котором выполняется такой процесс, завершит свою работу, то блокировка автоматически освободится (если, конечно, ею никто больше не владеет).

−

+

−

После этого небольшого обзора взглянем на наших героев. Для «захвата» блокировки у нас есть следующие три функции: global:set_lock(Id), global:set_lock(Id, Nodes) и global:set_lock(Id, Nodes, Retries). Функция global:set_lock/3 пытается установить блокировку с идентификатором Id, область действия которой распространяется на узлы Nodes, с количеством попыток установить блокировку Retries. В качестве значения для числа попыток установить блокировку можно передать любое неотрицательное число или атом infinity. Функция global:set_lock/3 будет пытаться «захватить» блокировку не более Retries раз, впадая на некоторое время в сон в случае неудачной попытки (если значением Retries является атом infinity, то функция global:set_lock/3 будет выполняться, пока не «захватит» блокировку). Эта функция вернет атом true, если блокировка была «захвачена», и false – в противном случае. Функция global:set_lock/2 эквивалентна функции global:set_lock/3 со значением Retries, равным атому infinity. Функция global:set_lock/1 эквивалентна функции global:set_lock/2, только блокировка определяется на всех узлах. Для освобождения блокировки служат следующие две функции: global:del_lock(Id) и global:del_lock(Id, Nodes). Функция global:del_lock/2 позволяет освободить блокировку, заданную идентификатором Id, на узлах Nodes, а функция global:del_lock/1 делает то же самое на всех узлах.

+

После этого небольшого обзора взглянем на наших героев. Для «захвата» блокировки у нас есть следующие три функции: global:set_lock(Id), global:set_lock(Id, Nodes) и global:set_lock(Id, Nodes, Retries). Функция global:set_lock/3 пытается установить блокировку с идентификатором Id, область действия которой распространяется на узлы Nodes, с количеством попыток установить блокировку Retries. В качестве значения для числа попыток установить блокировку можно передать любое неотрицательное число или атом infinity. Функция global:set_lock/3 будет пытаться «захватить» блокировку не более Retries раз, впадая на некоторое время в сон в случае неудачной попытки {{Врезка|right|Заголовок= Блокировки: Упрощенный сценарий|Ширина=60%|Содержание=Обычно работа с блокировками ресурсов выглядит так: мы «захватываем» блокировку, выполняем некую функцию (или последовательность действий, сводимую в некую функцию), после чего «освобождаем» блокировку. Конечно, мы можем не смочь «захватить» блокировку: тогда дальнейших действий не предвидится. Чтобы упростить этот сценарий, в модуле global определены функции global:trans/2,3,4. Функция global:trans(Id, Fun, Nodes, Retries) пытается захватить блокировку с идентификатором Id на узлах Nodes Retries раз. Если «захват» осуществлен, выполняется функция Fun, блокировка «освобождается» и возвращается результат выполнения функции Fun. Если «захватить» блокировку не удалось, возвращается атом aborted. }}(если значением Retries является атом infinity, то функция global:set_lock/3 будет выполняться, пока не «захватит» блокировку). Эта функция вернет атом true, если блокировка была «захвачена», и false – в противном случае. Функция global:set_lock/2 эквивалентна функции global:set_lock/3 со значением Retries, равным атому infinity. Функция global:set_lock/1 эквивалентна функции global:set_lock/2, только блокировка определяется на всех узлах. Для освобождения блокировки служат следующие две функции: global:del_lock(Id) и global:del_lock(Id, Nodes). Функция global:del_lock/2 позволяет освободить блокировку, заданную идентификатором Id, на узлах Nodes, а функция global:del_lock/1 делает то же самое на всех узлах.

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

LXF163:Erlang: Программируем синхронизацию - История изменений

Olkol: /* Erlang: Программируем синхронизацию */

Olkol: Новая страница: «Категория: Учебники Категория: Программирование Категория: Синхронизация '''Erl…»

@@ Строка 33: / Строка 33: @@
 В этом примере мы показали проблему, известную как состязание (гонка) за ресурсы. Другая известная проблема, связанная с одновременным изменением данных – повреждение данных. Обычно данные повреждаются, когда несколько задач одновременно обновляют сложные структуры данных, доступ к которым не атомарен на уровне процессора. Например, на платформе x86 такой структурой данных будут 64-битные целые числа. После такого обновления в подобной структуре могут содержаться данные всех процессов, производивших обновление, и, соответственно, сама структура содержит данные, которые в ней не появились бы, если бы все процессы обновляли ее последовательно. Возникает вполне логичный вопрос: что надо делать, чтобы подобных ситуаций не возникало? Ответ вполне очевиден: если несколько процессов одновременно обращаются к некоторым данным, причем некоторые из этих процессов изменяют общие данные, то для доступа к этим данным необходимо использовать средства синхронизации.
 Следует сказать, что на многоядерных и многопроцессорных машинах возможна гонка за ресурсы, связанная с тем, что разные ядра (или процессоры) в своей кэш-памяти содержат разные значения одной и той же переменной. Это справедливо, даже если доступ к такой переменной атомарен на уровне процессора, как, например, для 32-битных целых чисел на платформе x86. Следует учитывать подобные ситуации и применять соответствующие средства синхронизации, чтобы избежать их.
@@ Строка 49: / Строка 50: @@
 Со средствами синхронизации с блокировками связана также такая большая проблема, как взаимные блокировки задач. В простейшем случае взаимные блокировки задач получаются следующим образом. Пусть у нас есть два ресурса – A и B, доступ к которым защищается при помощи средств синхронизации с блокировками. Предположим, что у нас есть две задачи, которые хотят безопасно работать как с ресурсом A, так и с ресурсом B, при этом первая задача сначала пытается «захватить» блокировку, связанную с ресурсом A, а потом с ресурсом B, а вторая задача – наоборот. При одновременном выполнении этих задач возможна такая ситуация, когда первая задача «захватила» блокировку, связанную с ресурсом A, и ожидает блокировку, связанную с ресурсом B, тогда как вторая задача «захватила» блокировку, связанную с ресурсом B, и ожидает блокировку, связанную с ресурсом A. Такое ожидание будет вечным. Как мы говорили выше, средства синхронизации – это средства взаимодействия между процессами, и если разные задачи «захватывают» одни и те же блокировки в разном порядке, это означает, что какие-то из задач нарушают протокол взаимодействия между задачами.
+{{Врезка|left|Заголовок= Блокировки на перекрывающихся подмножествах узлов|Ширина=60%|Содержание=
 Что касается средств неблокирующей синхронизации, то помимо сильного усложнения разрабатываемых приложений, далеко не все может быть реализовано только с их помощью. Так, например, двусвязный список не имеет реализации с использованием средств неблокирующей синхронизации. При использовании средств неблокирующей синхронизации ситуации взаимной блокировки задач возникнуть не может. Но вполне могут возникнуть ситуации зацикливания задачи и гонки за ресурсы.
@@ Строка 119: / Строка 121: @@
 Вполне возможна ситуация, что два разных процесса пытаются «захватить» блокировку на какой-то ресурс, используя один и тот же идентификатор запрашивающей стороны. В этом случае (естественно, если блокировка свободна) они оба ее «захватят»; однако и освобождать эту блокировку необходимо им обоим. Область действия этих блокировок – все известные узлы; однако область действия блокировки можно изменить, задав список узлов, для которых данная блокировка будет действительна. Если процесс, владеющей блокировкой, завершится без ее освобождения или же узел, на котором выполняется такой процесс, завершит свою работу, то блокировка автоматически освободится (если, конечно, ею никто больше не владеет).
-−
-После этого небольшого обзора взглянем на наших героев. Для «захвата» блокировки у нас есть следующие три функции: global:set_lock(Id), global:set_lock(Id, Nodes) и global:set_lock(Id, Nodes, Retries). Функция global:set_lock/3 пытается установить блокировку с идентификатором Id, область действия которой распространяется на узлы Nodes, с количеством попыток установить блокировку Retries. В качестве значения для числа попыток установить блокировку можно передать любое неотрицательное число или атом infinity. Функция global:set_lock/3 будет пытаться «захватить» блокировку не более Retries раз, впадая на некоторое время в сон в случае неудачной попытки (если значением Retries является атом infinity, то функция global:set_lock/3 будет выполняться, пока не «захватит» блокировку). Эта функция вернет атом true, если блокировка была «захвачена», и false – в противном случае. Функция global:set_lock/2 эквивалентна функции global:set_lock/3 со значением Retries, равным атому infinity. Функция global:set_lock/1 эквивалентна функции global:set_lock/2, только блокировка определяется на всех узлах. Для освобождения блокировки служат следующие две функции: global:del_lock(Id) и global:del_lock(Id, Nodes). Функция global:del_lock/2 позволяет освободить блокировку, заданную идентификатором Id, на узлах Nodes, а функция global:del_lock/1 делает то же самое на всех узлах.
+После этого небольшого обзора взглянем на наших героев. Для «захвата» блокировки у нас есть следующие три функции: global:set_lock(Id), global:set_lock(Id, Nodes) и global:set_lock(Id, Nodes, Retries). Функция global:set_lock/3 пытается установить блокировку с идентификатором Id, область действия которой распространяется на узлы Nodes, с количеством попыток установить блокировку Retries. В качестве значения для числа попыток установить блокировку можно передать любое неотрицательное число или атом infinity. Функция global:set_lock/3 будет пытаться «захватить» блокировку не более Retries раз, впадая на некоторое время в сон в случае неудачной попытки {{Врезка|right|Заголовок= Блокировки: Упрощенный сценарий|Ширина=60%|Содержание=Обычно работа с блокировками ресурсов выглядит так: мы «захватываем» блокировку, выполняем некую функцию (или последовательность действий, сводимую в некую функцию), после чего «освобождаем» блокировку. Конечно, мы можем не смочь «захватить» блокировку: тогда дальнейших действий не предвидится. Чтобы упростить этот сценарий, в модуле global определены функции global:trans/2,3,4. Функция global:trans(Id, Fun, Nodes, Retries) пытается захватить блокировку с идентификатором Id на узлах Nodes Retries раз. Если «захват» осуществлен, выполняется функция Fun, блокировка «освобождается» и возвращается результат выполнения функции Fun. Если «захватить» блокировку не удалось, возвращается атом aborted. }}(если значением Retries является атом infinity, то функция global:set_lock/3 будет выполняться, пока не «захватит» блокировку). Эта функция вернет атом true, если блокировка была «захвачена», и false – в противном случае. Функция global:set_lock/2 эквивалентна функции global:set_lock/3 со значением Retries, равным атому infinity. Функция global:set_lock/1 эквивалентна функции global:set_lock/2, только блокировка определяется на всех узлах. Для освобождения блокировки служат следующие две функции: global:del_lock(Id) и global:del_lock(Id, Nodes). Функция global:del_lock/2 позволяет освободить блокировку, заданную идентификатором Id, на узлах Nodes, а функция global:del_lock/1 делает то же самое на всех узлах.
 Сегодня мы познакомились поближе с таким явлением, как синхронизация задач (и с ее реализацией в языке Erlang). Мы увидели, что ничего страшного в синхронизации нет: достаточно быть аккуратным и соблюдать принятые протоколы взаимодействия между задачами. А в следующем номере мы начнем практикум, посвященный созданию многозадачных приложений. |