Может ли EventWaitHandle иметь дело с ложными следами?

Question

Примечание: Я ограничен .NET 3.5, поэтому я не могу использовать ManualResetEventSlim.

Должен ли я иметь дело с Spurious wakeups, делая что-то вроде этого:

var waitHandle = new EventWaitHandle(); 
new Thread(() => 
{ 
    Thread.Sleep(TimeSpan.FromSeconds(5)); 
    waitHandler.Set(); 
}); 
waitHandle.WaitOne(); 

Если да, то правильный барьер памяти устанавливается при вызове Set и/или WaitOne таким образом, что это будет безопасно:

var reallyDone = false; 
var waitHandle = new EventWaitHandle(); 
new Thread(() => 
{ 
    Thread.Sleep(TimeSpan.FromSeconds(5)); 
    reallyDone = true; 
    waitHandler.Set(); 
}); 
while (!reallyDone) 
    waitHandle.WaitOne(); 

В частности, возможно ли, что основной поток в этом примере может не увидеть, что reallyDone установлено в true из-за переупорядочения или кеширования команд? reallyDone должен быть неустойчивым в этом случае или это не нужно?

Answer 1

Нет никаких побочных пробуждений для событий (MRE, ARE и тонкие версии). Почти все программы Windows сломались бы, если бы существовали такие вещи с этими объектами. Вы сражаетесь с ветряными мельницами. Но да, многие функции синхронизации, включая события ожидания и настройки, выполняют полный барьер памяти (который хорошо понимается, но нигде не документируется). Переменные условия, чтобы разрешить ложные пробуждения (как состояние документов). Они не связаны с событиями.

Кроме того, почему возникли побочные пробуждения? Не имеет смысла с точки зрения API. Событие может просто зацикливаться внутри и скрыть побочные пробуждения от вас (действительно, MRESlim делает это). Я могу только повторить: почти все программы сломались. Это не реальность.

The docs say:

блокирует текущий поток до тех пор, пока ток WaitHandle принимает сигнал. Вызывающий этот метод блокирует бесконечно, пока текущий экземпляр не получит сигнал.

Эти утверждения были бы ложными, если бы ложные пробуждения должны существовать в контексте событий.

Вы неверно истолковали то, что видели. У вас есть ошибка, но это не вызвано событием. Техника reallyDone не требуется.