Разница между барьером в C # 4.0 и WaitHandle в C # 3.0?

Question

Я беру C # 4.0, и одна из вещей, которая меня смущает, это концепция барьера.

Разве это не похоже на использование WaitAll метода WaitHandle? Разве это не ждет завершения всех потоков?

Из этой страницы я узнал конструкцию барьера: http://www.managed -world.com / archive / 2009/02/09 / an-intro-to-барьер.aspx

Однако это похоже на метод WaitAll. Что мне не хватает? Какая здесь разница?

Спасибо.

Answer 1

Похоже, вам интересно, почему барьер предпочтительнее, чем производная WaitHandle + WaitForAll? Оба могут достичь аналогичной цели, если правильно структурированы.

Я не очень хорошо знаком с Барьером, но одно преимущество, которое бросается в глаза, - это проблема с ресурсами. Для синхронизации N потоков с барьером требуется только один экземпляр барьера. Для синхронизации N потоков через WaitHandle и WaitAll требуются N дескрипторов. Эти ресурсы дешевые, но не бесплатные. Сокращение количества ресурсов для синхронизации группы потоков имеет свои преимущества.

Answer 2

Barrier предлагает более высокий уровень абстракции и удобства: один вызов SignalAndWait - это все, что нужно каждому потоку, вместо того, чтобы знать, какой дескриптор в массиве должен сигнализировать (или использовать мьютекс для поиска и увеличьте «следующую доступную точку в массиве» и сообщите, что), и необходимо сначала подать сигнал, а затем WaitAll.

В конце, конечно, вы можете выполнить ту же задачу синхронизации путем соответствующего использования других механизмов синхронизации, но для такого распространенного шаблона использования, как воплощение Barrier, удобно иметь такое удобное и надежное решение, которое уже есть и аккуратно упакованы; -).

Answer 3

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

Представьте сетку кубов 1000 x 1000 x 1000, представляющую кубическую милю воздуха. В нулевой момент времени на данный единичный куб влияют различные параметры его соседей, такие как температура и давление. Как только все вычисляют время 1, вы делаете то же самое для времени 2 ... Вы получаете симулятор погоды. Подобная история для ядерной симуляции.

Существует также разновидность барьера, называемая CyclicBarrier , где он принимает потоки, которые не взлетали со стартовой линии, и позволяет ему снова присоединиться к группе через некоторое время. Из документации не ясно, является ли барьер C # 4 циклическим барьером, но есть свойство, называемое PlayersRemaining .

Answer 4

Основная слабая функция WaitAll - это максимальное ограничение дескрипторов (можно использовать только 64 дескриптора) Обходной путь для ограничения дескриптора WaitHandle.WaitAll 64?

Answer 5

WaitFor - это оператор Transact SQL. Он блокирует выполнение пакета, хранимой процедуры или транзакции до тех пор, пока не будет достигнут указанный интервал времени или времени, или пока указанный оператор не изменит или не вернет хотя бы одну строку.

Барьер - это примитив синхронизации, который обеспечивает остановку выполнения между несколькими потоками или процессами в данной точке и предотвращает дальнейшее выполнение, пока все потоки или процессоры не достигнут данной точки.

Если вы ссылаетесь на WaitAll, WaitAll требует от вас поддерживать массив WaitHandles. В этом смысле барьер немного проще в использовании. Тем не менее, я согласен, что эти два метода выглядят удивительно похожими.

Answer 6

Похоже на счетную ручку ожидания для меня. Позволяет вам сказать: «когда число потоков, ожидающих этой блокировки, становится X, отпустите их все». Вы ничего не можете сделать с другой конструкцией, но это кажется удобным.