| |
Все запросы об удалении структуры IPC (xxxctl() вследствие команды IPC_RMID) посылаются машине-владельцу. Если структура действительно удалена, то об этом информируется referee, который, в свою очередь, информирует другие машины со структурами с таким же ключом - с целью удаления и этих структур. Удаление делается при наличии прав суперпользователя.
Схема ниже показывает, как обрабатывается ключевое удаление:
Сеть (Компьютер-владелец) | (Арбитрирующий компьютер) | |-1->back_end >-2-+ | | | | ядро | employer-3--|-> referee | |
Здесь структура IPC удаляется на компьютере-владельце;
back_end
находит запрос об этом (1) и раздваивает employer для его
обработки (2), employer информирует referee об удалении
(3).
На следующей схеме показано, что происходит после того, как referee получает эту информацию:
Сеть (Арбитрирующий компьютер) | (Компьютер с ключом) | | | referee~--4------|-> front_end -->worker -6->| ядро | | | | +-7--<---|
То, что показано выше, происходит на всех компьютерах, которые имеют созданные структуры IPC с данным ключом: referee посылает запрос об удалении ключа front_end (4), который раздваивает worker для реализации xxxctl() и непосредственного удаления с привилегиями суперпользователя; worker получает результаты этого процесса, но referee не беспокоится (не ожидает) об этом.
Дополнительно referee проверяет, находится ли структура IPC в разделяемой памяти и только ли один компьютер имеет такую структуру. Если это так, то посылается запрос менеджеру разделяемой памяти (shm_man) этой машины об отсоединении от разделяемой памяти. Это можно сделать по следующей причине: известно, что нет такого процесса на любом из компьютеров, имеющих разделяемую память, который будет обращаться к ней, так как при изначальном присоединении (предотвращение разрушения разделяемой памяти, когда все процессы на машине-владельце завершились) не ставилась цель захватывать что-либо еще. На следующей схеме показаны соответствующие действия для случая, когда сказанное выше справедливо:
Сеть (Арбитрирующий компьютер | (Владелец разделяемой памяти) | referee--8------|-> front_end --9-->shm_man |
В итоге referee информирует shm_man об отсоединении (8 и 9). В данном случае referee также не ожидает подтверждения о том, что shm_man действительно отсоединился.
Далее показаны остальные действия:
Сеть (Компьютер-владелец) | (Арбитрирующий компьютер) | | | ядро |<--12--employer | referee | | | | | +-11-<front_end<-|-----10-+
Теперь referee сообщает оригинальному employer о том, что тот может продолжать работу (10 и 11); employer далее сообщит ядру о том, что и исходный пользовательский процесс может продолжаться (12).
Не предпринимается особых действий, когда владелец не может быть проинформирован об удалении. В таком случае владелец удалит структуру в то время, как другие машины, имеющие структуры с таким же ключом, не будут об этом ничего "знать".
Обратите внимание и на то, что возможна ситуация, когда ряд компьютеров временно недоступен или они не могут быстро удалять свои структуры. Как уже было сказано, referee не заботится о таких вещах: не предпринимается специальных действий, если он не может подключиться к компьютеру и сообщить ему об удалении. К тому же, он не ждет подтверждения перед тем, как продолжить работу (См. программы в каталоге tools, позволяющие частично решить такие задачи).
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |