The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Каталог документации / Раздел "Программирование в Linux" / Оглавление документа
next up previous contents
Next: Удаление структур IPC Up: DIPC - Распределенные межпроцессные Previous: Создание структур IPC и   Contents

Концепция владельца

Данная концепция применима только к структурам IPC с распределенными ключами. Когда процесс впервые создает структуру IPC в пределах кластера при помощи xxxget(), компьютер, на котором он выполняется, становится ее ``владельцем''. Все операции манипулирования с данной структурой проводятся на машине-владельце. Фактически это означает, что может существовать только один активный экземпляр структуры IPC. Это свойство сильно влияет на простоту и семантику при обеспечении сохранности DIPC.

При DIPC процесс-производитель и процесс-потребитель данных могут состоять в следующих отношениях:

  1. Оба находятся на одной машине, которая является владельцем. Такая ситуация сильно напоминает обычные вызовы IPC.
  2. Оба находятся на одной машине, которая не является владельцем. В такой ситуации производитель будет посылать свои данные компьютеру - владельцу. Потребитель будет обращаться к владельцу данных, который в ответ будет посылать их ему. Данные будут ходить ``по кругу''.
  3. Каждый находится на отдельной машине, но одна из этих машин является владельцем. Один процесс вынужден передавать / принимать данные к/от владельцу(-а), а другой может пользоваться обычными технологиями IPC.
  4. Каждый находится на отдельной машине, но ни одна из этих машин не является владельцем. Данная ситуация подобна ситуации 2, но данные ``используют'' компьютер - владелец как промежуточную остановку при движении от компьютера - производителя к компьютеру - потребителю.
Следующие подходы оказывают влияние на принятие решения о привлечении владельца при любой активности DIPC:

  1. Централизованный подход, упрощающий алгоритмы. Процесс "знает", куда он должен отсылать данные, им производимые, - без необходимости опроса всех машин в кластере. Ситуация может быть наихудшей, если запрашиваемые данные еще не произведены, - потому что в этом случае ``проситель'' не знает, где их ожидать. Сопутствующей проблемой может быть то, как найти все ожидающие процессы в кластере, информировать их о доступности некоторых новых данных и выбрать, кто из них должен получить данные.
  2. Наиболее подходящий подход с обычным поведением IPC.
    Предположим, два процесса на двух различных машинах производят некоторые данные с отсутствием синхронизирующих тактов - им очень тяжело согласовать, какие данные должны быть произведены первыми. Рассмотренным выше методом производство и потребление данных организуется последовательно. В отношении к машине-владельцу это предполагает наличие жесткого порядка во время производства и потребления данных. Это сильно напоминает семантику обычных механизмов IPC.
Владельца структуры IPC после его ``закрепления'' заменить невозможно. Другими словами, миграция IPC отсутствует.



2004-06-22



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру