На самом деле зависит от задачи. Event медленнее, но критические секции (Monitor) - это спинлок плюс Event. Т.е. делается N попыток блокировки в цикле, затем при неудаче засыпание на Event.

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

ViPRosDima T,

где то прочитал, что есть ограничение на количество AutoResetEvents (64), не сталкивался ( я не вижу реакции)?
AutoResetEvents это обертка над виндовым Event , для него нет ограничений по количеству.

Есть ограничение 64 для вызова WaitAll() или WaitAny() потому что внутри виндовая WaitForMultipleObjects() и это ее ограничение.

Для Monitor ничего подобного WaitAll()/WaitAny() вообще нет.

ViPRosDima T,

хреново что 64, у меня объектов может быть больше намного
Читай внимательней что я писал.
Еще раз: объектов сколько угодно , хоть 100500, но только 64 объекта можно ждать одновременно (WaitAll() или WaitAny()).

ViPRosПросто я думал - может WaitAll/Any как т по особому этот массив обрабатывают (для массива мониторов нужен еще один монитор - вощем получается многоуровневая структура мониторов)
По-особому. Потому что внутри используется виндовая WaitForMultipleObjects() , а для мониторов ( CRITICAL_SECTION ) ничего похожего нет.

PS Если для мониторов ты делал самодельный WaitAll(), то скорее всего он будет тормознее чем WaitAll() для эвентов.

PPS Для твоей задачи можно поизобретать самодельный объект для синхронизации. Менеджер ресурсов. Примерно так: обработчик регистрирует запрос нужных ресурсов и встает на ожидание, менеджер контролирует освобождение ресурсов и как только все нужные освободились - будит обработчика.

ViPRosДумал о менеджере ресурсов. Но, менеджер этот тоже должен быть синхронизирован.
Его надо вынести в отдельный поток. Запросы передавать через очередь.
Т.е. сам менеджер однопоточный, ждет сообщения из очереди, по мере поступления обрабатывает.
Внутри сообщения AutoResetEvent для пробуждения обработчика и указание требуемых ему ресурсов.
Т.е. как только ресурсы освободились - будим обработчик и закрепляем ресурсы за ним, по окончании он сообщает что закончил, ресурсы освобождаются и т.д.

Осталось придумать как быстро отслеживать кому какие ресурсы нужны :)

Dima TОсталось придумать как быстро отслеживать кому какие ресурсы нужны :)
Как вариант: массив счетчиков для обработчиков, при регистрации прописываем их количество:


для ресурсов массив массивов (List<List<int>>), т.е. по одному массиву на каждый ресурс, а во внутренний массив писать список обработчиков, ожидающих ресурс.
При регистрации обработчика он добавляется во все ресурсы.

При освобождении ресурса проходим по списку привязанных к нему обработчиков и делаем всем worker[i]--, как только получили 0 - значит все необходимые ресурсы свободны и можно запускать обработчик.
При блокировке ресурса - всем ожидающим worker[i]++

ИМХО в однопоточном варианте должно достаточно быстро работать

Dima TКак вариант: массив счетчиков для обработчиков, при регистрации прописываем их количество:


опечатка: записываем количество требуемых ресурсов.

ViPRosНаверное, легче сделать иерархию AutoResetEvents (по 64 в блоке), вощем все это я уже делал для монитора
потому что WaitAll действительно по особому
Тут тоже не все просто. Каждый WaitAll() должен работать в своем потоке, затем надо их как-то синхронизировать, т.е. еще один поток ожидающий все первые.
Сразу просматривается проблема: в первом WaitAll() все ресурсы освободились, а во втором - нет. Что дальше делать? Первый сигналит что "свободно" и требует что-то делать, перестать ожидать первые - а вдруг пока второй набор освобождался в первом уже опять что-то заняли.

Как вариант (без больших переделок): разбиваем ресурсы на кучки по 64, ожидание первой (один WaitAll()), при сработке допроверка остальных, если какая-то несвободна, то ждем ее и т.д. по кругу. Как все освободились - закончили ожидание.