Aby dokonać wyboru między ManualResetEvent lub Thread.Sleep()

Question

Nie jestem pewien, którą strategię zastosować ... Koncentruję się na tym, że moja operacja jest zakończona, ale chciałbym również, aby problemy z wydajnością były minimalne. ... istnieje metoda o nazwie Execute(), która musi czekać (działać synchronicznie) do zakończenia operacji. Ta operacja dzieje się w innym wątku. Istnieją 2 sposoby realizują to samo ...

Korzystając ManualResetEvent

void Execute() 
{ 
    taskHandle = new ManualResetEvent(false); 
    . 
    . 
    //delegate task to another thread 
    . 
    . 
    taskHandle.WaitOne(); 
} 

LUB

za pomocą prostego natomiast skonstruować

void Execute() 
{ 
    . 
    . 
    //delegate task to another thread 
    . 
    . 
    while (!JobCompleted) 
     Thread.Sleep(1000); 
} 

którym jeden z dwóch podejść powinienem przyjąć ... dlaczego?

EDYTOWANIE:

Q2. A co, gdybym po prostu miał puste podczas pracy? Co za różnica...?

while(!JobCompleted); 

EDIT: (coś Zebrałem wcześniej)

http://www.yoda.arachsys.com/csharp/threads/waithandles.shtml - Ten artykuł mówi manualresets są comparitively wolniej, ponieważ wychodzą z kodu zarządzanego i z powrotem w ...

Answer 1

Z ciekawości, dlaczego ManualResetEvent, a nie AutoResetEvent? Tak czy siak, idź z prymitywem systemu operacyjnego OS za pomocą trybu "sleep-check-sleep".

Można również użyć blokady Monitor (jawnie przez Monitor.Enter i Monitor.Exit lub poprzez lock bloku), ale podejście powinno być oparte na co jesteś rzeczywiście robi; jeśli jest to scenariusz „jest tylko jedna z tych rzeczyi muszę wyłącznego dostępu”, a następnie użyć blokady Monitor. Jeśli jest to „muszę czekać aż inny wątek zakończy z powodów innych niż dostęp do zasobów”, a następnie użyć AutoResetEvent lub ManualResetEvent.

sugestie używać Thread.Join są dobre, jeśli (i tylko wtedy)

1. mieć dostęp do innych Thread obiektu
2. Nie chcesz wykonać aż inny wątek kończy.

Jeśli któraś z nich nie jest prawdziwa (nie masz dostępu, lub drugi wątek się nie zakończy, to po prostu zasygnalizuje "wszystko jasne"), wtedy Thread.Join nie jest opłacalny.

Najgorszym rozwiązaniem jest

while(!JobCompleted);

Jako że zwiąże się procesor z niepotrzebnych kontroli zmiennej bez żadnej przerwy pomiędzy nimi. Tak, zablokuje twój wątek, dopóki operacja nie zostanie zakończona, ale maksymalnie wykorzystasz CPU (lub przynajmniej wartość jednego rdzenia).

Answer 2

Jeśli masz dostęp do oryginalny obiekt Thread, lub możesz uzyskać taki dostęp, najlepiej używać Thread.Join().

Edycja: Również, jeśli to ma miejsce w GUI jak WinForms lub WPF, można rozważyć użycie BackgroundWorker

Answer 3

Impreza pozwala na bardziej efektywne wykorzystanie processors- nie masz się obudzić wątek nadrzędny do ankiety. Jądro Cię obudzi, gdy wydarzenie się rozpocznie.

Answer 4

Główną wadą korzystania z Thread.Sleep() jest decyzja, jak długo wątek będzie czekać. Operacja, na którą czekasz, może trwać bardzo długo, a generalnie bardzo trudno dokładnie określić czas. Jeśli wątek śpi zbyt długo, nie najlepiej wykorzystujesz zasoby systemowe.

Aby być optymalnym, powinieneś użyć ManualResetEvent (lub AutoResetEvent), aby Twój wątek został wznowiony natychmiast po zakończeniu zależnej operacji.

Answer 5

Zasadniczo oba podejścia mają to samo znaczenie. Pętla while jest jednak trochę bardziej wyraźna, ponieważ możesz określić czas snu. Chociaż używałbym klas XXXResetEvent, które mają być używane w scenariuszu, w którym pracujesz. Założę się, że klasy wątków zostałyby zaimplementowane teraz lub później z bardziej rozbudowanym kodem gwintowania, aby poradzić sobie z powinowactwem do wątków w procesorach wielordzeniowych.

Answer 6

ManualResetEvent jest zdecydowanie do zrobienia.

Od Fragment kodu podałeś, to wygląda na to delegowanie wykonania w swoim Execute metody. Jeśli tak jest i delegujesz tylko jedno zadanie, dlaczego w ogóle przekazujesz inny wątek, jeśli musisz poczekać na odpowiedź? Równie dobrze możesz po prostu wykonać proces synchronicznie.

Answer 7

manualresets są comparitively wolniej, ponieważ wychodzą z kodu zarządzanego iz powrotem ..

Są prawdopodobnie wolniej niż powiedzieć Wait/Pulse combo, którego należy użyć tutaj moim zdaniem. Ale Manual/AutoResetEvents będzie o wiele szybszy niż jakikolwiek inny Thread.Sleep(x), nawet jeśli wybierzesz x = 1. I nawet jeśli obniżysz rozdzielczość timera Windows do 1 ms.

Co, gdybym po prostu miał puste podczas pracy? Co za różnica...?

Wtedy jeden rdzeń będzie spin na 100%, aż stan okazuje prawdziwe, kradzież z dala czas od innych wątków, które mogłyby zamiast użyć go do zrobienia czegoś pożytecznego, jak obliczania klatek dla „Angry Birds” - czy procesor może po prostu ochłodzić się nieco, opóźniając tragiczne skutki globalnego ocieplenia o kolejne nanosekundy.