Dziś kolejny mechanizm potrzebny do zrozumienia struktury SpinWait, którą opiszę w następnym poście. Thread.Yield oddaje wątek z powrotem do CPU. Wywołanie mówi, że nie mam nic więcej do roboty i jeśli CPU ma coś lepszego do zrobienia to niech to zrobi a po tym dopiero wątek macierzysty zostanie wznowiony. Innymi słowy jeśli wątek A wywołuje Thread.Yield wtedy CPU zawiesza go, wykonuje inny i potem z powrotem powraca do wątku A. Jednak należy zaznaczyć, że w przypadku Yield, może zostać wybrany wątek wyłącznie wykonywany na tym samym procesorze. Nie można ustąpić miejsca na rzez wątku znajdującego się na innym rdzeniu.

Thread.Sleep (0) oraz Thread.Sleep(1) wykonują to samo z tym, że:

Powyższe metody przydatne są w programowaniu współbieżnym bez stosowania blokad. W następnym poście przedstawię stos działający w środowisku wielowątkowym ale nie wykorzystujący lock’ow. Oczywiście Thread.Yield nie spowoduje, że inny wątek zostanie w całości wykonany. Jest to wyłącznie oddanie trochę czasu.  Task scheduling to skomplikowany mechanizm i nigdy nie wiadomo, kiedy wątek zostanie wstrzymany.

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.

W ostatnich postach opisuje różne mechanizmy synchronizacji w c#. Jak widać, jest tego na prawdę wiele i sama znajomość słowa lock nie wystarcza jeśli poważnie myśli się o algorytmach współbieżnych. Dziś kolejna metoda synchronizacji a mianowicie klasa CountdownEvent. Ostatnie posty oprócz wprowadzenia do wspomnianych klas stanowią wstęp do kolekcji współbieżnych, które zamierzam omówić wkrótce.

Konstruktor CountdownEvent przyjmuje liczbę całkowita (zwykle większą od 0), która stanowi wartość początkową wewnętrznego licznika. Następnie podczas wywołania metody Wait, wątek jest blokowany dopóki licznik nie osiągnie wartości zero. Licznik jest zmniejszany przez metodę Signal, która ma dwa przeładowania. Jedno zmniejsza licznik po prostu o 1 a drugi o wartość przekazaną w parametrze:

var countDownEvent = new CountdownEvent(20);
countDownEvent.Signal(15); 

Jedna bardzo ważna uwaga. CountdownEvent używa mechanizmu Spin opisanego kilka postów wcześniej. Z tego względu, wykorzystanie klasy jest wydajne jednak wyłącznie gdy wiemy, że “blokada” została nałożona na krótki czas. W innych scenariuszach, może się okazać, że wątek blokuje zasoby i lepiej aby został uśpiony ponieważ będzie musiał poczekać trochę na swoją kolej. Polecam przeczytanie tego posta aby w pełni zrozumieć zasadę działania Spin i czym ona się różni od klasycznych blokad.

Analogiczną metodą jest AddCount, która zwiększa licznik:

var countDownEvent = new CountdownEvent(20);
countDownEvent.AddCount(15); 

Metoda Wait blokuje wątek i czeka aż licznik zostanie ustawiony na zero (np. poprzez wysyłanie sygnału za pomocą Signal):

_countdownEvent.Wait();
// jakas logika tutaj

Ponadto można przekazać timeout w milisekundach:

_countdownEvent.Wait(5000);

Z kolei metoda Reset ustawia CurrentCount do InitialCount:

_countdownEvent.Reset();

Aby przekonać się, że CountDownEvent używa SpinWait, sprawdźmy implementację Signal np. w Reflector:

public bool Signal(int signalCount)
{
    int num;
    if (signalCount <= 0)
    {
        throw new ArgumentOutOfRangeException("signalCount");
    }
    this.ThrowIfDisposed();
    SpinWait wait = new SpinWait();
Label_001D:
    num = this.m_currentCount;
    if (num < signalCount)
    {
        throw new InvalidOperationException(Environment.GetResourceString("CountdownEvent_Decrement_BelowZero"));
    }
    if (Interlocked.CompareExchange(ref this.m_currentCount, num - signalCount, num) != num)
    {
        wait.SpinOnce();
        goto Label_001D;
    }
    if (num == signalCount)
    {
        this.m_event.Set();
        return true;
    }
    return false;
}

