Na wstępnie od razu chciałbym dodać, że dla większości aplikacji, dalsze rozważania w tym poście nie mają sensu i należy to traktować jako ciekawostkę. Dla części systemów może to jednak być ważne a mianowicie dla oprogramowania działającego w “czasie rzeczywistym”, wymagającego low-latency.

Dzisiejszy wpis może powstał trochę zbyt wcześnie ale wkrótce powinna pojawić się druga część mojego artykułu o GC, który będzie dotyczył różnych trybów kolekcji. Jednym z tych trybów jest wykonywanie kolekcji w sposób nierównoległy. W skrócie, znajdywanie wszystkich nieosiągalnych obiektów ma miejsce na wątku głównym (główny to ten, który powoduje kolekcje). W podejściach równoległych, istnieje osobny wątek, który na bieżąco sprawdza czy jakieś obiekty są już nieosiągalne. Podejście równoległe daje wrażenie płynności aplikacji (pauzy na kolekcje są dużo krótsze) ale wymaga to więcej zasobów i jest to na końcu po prostu trochę wolniejsze (synchronizacja itp.). Najszybsze jest po prostu zablokowanie wątków i przejście przez drzewo obiektów. Niestety powoduje to opóźnienia i w niektórych aplikacjach jest to bardzo niekorzystne – wyobraźmy sobie aplikację, wyświetlającą animację, która musi się co jakiś czas zatrzymać aby wykonać kolekcję.

Istnieje wiele rozwiązań na ten problem. Cześć z nich pokażę w nadchodzącym artykule. W dzisiejszym wpisie chciałbym zaprezentować jednak trochę inny mechanizm. Wyobraźmy sobie, że mamy rozproszony system przetwarzający tysiące zapytań. Dodajmy również kolejne wymaganie a mianowicie “low latency” – nie możemy sobie pozwolić, że jakieś zapytanie będzie opóźnione z powodu GC. W poście chciałbym pokazać rozwiązanie polegające na transferze zapytań do np. innego węzła w momencie, gdy zbliża się czas kolekcji. Jeśli zatem wiemy, że za 5 sekund będziemy mieli pełną kolekcję wtedy przekierowujemy ruch do innego węzła.

W .NET istnieją 4 funkcję, które będą nam szczególnie przydatne:

• GC.RegisterForFullGCNotification()
• GC.CancelFullGCNotification()
• GC.WaitForFullGCApproach()
• GC.WaitForFullGCComplete()

Utworzymy więc osobny wątek, który będzie monitorował stan GC. W momencie, gdy zbliża się kolekcja, wyśle on komunikat, że system będzie przez jakiś czas obciążony. W celu otrzymania powiadomień od GC należy wywołać funkcję GC.RegisterForFullGCNotification:

GC.RegisterForFullGCNotification(maxGenerationThreshold: 10, largeObjectHeapThreshold: 10);

Funkcja jest bardzo prosta ale niestety parametry wejściowe to trochę czarna magia. W dokumentacji możemy znaleźć następujący opis:

maxGenerationThreshold

Type: System.Int32

A number between 1 and 99 that specifies when the notification should be raised based on the objects surviving in generation 2.

largeObjectHeapThreshold

Type: System.Int32

A number between 1 and 99 that specifies when the notification should be raised based on objects allocated in the large object heap.

Niestety nie jest to zbyt precyzyjne a nawet powiedziałbym bardzo mylące! Podane progi to nie wartości absolutne. Jeśli przekażemy 10 i 10  nie znaczy to, że dostaniemy powiadomienie gdy 10 obiektów zostało wypromowanych do GEN2. Należy te parametry traktować jako wartości relatywne i:

1. Podanie zbyt wysokiej liczby spowoduje, że dostaniemy powiadomienie bardzo szybko, możliwe, że długo przed faktyczną kolekcją.
2. Podanie zbyt małej wartości może nieść ryzyko, że powiadomienia po prostu nie zostaną wysłane.

Zatem należy na nie patrzyć relatywnie – 90 wyśle powiadomienie dużo szybciej niż np. 5.

Mając mechanizm powiadomień możemy stworzyć nowy wątek, który będzie sprawdzał stan pamięci:

private static void MonitorMemory()
{
  while (true)
  {
      GCNotificationStatus gcStartedStatus = GC.WaitForFullGCApproach(-1);
      if (gcStartedStatus == GCNotificationStatus.Succeeded)                    
          Console.WriteLine("Nadchodzi kolekcja.Pamiec:{0}",GC.GetTotalMemory(false));
      else
          Console.WriteLine("Cos poszlo nie tak...");

      GCNotificationStatus gcCompletedStatus = GC.WaitForFullGCComplete(-1);
      if (gcCompletedStatus == GCNotificationStatus.Succeeded)
          Console.WriteLine("Kolekcja zakonczona.Pamiec:{0}", GC.GetTotalMemory(false));
      else
          return;
  }
}

