Простейший подход - игнорировать проблему тупиков. Различные люди реагируют на подобную стратегию по-разному. Математики находят ее неприемлемой и утверждают, что тупики должны быть предотвращены любой ценой. Инженеры задают вопрос: как часто возникает данная проблема и как часто система виснет по другим причинам? Если тупик встречается раз в пять лет, но аварийный останов системы из-за отказов оборудования, ошибок компиляторов или ОС происходит раз в месяц, большинство инженеров не пожелают пожертвовать производительностью или удобством, чтобы ликвидировать тупик.
Например, ОС Unix, имеющая в ядре ряд массивов фиксированной размерности, потенциально страдает от тупиков, даже если они не обнаружены. Например, суммарное число процессов в системе определяется размерностью таблицы процессов. Если таблица заполнена, вероятность этого ничтожна, но такое может произойти, то для программы, которая делает вызов fork, резонно подождать некоторое время и попытаться осуществить этот вызов вновь. Следует ли отказываться от вызова fork, чтобы решить эту проблему?
Максимальное число открытых файлов аналогичным образом ограничено размером таблицы индексных узлов. С ними может произойти аналогичная ситуация. Пространство выгрузки на диске - другой лимитируемый ресурс. Фактически любая таблица в ОС - конечный ресурс.
Подход Unix состоит в том, чтобы игнорировать данную проблему в предположении, что большинство пользователей предпочтут случайный тупик нелепым правилам заставляющих их иметь один процесс, один открытый файл и т.п. ... Таким образом, мы сталкиваемся с нежелательным выбором между строгостью и удобством. Трудно найти общее, устраивающее всех решение.