RU2673019C1 - Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе - Google Patents

Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе Download PDF

Info

Publication number
RU2673019C1
RU2673019C1 RU2017143803A RU2017143803A RU2673019C1 RU 2673019 C1 RU2673019 C1 RU 2673019C1 RU 2017143803 A RU2017143803 A RU 2017143803A RU 2017143803 A RU2017143803 A RU 2017143803A RU 2673019 C1 RU2673019 C1 RU 2673019C1
Authority
RU
Russia
Prior art keywords
access
shared resource
processes
list
request
Prior art date
Application number
RU2017143803A
Other languages
English (en)
Inventor
Евгений Сергеевич Шишкин
Original Assignee
Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы"
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы" filed Critical Открытое Акционерное Общество "Информационные Технологии И Коммуникационные Системы"
Priority to RU2017143803A priority Critical patent/RU2673019C1/ru
Application granted granted Critical
Publication of RU2673019C1 publication Critical patent/RU2673019C1/ru

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00Arrangements for program control, e.g. control units
    • G06F9/06Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46Multiprogramming arrangements
    • G06F9/52Program synchronisation; Mutual exclusion, e.g. by means of semaphores

Abstract

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

Description

Область техники, к которой относится изобретение
Предполагаемое изобретение относится к распределенным вычислительным системам и может быть использовано для обеспечения эксклюзивного доступа к разделяемым ресурсам в распределенных вычислительных системах.
Уровень техники
В настоящее время существует большое количество алгоритмов, обеспечивающих эксклюзивный доступ к разделяемому ресурсу в распределенной системе. Классификация, предложенная в [1], разделяет такие алгоритмы на три класса: на основе обладания токеном, на основе явного запроса разрешения у участников и гибридные алгоритмы.
Методы на основе обладания токеном подразумевают, что в системе, имеющей несколько узлов, существует виртуальный объект под названием токен, обладание которым дает право узлу на получение доступа к общему ресурсу. Так как токен существует в единственном числе, то обладание им гарантирует эксклюзивность такого доступа [2, 3, 4].
Методы на основе запроса разрешения у участников подразумевает, что процесс-претендент за обладание ресурсом явно рассылает запрос на доступ к ресурсу другим претендентам. Получив такое разрешение, процесс получает право на ресурс [5, 6, 7].
К гибридным алгоритмам относятся, в частности, централизованные алгоритмы, которые предполагают, что выдачей разрешений на запросы претендентов на ресурс занимается какой-то специально отведенный центральный координатор [8].
Существует ряд характеристик, по которым алгоритмы сравнивают между собой, такие как количество отправляемых сообщений, необходимое для корректной работы алгоритма, способность алгоритма учитывать отказы отдельных процессов, ограничения, накладываемые на сетевую топологию и т.д. [1].
Особый интерес с практической точки зрения представляют алгоритмы, способные учитывать отказы отдельных процессов и адаптироваться к увеличению числа процессов-участников.
Известен способ обеспечения доступа к разделяемому ресурсу в распределенной системе (называемый также алгоритмом Рикарта-Агравала, [7]), причем система содержит
• по крайней мере, два узла, соединенных между собой посредством цифровой сети передачи данных,
• разделяемый ресурс
• прикладное программное обеспечение (ППО), используемое на каждом узле и формирующее, по крайней мере, один программный процесс (клиент), в ходе работы которого может потребоваться доступ к разделяемому ресурсу, выполненное с возможностью
Figure 00000001
формировать запрос на получение доступа к СБ,
Figure 00000001
останавливать действия до получения ответа от СБ;
• средство блокирования (СБ) доступа к разделяемому ресурсу, расположенное на каждом узле, выполненное с возможностью
Figure 00000001
разрешать или блокировать доступ к разделяемому ресурсу,
Figure 00000001
формировать и посылать сообщения клиенту и другим СБ;
• средство формирования уникальных для всей распределенной системы идентификаторов процессов.
В такой системе, в ходе одновременной работы множества процессов, работающих над одной прикладной задачей, иногда возникает необходимость обеспечить эксклюзивный доступ одного из процессов к разделяемому ресурсу.
Процессы не имеют общей памяти и взаимодействуют между собой только посредством обмена сообщениями. Предполагается, что у любого процесса есть возможность отправить сообщение любому другому процессу, причем сообщение, будучи доставлено до процесса, попадает в его локальный блок хранения (почтовый ящик). Доставка сообщений предполагается надежной, то есть если процесс отправил сообщение, оно обязательно будет доставлено в почтовый ящик получателя без искажений содержимого сообщения.
У каждого процесса есть свой уникальный идентификатор, при этом не происходят отказы процессов, каждый процесс имеет сведения об идентфикаторах всех других процессов-участников, и этот список не меняется.
Процесс, которому необходимо получить доступ к ресурсу, рассылает сообщение всем остальным процессам. При получении сообщения, процесс-получатель может либо сразу дать разрешение, либо отложить запрос в специальный список - список отложенных запросов.
Процесс отвечает на запрос без промедлений в том случае, если, либо он не претендует на доступ и не осуществляет сам доступ к ресурсу в момент получения запроса, либо приоритет у процесса, приславшего запрос, выше, чем его собственный.
Приоритет процесса определяется парой значений: значением идентификатора процесса и значением специального счетчика, который в дальнейшем называется логическими часами процесса. Процесс, у которого значение логических часов меньше, либо, в случае если значения часов совпадают, но значение идентификатора меньше, тот обладает более высоким приоритетом.
Для того, чтобы процесс-получатель имел возможность сравнить свой приоритет с приоритетом процесса-отправителя, значение логических часов передается вместе с сообщением.
Если получатель сообщения сам является претендентом на доступ к ресурсу, и его приоритет выше, чем приоритет отправителя, то в этом случае запрос перекладывается в список отложенных запросов.
Процесс получает доступ к ресурсу только после того, как всем остальным процессам был отправлен запрос на получение доступа и от всех из них получено разрешение.
Успешно получив доступ, выполнив все необходимые действия с ресурсом и затем освободив ресурс, процесс ответит на все такие отложенные запросы, давая возможность доступа к ресурсу другим процессам.
Известный способ принимается за прототип.
Однако, известный способ имеет ряд недостатков.
Так, в случае временного или полного прекращения обмена сообщениями с одним или несколькими другими процессами (например, из-за аппаратного сбоя или физического уничтожения одного или нескольких узлов), остальные процессы будут заблокированы и останутся в неопределенно долгом ожидании, что снижает надежность способа.
Кроме того, известный способ в ходе реализации не предусматривает добавление в состав системы новых процессов или удаление имеющихся процессов, что ограничивает применение способа в реальных системах.
Раскрытие изобретения
Техническим результатом является
1) повышение надежности доступа к разделяемому ресурсу,
2) возможность учета динамического изменения состава участвующих процессов-претендентов на доступ к разделяемому ресурсу.
Для этого предлагается способ обеспечения эксклюзивного доступа к разделяемому ресурсу в распределенной вычислительной системе, причем система содержит
• по крайней мере, два узла, соединенных между собой посредством цифровой сети передачи данных;
• разделяемый ресурс;
• прикладное программное обеспечение, используемое на каждом узле и формирующее, по крайней мере, один программный процесс (клиент), в ходе работы которого может потребоваться доступ к разделяемому ресурсу;
• средство мониторинга (СМ) состояния процессов в системе, расположенное на каждом узле и выполненное с возможностью информировать процессы в системе об отказе какого-либо процесса посредством отправки сообщения;
• средство организации списка процессов-участников какой-то группы процессов (менеджер групп процессов, МГП), расположенное на каждом узле, связанное с СМ и выполненное с возможностью
Figure 00000001
формировать актуальный список процессов-участников группы,
Figure 00000001
отвечать на внешние запросы о текущем составе группы;
• средство формирования уникальных для системы идентификаторов процессов;
• средство блокирования (СБ) доступа к разделяемому ресурсу, расположенное на каждом узле, связанное с МГП и СМ и выполненное с возможностью
Figure 00000001
разрешать или блокировать доступ к разделяемому ресурсу,
Figure 00000001
формировать и посылать сообщения клиенту и другим СБ;
причем прикладное программное обеспечение выполнено с возможностью
• формировать запрос на получение доступа к СБ,
• останавливать действия до получения ответа от СБ; способ, заключающийся в том, что
• если узел впервые обращается за доступом и/или узел восстанавливается после временного прекращения работоспособности, то выполняют следующие действия:
Figure 00000001
назначают уникальный идентификатор для каждого активного процесса в системе, с учетом возможности сравнения идентификаторов через отношение "меньше - больше";
Figure 00000001
при необходимости получения доступа к разделяемому ресурсу, посылают запрос от клиента к СБ, причем клиент остается заблокированным до тех пор, пока СБ не даст клиенту разрешение на доступ;
Figure 00000001
при необходимости освободить полученный ранее доступ к ресурсу, посылают запрос от клиента к СБ на освобождение доступа, причем клиент остается заблокированным до тех пор, пока СБ не выполнит действия, связанные с освобождением доступа;
Figure 00000001
формируют в СБ список претендентов, изначально пустой;
Figure 00000001
формируют в СБ список ожидания, изначально пустой;
Figure 00000001
формируют в СБ список отложенных запросов, изначально пустой;
Figure 00000001
обнуляют в СБ значение N счетчика собственных запросов;
Figure 00000001
обнуляют в СБ значение М счетчика входящих запросов;
иначе переходят к этапу А;
• (А) при необходимости получения доступа к разделяемому ресурсу посылают запрос на получения доступа к разделяемому ресурсу от клиента в СБ;
• посылают запрос из СБ в МГП на добавление идентификатора процесса СБ в группу претендентов;
• дожидаются ответа в СБ на запрос в МГП о добавление идентификатора процесса СБ в группу претендентов;
• посылают запрос из СБ в МГП на получение списка претендентов;
• дожидаются ответа в СБ на запрос в МГП со списком претендентов;
• посылают из СБ всем процессам из списка претендентов сообщения о включении в группу претендентов;
• посылают запрос из СБ в СМ на мониторинг состояния всех процессов из списка претендентов;
• дожидаются подтверждения получения запроса в СБ на запрос в СМ о состоянии каждого процесса из списка претендентов;
• вносят в список ожидания все процессы из списка претендентов;
• посылают из СБ всем процессам из списка ожидания сообщение о необходимости получение доступа, содержащее также уникальный идентификатор процесса СБ и значение N счетчика собственных запросов, равное
N=1+М,
где М - значение счетчика входящих запросов в СБ;
• (Б) ожидают в СБ получения разрешения от всех процессов из списка претендентов;
• если приходит сообщение о том, что какой-либо процесс из списка претендентов остановился, то
Figure 00000001
исключают идентификатор этого процесса из списка ожидания и из списка претендентов; при этом, если оказывается, что список ожидания пуст, то дают разрешение клиенту на доступ к ресурсу;
Figure 00000001
переходят к этапу В;
• если приходит сообщение о том, что какой- либо процесс включился в группу претендентов и его идентификатор отсутствует в списке претендентов, то
Figure 00000001
добавляют идентификатор нового процесса в список ожидания;
Figure 00000001
добавляют идентификатор нового процесса в список претендентов;
Figure 00000001
посылают из СБ новому процессу сообщение о необходимости получение доступа к ресурсу, содержащее также уникальный идентификатор процесса СБ и значение N счетчика собственных запросов, равное N=1+М;
Figure 00000001
посылают запрос из СБ в СМ на мониторинг состояния нового процесса;
Figure 00000001
дожидаются подтверждения получения запроса в СБ на запрос в СМ о состоянии нового процесса;
Figure 00000001
переходят к этапу Б;
• если приходит сообщение на получение доступа от другого процесса, содержащее идентификатор и счетчик собственных запросов другого процесса, то
Figure 00000001
если идентификатор СБ меньше идентификатора другого процесса и при этом значение счетчика собственных запросов СБ равно значению счетчика собственных запросов другого процесса или значение счетчика собственных запросов СБ меньше значения счетчика собственных запросов другого процесса, то
Figure 00000002
добавляют идентификатор нового процесса в список отложенных запросов;
иначе
Figure 00000002
отправляют разрешение другому процессу на доступ;
Figure 00000002
изменяют значение счетчика входящих запросов СБ на максимальное из значений счетчика другого процесса и счетчика входящих запросов СБ;
Figure 00000001
изменяют значение счетчика входящих запросов СБ на максимальное из значений счетчика собственных запросов другого процесса и счетчика входящих запросов СБ;
Figure 00000001
переходят к этапу Б;
• если приходит сообщение с разрешением на доступ от другого процесса, то
Figure 00000001
исключают идентификатор другого процесса из списка ожидания, при этом если после удаления список оказывается пуст, то дают разрешение клиенту на доступ к ресурсу;
Figure 00000001
переходят к этапу В;
• (В) если доступ к ресурсу перестал быть необходим, делают запрос из клиента в СБ на освобождение ресурса;
• высылают из СБ разрешение на доступ всем процессам из списка отложенных запросов.
Все эти средства могут быть сформированы в программном, программно-аппаратном или аппаратном виде, причем предпочтительным является программный вид. Соответствующие программы могут быть созданы специалистами в области программирования (программистами) на основе знания выполняемых программами функций.
После сформирования все эти средства устанавливаются на каждом узле системы.
Распределенная система, в которой реализуется предлагаемый способ, предусматривает наличие нескольких, по крайней мере, двух узлов, связанных между собой, и возможность работы узлов без потери управляемости системы в случае временного или полного выхода из строя (уничтожения) любого узла.
Распределенная система, в которой реализуется предлагаемый способ, может быть изначально неактивной, и для начала работы она должна быть включена (запущена) путем последовательного либо одновременного включения, по крайней мере, двух вычислительных узлов.
В случае, когда способ реализуется в уже работающей системе, эти действия не выполняют.
Уникальные идентификаторы для процессов в системе могут быть сформированы на основе разных методов, например, такой идентификатор можно получить, используя МАС-адрес сетевого адаптера, дополненный счетчиком, значение которого сохраняется на постоянном носителе, изначально равным 0, и значение которого увеличивается каждый раз при перезагрузке узла.
Когда процесс СБ начинает свою работу, он регистрирует свой идентификатор в составе группы через средство МГП. Далее СБ получается список всех зарегистрированных на данный момент идентификаторов процессов-претендентов и явно оповещает их о своем присутствии, рассылая соответствующее сообщение. Это дает возможность уже работающим процессам иметь сведения о появлении нового претендента и выполнить соответствующие действия по мониторингу состояний нового процесса и, если это необходимо, осуществления запроса на получение доступа.
Основным условием захвата разделяемого ресурса процессом СБ является пустота списка ожидания. Изначально список ожидания наполняется идентификаторами всех процессов претендентов, и далее может уменьшается, либо увеличиваться в случае появления новых процессов в группе, что достигается за счет использования средства менеджера групп процессов, а также корректной обработки сообщений о вхождении процесса в группу претендентов.
Активное наблюдение процесса СБ за остальными процессами СБ группы претендентов посредством сетевого монитора (СМ) позволяет, при получении от СМ сообщения об исчезновении какого-либо процесса-претендента, удалить идентификатор исчезнувшего процесса СБ из списка ожидания, таким образом избавляясь от необходимости ждать ответа от несуществующего процесса. Это гарантирует, что список ожидания будет уменьшаться даже в случае отказа процесса-участника, и через какое-то время окажется пуст, выполнив основное условие захвата ресурса.
При возникновении пустого списка ожидания СБ предоставляет процессу доступ к разделяемому ресурсу. После окончания доступа разделяемый ресурс корректно высвобождается и может быть предоставлен другому процессу.
В результате,
• внезапное, полное или временное прекращение функционирования одного или нескольких узлов в системе не приводит к остановке процесса обеспечения доступа к разделяемому ресурсу для остальных узлов, что повышает надежность,
• в работающей группе процессов возможно осуществить добавление нового процесса или удаление процесса, что не изменяет возможность доступа к разделяемому ресурсу для остальных узлов.
Краткое описание чертежей
На фигуре графического изображения показана схема распределенной системы, состоящей из двух вычислительных узлов.
Осуществление изобретения
Предлагаемый способ может быть реализован в распределенной системе, состоящей, например, из трех вычислительных узлов, соединенных посредством сети передачи данных Ethernet. На каждом узле установлена ОС Linux Fedora 25.
В качестве разделяемого ресурса 5 был использован текстовый файл, расположенный в общем сетевом хранилище (см. фигуру графического изображения).
Для программной реализации средств на каждом узле был использован язык программирования Erlang OTP 16 [9] на основе пакета erlang х86_64.
При этом
• в качестве средства сетевого монитора 3 используется функционал модуля erlang:monitor;
• в качестве средства менеджера групп процессов 4 используется модуль pg2;
• в качестве клиента 1 используется процесс ra_mutex_client.erl;
• в качестве средства генератора уникальных идентификаторов используется встроенное в Erlang средство формирования идентификаторов процессов.
• в качестве средства блокирования 2 используется процесс ra mutex ft.erl, реализующий описанные функции.
Возможности корректно обрабатывать отказы отдельных процессов и динамического изменения состава узлов были проверены на тестовом стенде. Дополнительно, способ был промоделирован в среде TLA+, описание модели доступно [10].
После запуска распределенной системы обеспечивалось ведение списков претендентов, ожидания, отложенных запросов. При временном отключении одного или двух узлов (одновременно и последовательно) обеспечивались корректный доступ к разделяемому ресурсу и корректное освобождение доступа, а также динамическое изменение состава списков, без остановки процесса обеспечения доступа к разделяемому ресурсу для остальных узлов, что повышает надежность предложенного способа.
Источники информации
1. Mukesh Singhal - A Taxonomy of Distributed Mutual Exclusion, Journal of Parallel and Distributed Computing, 1993.
2. Naimi, M.; Trehel, M. An improvement of the log(n) distributed algorithm for mutual exclusion, Proc. Of the 7th International Conference on Distributed Computing Systems, 1987.
3. Raymond, K. A tree based algorithm for distributed mutual exclusion, ACM Trans. Comput. Systems 7 (1989).
4. Singhal, M. A heuristically-aided algorithm for mutual exlusion in distributed systems, IEEE Trans. Comput. (1989).
5. Carvalho, O.S.F., Roucairol, G. On mutual exclusion in computer networks, technical correspondence. Comm. ACM (1983).
6. Singhal, M. A dynamic information structure mutual exclusion algorithm for distributed systems. IEEE Trans. Parallel Distribut. Systems (1992).
7. Ricart, G., Agrawala A.K. An optimal algorithm for mutual exclusion in computer networks. Comm. ACM (1981).
8. Buckley, G., Silberschatz, A. A failure tolerant centralized mutual exclusion algorithm. Proc. of the 4th Intl. Conf. On Distributed Computing Systems (1984).
9. Программа по адресу:
https://itbucket.org/unboxed_type/ra_mutex/raw/3c2e67ee6ae15ab35b631db6a18d77a9d895d160/src/ra_mutex_ft.erl
10. Результаты моделирования по адресу:
https://bitbucket.org/unboxed_type/ra_mutex/raw/3c2e67ee6ae15ab35b631db6a18d77a9d895d160/model/RAPlus.tla

