Вы бы использовали WaitHandle, когда хотите, чтобы поток отправлял или принимал двоичный сигнал без необходимости в критической секции. Monitor.Wait и Monitor.Pulse с другой стороны требуют критической секции. Как и большинство механизмов синхронизации в BCL, есть некоторые совпадения в том, как могут использоваться упомянутые вами два. Но не думайте, что они выполняют одну и ту же цель.
Monitor.Wait и Monitor.Pulse являются гораздо более примитивным механизмом синхронизации, чем MRE или ARE. Фактически, вы можете построить MRE или ARE, используя не более чем класс Monitor. Самая важная концепция, которую нужно понять, - это то, как отличаются методы Monitor.Wait и WaitHandle.WaitOne. Wait и WaitOne оба переведут поток в состояние WaitSleepJoin, что означает, что поток становится бездействующим и отвечает только на Thread.Interrupt или на соответствующий вызов Pulse или Set. Но, и это главное различие, Wait покинет критическую секцию и получит ее атомным способом . WaitOne просто не может этого сделать. Это различие, столь фундаментальное для поведения этих механизмов синхронизации, которое определяет сценарии, в которых они могут быть использованы.
В большинстве случаев вы бы выбрали MRE или ARE. Они удовлетворяют большинству ситуаций, когда один поток должен получить сигнал от другого. Однако, если вы хотите создать свой собственный механизм сигнализации, вам нужно будет использовать Wait и Pulse. Но, опять же, в .NET BCL уже есть большинство популярных механизмов сигнализации. Следующие сигнальные механизмы уже существуют 1 .
- ManualResetEvent (или ManualResetEventSlim)
- AutoResetEvent
- Семафор (или SemaphoreSlim)
- EventWaitHandle
- CountdownEvent
- Barrier
1 Почетное упоминание относится к классу BlockingCollection. Это не сигнальные механизмы сами по себе, но у него есть качества сигнального механизма с дополнительным преимуществом, что вы можете прикрепить данные к сигналу. В этом случае сигнал означает, что элемент доступен в коллекции, а данные, связанные с этим сигналом, являются самим элементом.