Signal korzysta z klasy SpinWait, którą omówię w następnym poście ale mechanizm jest analogiczny do SpinLock opisanego w jednym z poprzednich postów – nie wymaga zmiany kontekstu.

Zasada działania CountdownEvent jest podobna do ManualResetEvent z tym, że mamy do dyspozycji licznik liczb całkowitych a nie zwykły boolean. Przykłady zastosowań są również podobne np. synchronizacja zdarzeń.  Podsumowując najważniejsze metody to Wait, AddCount, Signal oraz Reset. Wszystkie poza Wait zmniejszają lub zwiększają wewnętrzny licznik a  Wait blokuje wątek dopóki licznik nie osiągnie wartości zero.

Dziś kolejny post o synchronizacji w c#. Semafor to bardzo popularna forma limitowania liczby wątków, które mogą mieć dostęp do danego kodu. Nie chcę omawiać tutaj podstaw semafora, ale myślę, że warto przypomnieć ogólną zasadę. Pseudokod (źródło Wikipedia):

procedure V (S : Semaphore);
 begin
   (* Operacja atomowa: inkrementacja semafora *)
   S := S + 1;
 end;
 
   (* Operacja atomowa: dekrementacja semafora *)
 procedure P (S : Semaphore);
 begin
   (* Cała operacja jest atomowa *)
   repeat
     Wait();
   until S > 0;
   S := S - 1;
 end;

Semafor składa się z dwóch metod. Jedna zwiększa pewien licznik, druga z kolei zmniejsza. Wejście do sekcji krytycznej jest możliwe tylko wtedy gdy licznik jest większy od zera.  Zatem jeśli na początku licznik ma wartość 1 i zostanie wywołana metoda P to licznik będzie miał wartość 0 a tym samym następnie wywołanie P będzie musiało poczekać. Innymi słowy, przed wejściem zmniejszamy licznik a a przy wyjściu z sekcji krytycznej  zwiększamy go z powrotem. Jeśli początkowa wartość licznika to 1 wtedy tylko jeden wątek może wejść do takiej sekcji. Semafor może dopuścić wiele wątków jednocześnie -  to od nas zależy początkowa wartość licznika.

W .NET semafor jest realizowany za pomocą jednej z dwóch klas. Pierwszą z nich jest Semaphore:

internal class Program
{
   private static int _counter;

   private static void Main(string[] args)
   {
       for (int i = 0; i < 10000; i++)
       {
           var task = new Task(IncreaseValue);
           task.Start();
       }
       Thread.Sleep(2000);
       Console.WriteLine(_counter);

   }
   private static readonly Semaphore _semaphore=new Semaphore(1,1);

   private static void IncreaseValue()
   {
       _semaphore.WaitOne();
       _counter++;
       _semaphore.Release();
   }
}

Za pomocą konstruktora można określić ile wątków chcemy dopuścić do danej sekcji ( w naszym przypadku jest to jeden wątek). WaitOne zmniejsza wspomniany licznik z kolei release zwiększa. Po szczegóły API odsyłam do MSDN. W poście chciałem jednak pokazać drugą klasę odpowiedzialną za semafor: SemaphoreSlim:

internal class Program
{
    private static int _counter;
    
    private static void Main(string[] args)
    {
        for (int i = 0; i < 10000; i++)
        {
            var task = new Task(IncreaseValue);
            task.Start();
        }
        Thread.Sleep(2000);
        Console.WriteLine(_counter);
    }
    private static readonly SemaphoreSlim _semaphore = new SemaphoreSlim(1, 1);
    
    private static void IncreaseValue()
    {
        _semaphore.Wait();
        _counter++;
        _semaphore.Release();
    }
}

Jak widać, sposób użycia jest bardzo podobny. Istnieje jednak kilka bardzo ważnych szczegółów:

1. Używaj SemaphoreSlim dla krótkich operacji.
2. Semaphore może służyć do synchronizacji wątków miedzy procesami. Wtedy należy skorzystać z tzw. named semaphores.  W takiej sytuacji warto zwrócić szczególną uwagę na bezpieczeństwo aby złośliwe oprogramowanie nie spowodowało deadlock.
3. SemaphoreSlim to odchudzona wersja przeznaczona do synchronizacji wątków znajdujących się w tym samym procesie. Semaphore z kolei to wrapper na systemowy, niezarządzany semafor, który jest potężniejszy ale znacząco wolniejszy.

W .NET istnieje wiele sposobów synchronizacji pracy wątków. O dużej części z nich pisałem już na blogu (z ciekawszych np. klasa Barrier ). Najpopularniejszym i najłatwiejszym sposobem jest użycie słowa kluczowego lock. W wielu przypadkach jest to najlepszy i najbezpieczniejszy wybór. SpinLock to zupełnie inne podejście.

W przypadku lock, wątek jest usypiany i budzony gdy przyjdzie na niego kolej. Ma to kilka poważnych wad. Wiążą się one z szeregowaniem oraz zmianą kontekstu. Zmiana kontekstu jest dość czasochłonna ponieważ należy zapisać stan CPU (rejestry itp.) Usypianie więc wątku jest dość skomplikowane ponieważ należy dokonać pewnego rodzaju serializacji.

SpinLock działa zupełnie inaczej – wątek nigdy nie jest usypiany. Po prostu wątek działa i odpytuje czy może już uzyskać dostęp. Jeśli tak to od razu wykonuje operacje bez zbędnego szeregowania czy zmiany kontekstu. SpinLock to bardzo prosty algorytm, wykonujący pętle i sprawdzający jakąś flagę. W pseudokodzie można to zapisać następująco:

while (IsLockAlreadyTaken)
{
    // do nothing        
}

Rozważmy więc klasyczny problem zwiększania pewnej współdzielonej zmiennej:

internal class Program
{
private static int _counter;
private static SpinLock _spinLock=new SpinLock();

private static void Main(string[] args)
{
  for (int i = 0; i < 10000; i++)
  {
      var task = new Task(IncreaseValue);
      task.Start();
  }
  Thread.Sleep(7000);
  Console.WriteLine(_counter);
}
private static void IncreaseValue()
{
  bool lockTaken = false;

  try
  {
      _spinLock.Enter(ref lockTaken);
      _counter++;
  }
  finally
  {          
      if (lockTaken)
          _spinLock.Exit();
  }
 }
}

Korzystanie z SpinLock jest łatwe, wystarczy wywołać metodę Enter a potem Exit.  Należy jednak zwrócić uwagę na kilka niesłychanie ważnych szczegółów:

1. SpinLock to struktura a nie klasa! Z tego względu jeśli chcemy przekazać jako parametr musimy zrobić to przez referencję bo inaczej będą to całkowicie niezależne Spin’y.
2. Przed wywołaniem metody SpinLock.Enter flaga musi być ustawiona na false.
3. Spinlock nie jest “reentrant” czyli nie można wywołać metody Enter dwa razy. W przypadku gdy jest ustawiona właściwość  IsThreadOwnerTrackingEnabled zostanie wyrzucony wyjątek a w przeciwnym wypadku spowoduje to zakleszczenie.

Jakie są wady SpinLock? Największa to fakt, że wątek wciąż zużywa zasoby,wykonuje cykle. Dla operacji krótkotrwałych jest to lepsze niż zmiana kontekstu. W przypadku długich operacji zasoby systemowe są niepotrzebnie zużywane. Należy pamiętać, aby korzystać tylko z SpinLock dla prostych operacji, których wykonanie zajmie kilka cykli CPU – wtedy lepiej poczekać niż zmieniać kontekst. Jeszcze gorszy scenariusz, co w przypadku gdy czekamy na wątek, który został uśpiony ponieważ CPU miał coś ważniejszego do wykonania (interruption)? Im dłuższa operacja tym większe ryzyko. SpinLock jest odradzany dla procesorów jednordzeniowych gdzie trzymanie wątków nic nie robiących jest dużo bardziej kosztowne.