Należy mieć na uwadze, że rozwiązanie dotyczy wyłącznie nierównoległego GC więc należy takowy ustawić w pliku konfiguracyjnym (więcej o concurrent GC w nadchodzącym artykule):

<configuration>
   <runtime>
       <gcConcurrent enabled="false"/>
   </runtime>
</configuration>

W głównym wątku możemy stworzyć pętle, która sztucznie alokuje pamięć, tak abyśmy mogli przetestować metodę MonitorMemory:

class Program
{        
   static void Main(string[] args)
   {
       GC.RegisterForFullGCNotification(maxGenerationThreshold: 10, largeObjectHeapThreshold: 10);
       Task.Factory.StartNew(MonitorMemory);
       while(true)
       {
           byte[]buffer=new byte[85000];
           Thread.Sleep(100);
       }
   }
   private static void MonitorMemory()
   {
       while (true)
       {
           GCNotificationStatus gcStartedStatus = GC.WaitForFullGCApproach(-1);
           if (gcStartedStatus == GCNotificationStatus.Succeeded)                    
               Console.WriteLine("Nadchodzi kolekcja.Pamiec:{0}",GC.GetTotalMemory(false));
           else
               Console.WriteLine("Cos poszlo nie tak...");

           GCNotificationStatus gcCompletedStatus = GC.WaitForFullGCComplete(-1);
           if (gcCompletedStatus == GCNotificationStatus.Succeeded)
               Console.WriteLine("Kolekcja zakonczona.Pamiec:{0}", GC.GetTotalMemory(false));
           else
               return;
       }
   }
}

Na zakończenie kilka uwag. Metody nie gwarantują, że powiadomienie zostanie wysłane zatem nie można projektować algorytmów w ten sposób, że zawsze spodziewają się tego. W celu wstrzymania powiadomień wystarczy wywołać CancelFullGCNotification.

Jaki to ma sens w praktyce? Dla większości aplikacji: żaden. Dla systemów low-latency – nie wiem, nie wykorzystałem jeszcze tego w praktyce i nie wiem czy jest sens. Stworzenie wątku to w końcu skomplikowana sprawa i wiąże się z tym pewne zużycie pamięci.

Każdy wątek posiada metodę Suspend, która wstrzymuje jego wykonywanie. Ktoś mógłby napisać  takiego “potworka”:

class Program
{        
   static void Main(string[] args)
   {
       Thread thread=new Thread(Run);
       thread.Start();
       
       Thread.Sleep(1000);
       thread.Suspend();
       Thread.Sleep(5000);
       thread.Resume();

   }
   static private void Run()
   {
       while(true)
       {
           Console.WriteLine("Running...");
       }            
   }
}

Używanie Suspend jest bardzo złą praktyką i może spowodować wiele problemów. Od którejś wersji .NET Framework, metoda ta została nawet oznaczona jako Obselete. Dlaczego, jest to takie złe podejście?

Zastanówmy się, po co możemy chcieć zawiesić wątek na kilka sekund. Skoro tworzymy go, chcemy w końcu aby wykonał jak najszybciej swoje operacje. Nie ma sensu wstrzymywania go bo oczywiście efekt będzie taki, że operacja zostanie później wykonana. Ktoś może zasugerować, że być może wątek powinien zostać wstrzymany ponieważ na jakimś etapie, pewne dane mogą być jeszcze niegotowe. Jeśli tak to mamy do czynienia z czystą synchronizacją i jest to skrajnie zły scenariusz użycia Suspend.

Do synchronizacji służą takie klasy jak Semaphore, Monitor, Mutex, ManualResetEvent etc. W przypadku Suspend, największy problem to fakt, że nie wiemy kiedy dokładnie wątek zostanie wstrzymany. Może to zdarzyć się to w każdym w momencie. Co jeśli wątek A zawiesza wątek B, który aktualnie jest w sekcji krytycznej (lock, semafor) M? W takim przypadku, o ile wątek A, chce również uzyskać dostęp do M, będziemy mieli deadlock.

Wątek zawieszony oczywiście wymusza zmianę kontekstu. Problem w tym, że wciąż on zajmuje zasoby. Jeśli taki wątek nie zostanie wznowiony potem, mamy memory leak – zasoby będą w pamięci aż do momentu zamknięcia procesu.

