W dzisiejszym poście przedstawię zasadę działania semafora oraz mutexa. Zacznijmy od teorii, czym jest semafor i jak można go zaimplementować? Otóż semafor jest sposobem na realizację wzajemnego wykluczania – zapewnienia, że tylko określona liczba wątków będzie mogła jednocześnie wykonać dany fragment kodu. Wyróżniamy semafory binarne, które dopuszczają maksymalnie jeden wątek oraz semafory ogólne, które umożliwiają jednoczesny dostęp określoną przez programistę liczbę wątków.

Implementacja semafora wymaga zaprogramowania dwóch metod: wait oraz signal. Programista wchodząc do sekcji krytycznej wywołuję wait a wychodząc wykonuje signal. Zatem kod źródłowy semafora ogólnego mógłby wyglądać następująco:

// ustawienie wartośći początkowej semafora
counter=5;

// metody atomowe
void Wait()
{
    while(counter<=0){}
    counter--;
}
void Signal()
{
    counter++;
}

Jeśli zasoby aktualnie są używane, metoda Wait będzie blokować dalsze wykonywanie kodu. Dopiero w momencie gdy sekcja krytyczna zostanie opuszczona(wywołanie Signal), warunek w Wait zostanie spełniony i dalszy kod będzie mógł się wykonać. Należy zaznaczyć, że metody muszą być atomowe ponieważ w przeciwnym razie mogą wystąpić problemy synchronizacyjne opisane w poprzednim poście. W przypadku gdy counter posiada wartość początkową równą 1, mamy do czynienia z semaforem binarnym.

Powyższy kod pokazałem tylko po to aby rozjaśnić sposób działania semafora. C# posiada bowiem  gotową klasę System.Threading.Semaphore:

System.Threading.Semaphore semaphore = new System.Threading.Semaphore(1, 1);
semaphore.WaitOne();
// sekcja krytyczna
semaphore.Release(1);

Konstruktor przyjmuje kolejno aktualną oraz maksymalną wartość licznika counter.

Przejdźmy teraz do następnego mechanizmu synchronizacji – Mutex’a. Mutex od strony użytkownika wygląda bardzo podobnie do semafora. Umożliwia jednak synchronizację na poziomie procesów a nie tylko wewnątrz AppDomain.

Należy również wspomnieć o zasadzie  “principle of ownership” – tylko wątek który nałożył blokadę może ją później zdjąć. W przeciwieństwie do semaforów, nie możemy ustawić blokady w wątku A a zdjąć jej w wątku B – zakończy się to wyrzuceniem wyjątku.

Klasycznym przykładem wykorzystania mutexów jest zapewnienie, że tylko jedna instancja programu zostanie uruchomiona:

class Program 
{ 
    static void Main(string[] args) 
    { 
        Mutex oneMutex = null; 

        const string MutexName = "SingleInstance";
        try 
        {         
            oneMutex = Mutex.OpenExisting(MutexName); 
        } 
        catch (WaitHandleCannotBeOpenedException) 
        { 
            // Mutex nie istnieje, obsługa wyjątku
        }         
        if (oneMutex == null)         
        {         
            oneMutex = new Mutex(true, MutexName); 
        } 
        else 
        {         
            oneMutex.Close(); 
            return; 
        } 
        // tworzenie okna itp.
    } 
}

Z przykładu widać, że podczas tworzenia obiektu Mutex można przekazać jego nazwę, która służyć będzie do rozpoznawania obiektu w różnych procesach. W przypadku gdy funkcja OpenExisting zwróci wartość różną od NULL(Mutex już utworzony), program zakończy działanie ponieważ zostanie wykonana instrukcja “return;”.

Oczywiście Mutex posiada również metody WaitOne oraz ReleaseMutex. Sposób użytkowania jest niemalże identyczny jak w przypadku semafora binarnego, więc nie będę pokazywał już kodu źródłowego.

W następnym poście planuje opisać klasy ManualResetEvent, AutoResetEvent oraz Interlocked – zapraszam do odwiedzenia bloga za kilka dni.

Najtrudniejszym zadaniem w programowaniu współbieżnym jest programowanie sekwencyjne a uściślając synchronizacja wątków;). Pewne operacje w naszych programach muszą być wykonywane w sposób sekwencyjny. Często dostęp do danych współdzielonych nie może odbywać się w sposób równoległy. Rozważmy klasyczny problem zwiększania liczby o jeden:

counter = counter + 1;

Jeśli zmienna counter jest współdzielona przez kilka wątków, powyższa  operacja jest niepoprawna. Dlaczego? Zacznijmy od początku. Zwiększanie liczby o jeden, tak naprawdę składa się z trzech operacji:

