Избегание тупиков
Поскольку по умолчанию для IPC используются синхронные вызовы SEND и RECEIVE, могут возникать тупики, когда два или большее число процессов одновременно пытаются обмениваться сообщениями, и все процессы блокируются в ожидании один другого. Поэтому мы тщательно разрабатывали протокол избегания тупиков, предписывающий частичное, нисходящее упорядочение сообщений.
Упорядочение сообщений приблизительно соответствует разбиению на уровни, описанному в разд. 2.2. Например, обычным пользовательским процессам позволяется только посылать сообщения с использованием примитива SENDREC серверам, реализующим интерфейс POSIX, а эти серверы могут запрашивать сервисы от драйверов, которые, в свою очередь, могут производить вызовы ядра. Однако для асинхронных событий, таких как прерывания и таймеры, требуются сообщения, посылаемые в противоположном направлении, от ядра серверу или драйверу. Использование синхронных вызовов SEND для передачи этих событий может легко привести к тупику. Мы избегаем этой проблемы путем использования для асинхронных событий механизма NOTIFY, который никогда не блокирует вызывающую сторону. Если оповестительное сообщение не может быть доставлено процессу-адресату, оно сохраняется в его элементе таблицы процессов до тех пор, пока он не выполнит RECEIVE.
Хотя протокол избегания тупиков поддерживается обсуждавшимся выше механизмом масок посылки сообщений, мы также реализовали в ядре распознавание тупиков. Если вызов примитива в некотором процессе непредусмотренным образом привел бы к возникновению тупика, то выполнение примитива не производится, и вызывающей стороне возвращается сообщение об ошибке.