W 99.9% Suspend jest skrajnie złą praktyką. W jakich zatem sytuacjach jest to dopuszczalne a nawet stanowi jedyne rozwiązanie? Głównie narzędzia programistyczne, debuggery itp. korzystają z tego. Klasycznym przykładem jest Garbage Collector, który musi wstrzymać wątki w celu znalezienia obiektów nieosiągalnych. Podobnie robi wiele debuggerów i tym podobnych narzędzi. To co jednak cechuje powyższe przykłady to brak wykonywania kolejnych blokad czy jakieś logiki, bazującej na wspólnych danych. Wszystkie te przykłady zatrzymują wątek tylko po to, aby pobrać jakieś dane od nich – stacktrace, graf obiektów itp. W praktyce  są to skrajne sytuacje i osobiście nie spotkałem się z nimi w pracy – nigdy nie musiałem skorzystać z Suspend.

W .NET do synchronizacji dostępnych jest wiele mechanizmów. W dzisiejszym wpisie chciałbym przedstawić różnice między semaforem a muteksem. Na pierwszy rzut oka, wyglądają one identycznie. Przykład:

class Program
{
   static void Main(string[] args)
   {
       Mutex mutex = new Mutex();
       
       mutex.WaitOne();
       Console.WriteLine("Sekcja krytyczna tutaj");
       mutex.ReleaseMutex();

       Semaphore semaphore=new Semaphore(1,1);
       semaphore.WaitOne();
       Console.WriteLine("Sekcja krytyczna tutaj");
       semaphore.Release();
   }
}

Pierwsza różnica to fakt, że semafor może dopuścić kilka wątków naraz. W konstruktorze podajemy ile wątków może uzyskać dostęp jednocześnie do danej sekcji. Mutex jest zawsze binarny i dopuszcza wyłącznie jeden wątek.

Jaka jest różnica między semaforem binarnym a muteksem?

Muteks jest bardziej zaawansowanym tworem. Przede wszystkim zapamiętuje, z którego wątku została założona blokada. Jeśli wątek A wywołał WaitOne, to tylko wątek A może wykonać Release. Semafor tego nie robi, spójrzmy na przykład potwierdzający tezę:

class Program
{
   static Mutex _mutex = new Mutex();

   static void Main(string[] args)
   {
       var t1=Task.Factory.StartNew(Run1);
       Thread.Sleep(100);
       var t2=Task.Factory.StartNew(Run2);

       Task.WaitAll(t1, t2);            
   }
   static void Run1()
   {
       _mutex.WaitOne();
   }
   static void Run2()
   {
       _mutex.ReleaseMutex();
   }
}

Powyższy kod wyrzuci wyjątek ponieważ nie można ReleaseMutex wywołać z innego wątku niż ten, w którym został wykonany WaitOne. Mutex przechowuje zatem identyfikator wątku. Dla odmiany, poniższy kod, korzystający z semafora, nie spowoduje wyjątku:

class Program
{
   static Semaphore _semaphore=new Semaphore(1,1);

   static void Main(string[] args)
   {
       var t1=Task.Factory.StartNew(Run1);
       Thread.Sleep(100);
       var t2=Task.Factory.StartNew(Run2);

       Task.WaitAll(t1, t2);            
   }
   static void Run1()
   {
       _semaphore.WaitOne();
   }
   static void Run2()
   {
       _semaphore.Release();
   }
}

Kolejną zmianą jest rekurencja. Przyjrzyjmy się poniższemu kodu, który próbuje założyć blokadę dwa razy ale w tym samym wątku:

class Program
{
   static Semaphore _semaphore=new Semaphore(1,1);

   static void Main(string[] args)
   {
       var t1=Task.Factory.StartNew(Run1);
       Task.WaitAll(t1);            
   }
   static void Run1()
   {
       _semaphore.WaitOne();
       Console.WriteLine("Run1");
       Run2();
       _semaphore.Release();
   }
   static void Run2()
   {
       _semaphore.WaitOne();
       Console.WriteLine("Run2");
       _semaphore.Release();
   }
}

Semafor spowoduje po prostu deadlock, ponieważ aby założyć blokadę w Run2, najpierw trzeba zwolnić ją w Run1, co jest niemożliwe oczywiście. Mutex przechowuje informacje o aktualnym wątku, zatem wie, że w Run2 nie trzeba już zakładać ponownie blokady:

class Program
{
   static Mutex _mutex=new Mutex();

   static void Main(string[] args)
   {
       var t1=Task.Factory.StartNew(Run1);
       Task.WaitAll(t1);            
   }
   static void Run1()
   {
       _mutex.WaitOne();
       Console.WriteLine("Run1");
       Run2();
       _mutex.ReleaseMutex();
   }
   static void Run2()
   {
       _mutex.WaitOne();
       Console.WriteLine("Run2");
       _mutex.ReleaseMutex();
   }
}