1. Wczytanie zmiennej do rejestru procesora.
2. Zwiększenie wartości w rejestrze o jeden.
3. Przekopiowanie wartości rejestru z powrotem do zmiennej.

Załóżmy, że counter ma wartość 10. Wątek T1 chce zwiększyć wartość i wczytuje ją do rejestru. Następnie wątek T2 również chce zwiększyć wartość i kopiuje ją do rejestru(wciąż counter==10), zwiększa o jeden i przenosi wynik z powrotem do zmiennej. Zmienna zatem w tej chwili ma już wartość 11. Wątek T1 jednak w swoim rejestrze ma nieaktualną wartość 10. Bez synchronizacji, wątek T1 zwiększy wartość rejestru o 1 i otrzyma nieprawidłowy wynik 11(powinno być 12). Jeśli zamotałem, to mam nadzieję, że poniższy pseudokod rozjaśni problem:

;Wątek T1
Time1:    Kopiowanie wartości do rejestru.
Time4:    Zwiększenie rejestru o jeden. ;rejestr w tej chwili ma już nieaktualną wartość.
Time5:    Przekopiowanie rejestru do zmiennej counter.

;Wątek T2
Time1:    Kopiowanie wartości do rejestru.
Time2:    Zwiększenie rejestru o jeden.
Time3:    Przekopiowanie rejestru do zmiennej counter.

W programowaniu równoległym nie można zakładać, że wątki pracują w tym samym tempem. Każda operacja może trwać dłużej lub krócej w zależności od rdzenia procesora, priorytetu itp.

Zatem wszelkie operacje podzielne powinny być wykonywane w specjalnych obszarach kodu do których dostęp ma tylko jeden wątek jednocześnie –  tzw. sekcjach krytycznych.

C# posiada wiele mechanizmów synchronizacji. Zacznijmy od najpopularniejszego – operatora lock:

class Example
{
    private object m_SyncObject=new object();
    public void ThreadMethod()
    {    
        lock(m_SyncObject)
        {
            // sekcja krytyczna
        }
    }
}

Jak widać pewnie  ułatwienie dla synchronizacji posiada już sam język C# dostarczając słowo kluczowe lock. Niezbędnym jest dostarczenie obiektu, który stanowi pewne odniesienie dla synchronizacji. Za pomocą operatora lock blokujemy dostęp do dostarczonego obiektu (w tym przypadku m_SyncObject). Jeśli drugi wątek będzie chciał w tym samym momencie wejść do obszaru lock, będzie musiał poczekać aż pierwszy skończy wszelkie operacje zawarte w klauzuli lock. Wejście do obszaru lock z tym samym obiektem synchronizującym (m_SyncObject) możliwe jest wyłącznie przez jeden wątek .

Warto zaznaczyć, że nie powinno się używać referencji this oraz operatora lock:

class Example
{    
    virtual public void ThreadMethod()
    {    
        lock(this)
        {
            // sekcja krytyczna
        }
    }
}

Powyższy kod wywoła blokadę (deadlock)  w sytuacji gdy użytkownik klasy napiszę np.:

Example example=new Example();
lock(example)
{
    example.ThreadMethod();
}

Pierwszy lock(example) zadziała, jednak następny w ThreadMethod już nie zostanie nadany ponieważ referencje this oraz example odnoszą się do tego samego obiektu i tym samym lock(this) będzie czekał aż lock(example) zostanie zwolniony(co nie nastąpi nigdy).

Projektując biblioteki nie możemy przewidzieć w jaki sposób przyszli użytkownicy będą korzystać z naszej klasy więc powinniśmy pisać w sposób jak najbardziej elastyczny.

Następnym mechanizmem jest klasa Monitor. W rzeczywistości jest ona tym samym co lock. Słowo kluczowe lock  zostało wprowadzone po to aby programiści nie musieli pisać poniższego kodu:

class Example
{
   private object m_SyncObject = new object();
   public void ThreadMethod()
   {
       System.Threading.Monitor.Enter(m_SyncObject);
       try
       {
           // sekcja krytyczna
       }
       finally
       {
           System.Threading.Monitor.Exit(m_SyncObject);
       }
   }
}

Zwróćcie uwagę na try i finally. Bez tego awaria sekcji krytycznej(wyjątek) mogłaby spodować błędne zakończenie(brak wywołania metody Exit). Polecam wszystkim jednak używanie lock ponieważ trudniej w nim o popełnienie błędu takiego jak np. brak wywołania Exit. Warto jednak przyjrzeć się metodzie Monitor.TryEnter, która pozwala na sprawdzenie czy wejście do sekcji krytycznej jest możliwe.

W następnych postach planuje opisanie klas Mutex, Semaphore, AutoResetEvent, ManualResetEvent, Interlocked oraz o kilku nowościach wprowadzonych w .NET 4.0.