Claims (59)

  1. Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе, причем система содержит
  2. по крайней мере два узла, соединенных между собой посредством цифровой сети передачи данных;
  3. разделяемый ресурс;
  4. прикладное программно-аппаратное обеспечение, используемое на каждом узле и формирующее по крайней мере один программный процесс (процесс-клиент), в ходе работы которого может потребоваться доступ к разделяемому ресурсу;
  5. средство мониторинга (СМ) состояния процессов в системе, расположенное на каждом узле и выполненное с возможностью информировать процессы в системе об отказе какого-либо процесса посредством отправки сообщения;
  6. средство организации списка процессов-участников какой-либо группы процессов (менеджер групп процессов, МГП), расположенное на каждом узле, связанное с СМ и выполненное с возможностью
  7. формировать актуальный список процессов-участников группы, отвечать на внешние запросы о текущем составе группы;
  8. средство формирования уникальных для системы идентификаторов процессов, расположенное на каждом узле;
  9. средство блокирования (СБ) доступа к разделяемому ресурсу, расположенное на каждом узле, связанное с МГП и СМ и выполненное с возможностью
  10. разрешать или блокировать доступ к разделяемому ресурсу,
  11. формировать и посылать сообщения процессу-клиенту и другим СБ;
  12. причем прикладное программно-аппаратное обеспечение выполнено с возможностью
  13. формировать запрос на получение доступа к разделяемому ресурсу в СБ,
  14. останавливать действия процесса-клиента, связанные с доступом к разделяемому ресурсу, до получения ответа от СБ;
  15. способ, заключающийся в том, что
  16. если узел впервые обращается за доступом к разделяемому ресурсу и/или узел восстанавливается после временного прекращения работоспособности, то выполняют следующие действия:
  17. назначают уникальный идентификатор для каждого активного процесса в системе с учетом возможности сравнения идентификаторов через отношение "меньше - больше";
  18. при необходимости получения доступа к разделяемому ресурсу посылают запрос от процесса-клиента к СБ, причем процесс-клиент остается заблокированным до тех пор, пока СБ не даст процессу-клиенту разрешение на доступ к разделяемому ресурсу;
  19. при необходимости освободить полученный ранее доступ к разделяемому ресурсу посылают запрос от процесса-клиента к СБ на освобождение доступа к разделяемому ресурсу, причем процесс-клиент остается заблокированным до тех пор, пока СБ не выполнит действия, связанные с освобождением доступа к разделяемому ресурсу;
  20. формируют в СБ список процессов-претендентов на доступ к разделяемому ресурсу, изначально пустой;
  21. формируют в СБ список ожидания доступа к разделяемому ресурсу, изначально пустой;
  22. формируют в СБ список отложенных запросов на доступ к разделяемому ресурсу, изначально пустой;
  23. обнуляют в СБ значение N счетчика собственных запросов;
  24. обнуляют в СБ значение М счетчика входящих запросов;
  25. иначе переходят к этапу А;
  26. (А) при необходимости получения доступа к разделяемому ресурсу посылают запрос на получение доступа к разделяемому ресурсу от процесса-клиента в СБ;
  27. посылают запрос из СБ в МГП на добавление идентификатора процесса СБ в группу процессов-претендентов на доступ к разделяемому ресурсу;
  28. дожидаются ответа в СБ на запрос в МГП о добавление идентификатора процесса СБ в группу процессов-претендентов на доступ к разделяемому ресурсу;
  29. посылают запрос из СБ в МГП на получение списка процессов-претендентов на доступ к разделяемому ресурсу;
  30. дожидаются ответа в СБ на запрос в МГП со списком процессов-претендентов на доступ к разделяемому ресурсу;
  31. посылают из СБ всем процессам из списка процессов-претендентов на доступ к разделяемому ресурсу сообщения о включении в группу процессов-претендентов на доступ к разделяемому ресурсу;
  32. посылают запрос из СБ в СМ на мониторинг состояния всех процессов из списка процессов-претендентов на доступ к разделяемому ресурсу;
  33. дожидаются подтверждения получения запроса в СБ на запрос в СМ о состоянии каждого процесса из списка процессов-претендентов на доступ к разделяемому ресурсу;
  34. вносят в список ожидания доступа к разделяемому ресурсу все процессы из списка процессов-претендентов на доступ к разделяемому ресурсу;
  35. посылают из СБ всем процессам из списка ожидания доступа к разделяемому ресурсу сообщение о необходимости получения доступа к разделяемому ресурсу, содержащее также уникальный идентификатор процесса СБ и значение N счетчика собственных запросов, равное N=1+М,
  36. где М - значение счетчика входящих запросов в СБ;
  37. (Б) ожидают в СБ получения разрешения на доступ к разделяемому ресурсу от всех процессов из списка процессов-претендентов на доступ к разделяемому ресурсу;
  38. если приходит сообщение о том, что какой-либо процесс из списка процессов-претендентов на доступ к разделяемому ресурсу остановился, то исключают идентификатор этого процесса из списка ожидания доступа к разделяемому ресурсу и из списка процессов-претендентов на доступ к разделяемому ресурсу; при этом
  39. если оказывается, что список ожидания доступа к разделяемому ресурсу пуст, то дают разрешение процессу-клиенту на доступ к разделяемому ресурсу; переходят к этапу В;
  40. если приходит сообщение о том, что какой- либо процесс включился в группу процессов-претендентов на доступ к разделяемому ресурсу и его идентификатор отсутствует в списке процессов-претендентов на доступ к разделяемому ресурсу, то
  41. добавляют идентификатор нового процесса в список ожидания доступа к разделяемому ресурсу;
  42. добавляют идентификатор нового процесса в список процессов-претендентов на доступ к разделяемому ресурсу;
  43. посылают из СБ новому процессу сообщение о необходимости получения доступа к разделяемому ресурсу, содержащее также уникальный идентификатор процесса СБ и значение N счетчика собственных запросов, равное N=1+М;
  44. посылают запрос из СБ в СМ на мониторинг состояния нового процесса;
  45. дожидаются подтверждения получения запроса в СБ на запрос в СМ о состоянии нового процесса;
  46. переходят к этапу Б;
  47. если приходит сообщение на получение доступа к разделяемому ресурсу от другого процесса, содержащее идентификатор и счетчик собственных запросов другого процесса, то
  48. если идентификатор СБ меньше идентификатора другого процесса и при этом значение счетчика собственных запросов СБ равно значению счетчика собственных запросов другого процесса или значение счетчика собственных запросов СБ меньше значения счетчика собственных запросов другого процесса, то
  49. добавляют идентификатор нового процесса в список отложенных запросов на доступ к разделяемому ресурсу;
  50. иначе
  51. отправляют разрешение другому процессу на доступ к разделяемому ресурсу;
  52. изменяют значение счетчика входящих запросов СБ на максимальное из значений счетчика другого процесса и счетчика входящих запросов СБ;
  53. изменяют значение счетчика входящих запросов СБ на максимальное из значений счетчика собственных запросов другого процесса и счетчика входящих запросов СБ;
  54. переходят к этапу Б;
  55. если приходит сообщение с разрешением на доступ к разделяемому ресурсу от другого процесса, то
  56. исключают идентификатор другого процесса из списка ожидания доступа к разделяемому ресурсу, при этом если после удаления список оказывается пуст, то дают разрешение процессу-клиенту на доступ к разделяемому ресурсу;
  57. переходят к этапу В;
  58. (В) если доступ к разделяемому ресурсу перестал быть необходим, делают запрос из процесса-клиента в СБ на освобождение разделяемого ресурса;
  59. высылают из СБ разрешение на доступ к разделяемому ресурсу всем процессам-клиентам из списка отложенных запросов на доступ к разделяемому ресурсу.
