Удаление структур IPC

Все запросы об удалении структуры 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, позволяющие частично решить такие задачи).