Mutex przechowuje tzw. recursion count – jeśli inna metoda wchodzi do sekcji krytycznej, z tego samego wątku, po prostu licznik recursion count jest zwiększany i nie powoduje to blokady. Niestety powyższe korzyści wiążą się z pewnym obciążeniem ponieważ należy aktualizować kilka innych pól. Z tego wynika fakt, że jeśli rekurencja nie jest potrzebna wtedy lepiej unikać klasy Mutex.

O klasie ManualResetEvent pisałem  na blogu już wielokrotnie. Prosty przykład:

internal static class Sample
{
   private static readonly ManualResetEvent _manualEvent=new ManualResetEvent(false);

   public static void Main()
   {
       Task.Factory.StartNew(Run);
       _manualEvent.WaitOne();
       Console.WriteLine("Exiting...");
   }
   private static void Run()
   {
       Thread.Sleep(1000);
       Console.WriteLine("Run");
       _manualEvent.Set();
   }
}

Zastosowanie ManualResetEvent oraz AutoResetEvent jest szerokie i obejmuje m.in. testy jednostkowe czy synchronizację wątków. W dzisiejszym wpisie jednak nie o tym – jeśli powyższa konstrukcja jest nieznana lub niezrozumiała w pełni to warto poszukać o tym informacji choćby na tym blogu lub np. na MSDN. Dzisiaj chciałbym pokazać, że istnieje pewna odmiana powyższej klasy nazwana ManualResetEventSlim.

Dlaczego ją stworzono? ManualResetEvent jest bardzo skomplikowaną klasą, która pochłania dużo zasobów. Nie zawsze istnieje potrzeba korzystania z niej i dlatego wprowadzono odchudzoną wersję ManualResetEventSlim. Czy jest zatem sens używania ManualResetEvent, który jest tak bardzo rozpowszechniony? Jaka jest różnica pomiędzy powyższymi klasami?

Skrócona wersja to:

1. Używaj ManualResetEvent gdy dana operacja będzie trwała długo i co za tym idzie, WaitOne będzie musiał blokować wątek na dłuższy czas.
2. Używaj ManualResetEventSlim dla krótkich operacji, gdzie blokada nie będzie trwała długo.

ManualResetEvent jest implementacją typowo po stronie kernal’a. A co tym idzie, komunikacja .NET-Kernel musi mieć miejsce, co jest olbrzymim obciążeniem dla CPU i pamięci. Zawsze powinnyśmy preferować rozwiązania czysto .NET, gdzie nie ma komunikacji między światem zarządzanym a niezarządzanym. Oczywiście rozwiązania kernelowe mają przewagę dla długich operacji. Potrafią one bowiem uśpić wątek i zaplanować jakąś inną pracę. Rozwiązania synchronizacyjne bazujące na czystym .NET to tylko zwykły spinning (patrz poprzednie posty jeśli jest to niezrozumiałe). Spinning to nic innego jak zwykła pętla a zatem marnuje ona CPU. Jest to doskonałe dla krótkich operacji bo wtedy nie trzeba komunikować się z kernel, usypiać wątku, planować następnego i w końcu context switching. Dla długich operacji spinning jest  jednak marnowaniem zasobów– wątek nic nie robi tylko wykonuje pustą pętle.

ManualResetEventSlim to rozwiązanie hybrydowe – na początku będzie korzystał z spinningu, a dopiero potem wywoła Monitor.Enter, który z kolei na końcu spowoduje uśpienie wątku i komunikację z kernel. Jeśli mamy świadomość, że operacja potrwa długo wtedy nie ma sensu blokować wątku przez spinning i od razu lepiej skorzystać z ManualResetEvent. W przeciwnym wypadku, ManualResetEventSlim i jego spinning może przynieść bardzo pozytywne skutki. Proszę zauważyć, że ManualResetEventSlim również uśpi wątek po jakimś czasie więc nawet dla długich czasów oczekiwania, klasa nie przyniesie ekstremalnie złych efektów (spinning przez długi czas jest bardzo złym rozwiązaniem). Nie oznacza to oczywiście, że ZAWSZE preferować należy ManualResetEventSlim – jeśli wiemy, że operacja trochę potrwa wtedy nie ma najmniejszego sensu wykonywać pustej pętli.

Sposób korzystania jest praktycznie identyczny:

internal static class Sample
{
   private static readonly ManualResetEventSlim _manualEvent = new ManualResetEventSlim(false);

   public static void Main()
   {
       Task.Factory.StartNew(Run);
       _manualEvent.Wait();
       Console.WriteLine("Exiting...");
   }
   private static void Run()
   {
       Thread.Sleep(1000);
       Console.WriteLine("Run");
       _manualEvent.Set();
   }
}