RU2017143803A 2017-12-14 2017-12-14 Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе RU2673019C1 (ru)

Priority Applications (1)

Application Number Priority Date Filing Date Title
RU2017143803A RU2673019C1 (ru) 2017-12-14 2017-12-14 Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
RU2017143803A RU2673019C1 (ru) 2017-12-14 2017-12-14 Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе

Publications (1)

Publication Number Publication Date
RU2673019C1 true RU2673019C1 (ru) 2018-11-21

Family

ID=64556571

Family Applications (1)

Application Number Title Priority Date Filing Date
RU2017143803A RU2673019C1 (ru) 2017-12-14 2017-12-14 Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе

Country Status (1)

Country Link
RU (1) RU2673019C1 (ru)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987477A (en) * 1997-07-11 1999-11-16 International Business Machines Corporation Parallel file system and method for parallel write sharing
US6681241B1 (en) * 1999-08-12 2004-01-20 International Business Machines Corporation Resource contention monitoring employing time-ordered entries in a blocking queue and waiting queue
US20040230895A1 (en) * 2003-05-16 2004-11-18 Dethe Elza Method and system for enabling collaborative authoring of hierarchical documents with locking
US9053079B2 (en) * 2011-12-12 2015-06-09 Microsoft Technology Licensing, Llc Techniques to manage collaborative documents
RU2591169C2 (ru) * 2010-03-18 2016-07-10 НУОДиБи ИНК. Система управления базой данных
US9514110B2 (en) * 2013-03-28 2016-12-06 Hewlett-Packard Development Company, L.P. Collaborative editing of electronic documents

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987477A (en) * 1997-07-11 1999-11-16 International Business Machines Corporation Parallel file system and method for parallel write sharing
US6681241B1 (en) * 1999-08-12 2004-01-20 International Business Machines Corporation Resource contention monitoring employing time-ordered entries in a blocking queue and waiting queue
US20040230895A1 (en) * 2003-05-16 2004-11-18 Dethe Elza Method and system for enabling collaborative authoring of hierarchical documents with locking
RU2591169C2 (ru) * 2010-03-18 2016-07-10 НУОДиБи ИНК. Система управления базой данных
US9053079B2 (en) * 2011-12-12 2015-06-09 Microsoft Technology Licensing, Llc Techniques to manage collaborative documents
US9514110B2 (en) * 2013-03-28 2016-12-06 Hewlett-Packard Development Company, L.P. Collaborative editing of electronic documents

