Dziś kolejny post z ostatniego cyklu o o wielowątkowości.  Myślę, że Thread.Sleep jest znany każdemu – służy po prostu do uśpienia wątku. Na przykład:

for(int i=0;i<20;i++)
    Thread.Sleep(100);

Kod spowoduje uśpienie wątku na 100 milisekund czyli razem, uwzględniając pętle  >2 sekundy. Wywołanie SpinWait jest podobne:

Thread.SpinWait(100000000)

Pierwsza różnica to parametr wejściowy, który nie jest czasem w milisekundach a liczbą iteracji do przeczekania. Czym się zatem różni przeczekanie od uśpienia? SpinWait nie powoduje zmiany kontekstu. Jak pisałem w poprzednich postach, zmiana kontekstu jest kosztowna ponieważ wymaga przywrócenia stanu procesora. W niektórych przypadkach lepiej tego uniknąć. Generalnie należy się sporo zastanowić nad użyciem SpinWait. Jeśli wiemy, że operacja powinna być wznowiona bardzo szybko wtedy lepiej użyć Spinwait, który nie usuwa wątku a po prostu dosłownie blokuje wątek. Przez ten czas wątek wciąż zużywa zasoby ale jest to lepsze niż task scheduling, zmiana kontekstu itp. Pod warunkiem jeśli nie musimy czekać zbyt długo. W innych przypadkach, lepiej wątek oddać innym zadaniom.

MSDN nie definiuje co to jest liczba iteracji. Osobiście myślę, że jest to jakaś liczba cyklów procesora\liczba wykonanych instrukcji a co za tym czas zależy od konkretnego procesora i jego wydajności. SpinWait może służyć do zaawansowanej synchronizacji. Jeśli wiemy, że jakiś zasób będzie dostępny za parę milisekund to wtedy użycie SpinWait zamiast lock czy co gorsza Sleep jest wydajniejsze. Ale jak pisałem, jest to zdecydowanie mechanizm dla zaawansowanych algorytmów. Zły scenariusz dla Spinwait spowoduje wysokie zużycie procesora i blokadę zasobów, które w przypadku Sleep mogłyby zostać oddane innym zadaniom.