W języku C# mamy kilka mechanizmów tworzenia wątków. Różnią się one zarówno wydajnością jak i przeznaczeniem.

Zacznijmy więc od najpopularniejszego sposobu a mianowicie klasy System.Threading.Thread. Stworzenie wątku polega na inicjalizacji klasy oraz wywołania metody Start:

public class ThreadExample
{
    public CreateThread()
    {            
        System.Threading.Thread thread = new System.Threading.Thread(ThreadMethod);
        thread.Start(null);
    }
    private void ThreadMethod(object parameters)
    {
        while(true)
        {
            // jakiś kod
        }
    }
}

ThreadMethod zawiera kod, który chcemy wykonać współbieżnie. Warto także wspomnieć o właściwości Thread.IsBackground. Gdy ustawiamy ją na true(domyślnie jest false), wtedy wątek stanie się tzw. “background thread” – wątkiem zależnym od rodzica. W sytuacji gdy użytkownik zamknie naszą aplikację, automatycznie zostaną zamknięte wszystkie wątki “background”. Gdybyśmy nie ustawili IsBackground na true, po zamknięciu aplikacji, stworzone przez nas wątki nadal by pracowały, uniemożliwiając tym samym prawidłowe zamknięcie programu.

Najważniejszą jednak rzeczą, którą chciałem poruszyć w poście jest wydajność. Tworzenie klas Thread jest bardzo czasochłonne. O ile nie piszemy programu z naprawdę dużą ilością wątków, to podejście polegające na użyciu klasy Thread jest jednym z najgorszych rozwiązań. Związane jest to z długim czasem wymaganym na inicjalizacje tej klasy. Użycie Thread jest dobre gdy tworzymy pule wątków, które działają przez cały czas działania aplikacji.

Gdy tworzymy często nowe wątki, znacznie lepszym rozwiązaniem jest skorzystanie z gotowej puli wątków, które czekają już zainicjowane na użycie:

public class ThreadPoolExample
{
    public ThreadPoolExample()
    {        
        System.Threading.ThreadPool.QueueUserWorkItem(ThreadPoolMethod);
    }
    private void ThreadPoolMethod(object state) 
    {
        while(true)
        {
            // jakiś kod
        }
    }
}

Wywołując metodę QueueUserWorkItem system sprawdza czy w puli wątków jest wolny wątek .Jeśli tak, zwraca nam go i przechodzi do wykonywania kodu współbieżnego. Wątki zatem nie są tworzone za każdym razem od nowa – zawsze zwracane nam są już gotowe wątki do użycia. Gdy skończymy wykonywanie kodu współbieżnego, wątek nie zostaje zniszczony a wyłącznie zwrócony z powrotem do puli.

Dodatkowo warto wspomnieć, że wszystkie wątki z puli są typu “background”.

Gdy tworzymy interfejs użytkownika i chcemy jakaś operację wykonać w tle(np. połączenie się z WCF) warto zastanowić się nad klasą  BackgroundWorker. Przede wszystkim jest ona bardzo łatwo w użyciu(można ją nawet przeciągnąć z toolbox’a jako zwykłą kontrolkę) oraz posiada kilka zdarzeń, które są istotne dla GUI – np. powiadomienie o postępie prac. Krótki przykład:

public partial class Form1 : Form
{
   public Form1()
   {
       InitializeComponent();
       BackgroundWorker backgroundWorker = new BackgroundWorker();
       backgroundWorker.RunWorkerCompleted += new RunWorkerCompletedEventHandler(backgroundWorker_RunWorkerCompleted);
       backgroundWorker.ProgressChanged += new ProgressChangedEventHandler(backgroundWorker_ProgressChanged);
       backgroundWorker.RunWorkerAsync();
   }

   void backgroundWorker_ProgressChanged(object sender, ProgressChangedEventArgs e)
   {
       // e.ProgressPercentage
   }

   void backgroundWorker_RunWorkerCompleted(object sender, RunWorkerCompletedEventArgs e)
   {
       while (true)
       {
           // jakiś kod kod
       }
   }        
}

Jeśli chcemy wykonywać pewną operacje co jakiś czas np. aktualizację lokalnej bazy danych z danymi otrzymywanymi przez usługę sieciową warto użyć timer’a:

public partial class Form1 : Form
{
   public Form1()
   {
       InitializeComponent();
       System.Threading.Timer timer = new System.Threading.Timer(ThreadMethod,null,0,1000);
       
   }
   private void ThreadMethod(object state)
   {
        // jakiś kod
   }
}

Jak widać ten specjalny timer znajduje się w przestrzeni nazw System.Threading. Metoda ThreadMethod będzie wykonywana współbieżnie co określony czas, przekazany w ostatnim parametrze konstruktora.