Similar Documents

Publication Publication Date Title
CN109491776B (zh) 任务编排方法和系统
JP6362120B2 (ja) クラスタ・ブレイン分割後の調停処理方法、クォーラム記憶装置、およびシステム
US9705752B2 (en) Reliably updating a messaging system
US7848261B2 (en) Systems and methods for providing a quiescing protocol
US10574525B2 (en) Configuration agreement protocol method
WO2017167100A1 (zh) 一种数据迁移方法和装置
US20100333084A1 (en) Systems and methods for message-based installation management using message bus
JP6450330B2 (ja) 並列計算処理装置および並列計算処理方法
US10691501B1 (en) Command invocations for target computing resources
CN113067900B (zh) 智能合约的部署方法及装置
CN111625497A (zh) 一种分布式文件系统的部署方法、装置、设备及存储介质
US20130223206A1 (en) Redundant ring automatic recovery
CN106972962A (zh) 高可用集群的配置方法、装置及系统
Mohamed et al. MidCloud: an agent‐based middleware for effective utilization of replicated Cloud services
CN117354260A (zh) 一种电磁暂态跨域分布式并行计算调度方法及装置
US9106676B1 (en) Grid-based server messaging infrastructure
US10122602B1 (en) Distributed system infrastructure testing
Rudkovskyi et al. Interaction support system of network aplications
RU2673019C1 (ru) Способ обеспечения доступа к разделяемому ресурсу в распределенной вычислительной системе
CN115225482B (zh) 一种基于Kubernetes进行Pod容器网络配置的方法及装置
CN114697334B (zh) 一种编排任务的执行方法和装置
JP5993835B2 (ja) マルチノードを用いるスマート端末ファジング装置およびその方法
Devi et al. Self-healing fault tolerance technique in cloud datacenter
CN109688011A (zh) 一种基于OpenStack的agent选择方法及装置
CN113259462B (zh) 区块链消息的分发方法及装置