Lekka alternatywa dla Manual/AutoResetEvent w C#

Question

Napisałem, co mam nadzieję, jest lekką alternatywą dla używania klas ManualResetEvent i AutoResetEvent w C#/.NET. Powodem tego było posiadanie funkcjonalności typu Event bez wagi użycia obiektu blokującego jądro.

Mimo że kod wydaje się działać dobrze zarówno w testowaniu, jak i produkcji, uzyskanie tego wszystkiego w sposób właściwy dla wszystkich możliwości może być dużym przedsięwzięciem, a ja pokornie zażądam wszelkich konstruktywnych komentarzy i komentarzy od użytkowników StackOverflow na ten temat. Mam nadzieję, że (po przeglądzie) będzie to przydatne dla innych.

Użycie powinno być podobne do klas Manual/AutoResetEvent z funkcją Notify() używaną do Set().

Tu idzie:

using System; 
using System.Threading; 

public class Signal 
{ 
    private readonly object _lock = new object(); 
    private readonly bool _autoResetSignal; 
    private bool _notified; 

    public Signal() 
    : this(false, false) 
    { 
    } 

    public Signal(bool initialState, bool autoReset) 
    { 
    _autoResetSignal = autoReset; 
    _notified = initialState; 
    } 

    public virtual void Notify() 
    { 
    lock (_lock) 
    { 
     // first time? 
     if (!_notified) 
     { 
     // set the flag 
     _notified = true; 

     // unblock a thread which is waiting on this signal 
     Monitor.Pulse(_lock); 
     } 
    } 
    } 

    public void Wait() 
    { 
    Wait(Timeout.Infinite); 
    } 

    public virtual bool Wait(int milliseconds) 
    { 
    lock (_lock) 
    { 
     bool ret = true; 
     // this check needs to be inside the lock otherwise you can get nailed 
     // with a race condition where the notify thread sets the flag AFTER 
     // the waiting thread has checked it and acquires the lock and does the 
     // pulse before the Monitor.Wait below - when this happens the caller 
     // will wait forever as he "just missed" the only pulse which is ever 
     // going to happen 
     if (!_notified) 
     { 
     ret = Monitor.Wait(_lock, milliseconds); 
     } 

     if (_autoResetSignal) 
     { 
     _notified = false; 
     } 
     return (ret); 
    } 
    } 
} 

Answer 1

Działa to z założenia, że ​​wydarzenia Win32 są drogie. Nie są, niewiele mogę sobie wyobrazić, że jest to tańsze niż wydarzenie. Główną wskazówką, że tak właśnie jest, są projektanci .NET decydujący, że dobrym pomysłem byłoby użycie zdarzenia Win32 do implementacji MRE i ARE.

Prawdziwym kosztem zamiennika jest największy FUD, jaki odczujesz, kiedy masz wyścig do gwintowania i nie wiesz, co go powoduje.

Answer 2

Niestety, poprawna implementacja monitora jest dość ciężka, biorąc pod uwagę prymitywy synchronizacji Win32. Moim początkowym podejrzeniem jest to, że "blokada" byłaby większa w korzystaniu z zasobów niż zdarzenie (i prawdopodobnie jest zbudowana na szczycie zdarzenia).

Answer 3

Jednym ze sposobów optymalizacji wydajności AutoResetEvent jest utrzymanie jego stanu (sygnalizowanego/niesygnalizowanego) we własnej zmiennej, więc przed wykonaniem podróży do jądra i rzeczywistym wykorzystaniem obiektu zdarzenia, można po prostu sprawdzić stan aplikacji zmienne i pozostają przez cały czas w trybie użytkownika.
Wysłałem demonstration tej koncepcji kilka miesięcy temu.

Answer 4

Zasadniczo wszelkie sychronizacje są powolne, więc najlepiej ich unikać.

Istnieje jednak duża różnica między ich prędkości:

Procesor wspierany Interlocked Exchange jest najszybszy podczas prosta logiczna flagi wciąż bije AutoresetEvent.

Sprawdź to dla pełnych próbki kodu i performance comparisons on AutoResetEvent and alternatives.