Синхронизация и проблема тупиков

При синхронизации процессов может возникнуть проблема взаимной блокировки (дедлок, клинч) или тупика.

Поток-писатель пытается записать данные в заполненный набор буферов – он считывает значение переменной и блокируется в ожидании освобождения хоть одного буфера.

Помочь ему может только поток-читатель, который освободит один буфер.

Но поток-читатель не может войти в критическую секцию, так как она занята потоком – писателем.

Также тупик может возникнуть, когда потоку нужны 2 и более последовательных ресурса, например, принтер и порт.

Поток А запрашивает сначала принтер, потом порт

Поток Б запрашивает сначала порт, затем принтер.

Если поток А получил принтер, был прерван, затем поток Б получил порт и был прерван, потоки не смогут разминуться, так как заняли нужные друг другу ресурсы.

То есть потоки могут образовать очереди к разделяемым ресурсам, но могут и взаимно заблокировать друг друга в зависимости от соотношения их скоростей.

Тупики можно пытаться предотвратить:

- при написании программ задавать одинаковую последовательность запрашивания нескольких ресурсов

- на уровне ОС при запуске задач анализировать возможность возникновения тупика и откладывать запуск опасной задачи.

- выделять ресурсы ОС в определенной, общей для всех потоков последовательности.

Кроме того ОС должна быть снабжена возможностью распознавания уже возникших тупиков (чтобы своевременно снять их)

- ведение и анализ таблиц распределения ресурсов и таблиц запросов к ресурсам

И наконец ОС нужны средства для снятия взаимных блокировок:

- можно снять часть потоков

- можно совершить откат до определенной контрольной точки.