Более того, для конкурентного (кооперативного) взаимодействия существует возможность выявлять deadlock в кооперации. Пример реализации (язык Felix -- скриптовый в стиле ML для генерации кода на С++):
http://felix-lang.org/share/src/web/tut ... index.fdocТам процедуры общаются через спецканалы ввода/вывода, в которых и осуществляется управление планировщиком. Если в кооперации сложилась ситуация, когда никто не может ни прочитать, ни записать данные в канал -- "суицид". В принципе, это даже стандартный способ прекращения работы кооперации. В целом типы каналов можно расширить для прочих операций ввода/вывода, или обобщённо необходимо где-то вызывать аля yield с указанием причины: блокировка в ожидании данных от кооперации или от внешнего источника, либо же конец текущего кванта работы.
А задача монитора в общем случае универсальна. Ниже статья с примером неплохой технологии:
Вложение:
Здесь монитор "ворует" потоки-исполнители у "входящих" процессов, осуществляет универсальную алгоритмику координации. Техника монитора может быть реализована в разных формах, в т.ч. и на "акторах", как для асинхронных, так и для кооперативных процессов (в исходной статье речь именно про многопоточное программирование, но очевидно, что препятствий нет для прочих парадигм взаимодействия). Т.е. среди процессов, общающихся через каналы, выделяется управляющий монитор (и соответственно вводятся специальные типы каналов). В таком случае возникает единый стиль реализации процессов (настоящих параллельных и конкурентных. К слову, примитивы аля Esterel -- блоки-процессы, "следящие" секции, стековая дисциплина и пр. -- дополнительная высокоуровневая обвёртка над базовыми каналами).