Разница между барьером в C # 4.0 и WaitHandle в C # 3.0?
, если вы посмотрите на это Как присоединить события исходного объекта к глубоко скопированному клону У меня есть пример кода о том, как получить делегат для события через отражение. Насколько я знаю, это единственный способ сделать это в VB.
5 ответов
Похоже, вам любопытно, почему Barrier предпочтительнее производной WaitHandle + WaitForAll? Оба могут достичь схожей цели, если их правильно структурировать.
Я не очень хорошо знаком с Barrier, но одно преимущество, которое бросается мне в глаза, - это проблема с ресурсами. Для синхронизации N потоков с Barrier требуется только один экземпляр Barrier. Для синхронизации N потоков через WaitHandle и WaitAll требуется N дескрипторов. Эти ресурсы дешевы, но не бесплатны. Уменьшение количества ресурсов для синхронизации группы потоков имеет свои преимущества.
См. Барьер . Он ожидает, пока группа из нескольких потоков достигнет определенной точки, а не один. Он часто используется в научных вычислениях и моделировании для обозначения временных «тиков».
Представьте себе сетку кубов размером 1000 x 1000 x 1000, представляющую кубическую милю воздуха. В нулевой момент времени на данный единичный куб влияют различные параметры его соседей, такие как температура и давление. Как только все вычисляют время 1, вы делаете то же самое для времени 2 ... Вы получаете симуляцию погоды. Похожая история с ядерным моделированием.
Существует также вариант барьера, называемый CyclicBarrier , где он принимает потоки, которые не стартовали с начальной линии, и позволяет им снова присоединиться к группе через некоторое время. Из документации не ясно, является ли барьер C # 4 циклическим барьером,
Мне кажется, что время ожидания рассчитано. Дает вам удобство сказать: «когда количество потоков, ожидающих этой блокировки, станет X, отпустите их всех». Ничего подобного нельзя сделать с другой конструкцией, но это кажется удобным.
WaitFor - это оператор Transact SQL. Он блокирует выполнение пакета, хранимой процедуры или транзакции до тех пор, пока не будет достигнуто указанное время или интервал времени, либо указанный оператор не изменит или не вернет хотя бы одну строку.
Барьер - это примитив синхронизации, который принудительно останавливает выполнение между несколькими потоками или процессами в заданной точке и предотвращает дальнейшее выполнение, пока все потоки или процессоры не достигнут заданной точки.
Если вы ссылаетесь на WaitAll, WaitAll требует, чтобы вы поддерживали массив WaitHandles. В этом смысле барьер немного проще в использовании. Однако я согласен, что эти два метода выглядят удивительно похожими.
Barrier предлагает более высокий уровень абстракции и удобства: один SignalAndWait Вызов - это все, что нужно сделать каждому потоку, вместо того, чтобы знать, какой дескриптор в массиве он должен сигнализировать (или использовать мьютекс, чтобы найти и увеличить «следующее доступное место в массиве» и сигнализировать об этом) и иметь сначала сигнал, а затем WaitAll .
В конце, конечно, вы можете выполнить ту же задачу синхронизации, соответствующим образом используя другие механизмы синхронизации, но для такого распространенного шаблона использования, как Барьер воплощает, удобно иметь такое удобное и надежное решение уже там и аккуратно упаковано; -).