Projektowanie oprogramowania systemów WĄTKI I SYNCHRONIZACJA

Transkrypt

1 Projektowanie oprogramowania systemów WĄTKI I SYNCHRONIZACJA

2 plan Wątki Właściwości Tworzenie i łączenie Wzorce zastosowań biblioteka OpenMP Synchronizacja Obiekty synchronizacji Wzorzec Monitor

3 Właściwości wątków wątek wykonania działająca ścieżka instrukcji kodu (najmniejsza sekwencja instrukcji, która może być niezależnie zarządzana przez scheduler) Każdy proces posiada przynajmniej 1 wątek (wątek główny, główna pętla programu) Dodatkowe wątki mogą być tworzone na żądanie aby wykonywać specyficzne zadania (wątki robocze worker threads) Biblioteki i system mogą tworzyć dodatkowe wątki, działające niezależnie od kodu użytkownika, które czynią aplikację wielowątkową

4 Wątki vs procesy Procesy są niezależne, wątki istnieją wewnątrz procesów Procesy mają większą konfigurację stanu niż wątki, które współdzielą stan procesu, jego pamięć i zasoby Procesu mają osobną przestrzeń adresową, wątki współdzielą przestrzeń adresową Procesy wchodzą w interakcje między sobą poprzez mechanizmy IPC systemu Przełączenie kontekstu pomiędzy wątkami tego samego procesu jest szybsze niż pomiędzy procesami

5 Wielowątkowość po co? Responsywność przeprowadzaj długie, blokujące operacje w wątkach roboczych, aby aplikacja pozostała responsywna dla użytkownika i nie wyglądała na zawieszoną Podobny efekt można uzyskać za pomocą nieblokującego wejścia/wyjścia, bez wielowątkowości, ale jest to bardziej podatne na błędy programistyczne, trudniejsze i mniej naturalne Wydajność na systemach wielordzeniowych wątki pozwalają uzyskać wynik szybciej poprzez podział pracy na części wykonywane na osobnych rdzeniach Przepływność/utylizacja aplikacje wielowątkowe umożliwiają lepsze wykorzystanie systemu poprzez wykonywanie pracy w wątkach podczas gdy inne są zablokowane oczekując na I/O

6 Wielowątkowość - niebezpieczeństwa Synchronizacja wiele wątków może równocześnie modyfikować te same dane, prowadząc do niespodziewanych efektów Wyścigi (race condition) działanie programu zależy od określonej w czasie kolejności działania wątków. Bez odpowiedniej synchronizacji wątków, ich zależności czasowe mogą być niedeterministyczne (zwłaszcza w systemach wieloprocesorowych) Zakleszczenie (deadlock) niewłaściwe użycie obiektów synchronizacji może prowadzić do sytuacji, kiedy wątek A uzyskał zasób a i czeka aż wątek B zwolni zasób b, podczas gdy wątek B uzyskał zasób b i czeka aż wątek A zwolni zasób a Stabilność wadliwy wątek prowadzi do wywalenia się całego procesu

7 Wyścigi Efekt oczekiwany Efekt możliwy Te sytuacje prowadzą do bardzo trudnych do zdiagnozowania bugów (Heisenbugs) Rozwiązaniem jest użycie obiektów wzajemnej wyłączności (mutual exclusion mutex) lub innych obiektów synchronizacji (np. monitor) lub operacji atomowych

8 Deadlock Niezbędne jest zachowywanie tej samej sekwencji akwizycji zasobów w obu wątkach lub zastosowanie bezpiecznych wzorców np. monitor

9 Cykl życia wątku Poza wątkiem głównym, dodatkowe wątki są powoływane do życia jawnie, poprzez wywołanie systemowe (funkcję systemu operacyjnego) Wątek może być stworzony w stanie wstrzymanym lub działającym, niektóre systemy umożliwiają również wstrzymanie działającego wątku (czego należy unikać bo prowadzi do deadlock-a) Aby utworzyć wątek potrzebujemy funkcji wątku, która będzie stanowić jego ścieżkę wykonania kodu Kiedy funkcja wątku kończy się, wątek staje się joinable (złączalny??) Wątek może zostać złączony (joined) w dowolnym momencie, ale złączenie (join) będzie wstrzymany aż wątek stanie się joinable Złączenie (join) wątku kończy jego istnienie i zwalnia zasoby

10 Na Windows użyj API _beginthread()/_beginthreadex() aby stworzyć wątek (lub funkcję CreateThread()); WaitForSingleObject() lub inne funkcje oczekiwania aby złączyć (join) go Na POSIX-ach użyj API phtread_create() & pthread_join() (patrz man 3 pthread_create) Najlepiej: używaj standardu C++11 i klasy std::thread z nagłówka <thread>

11 Pula wątków Ogólny wzorzec użytkowy, w którym tworzymy wiele wątków, a zadania do wykonania kolejkujemy Wątki robocze pobierają zadania z kolejki, przetwarzają je i zachowują wynik Po zakończeniu zadania wątek powraca do puli i oczekuje na kolejne zadanie (lub natychmiast dostaje zadanie, jeśli już jest w kolejce) Zadania (i ich czas wykonania) mogą być identyczne lub różne możliwe optymalizacje Przepływność systemu się zwiększa (całkowity czas wykonania wszystkich zadań się zmniejsza) Liczba wątków może odpowiadać liczbie rdzeni procesora (dlaczego?)

12 Bezpieczeństwo ze względu na wątki (thread safety) Fragment kodu jest thread-safe jeżeli manipuluje współdzielonymi strukturami danych w sposób, który gwarantuje bezpieczne wykonanie przez wiele wątków na raz (gwarancja braku wyścigów) Rozwiązania Unikaj współdzielonych danych Re-entrancy pisz kod w taki sposób, żeby nie wiązało się to z przechowywaniem stanu w zmiennych globalnych/dzielonych. Dostęp do nie-lokalnego stanu odbywa się za pomocą operacji atomowych Thread-local storage każdy wątek ma własną kopię danych Synchronizuj dostęp do współdzielonych danych Mutual exclusion (wzajemna wyłączność) dostęp do danych jest szeregowany za pomocą obiektów synchronizacji zapewniających że tylko jeden wątek czyta/zapisuje dane na raz Operacje atomowe użycie specjalnych instrukcji, które nie mogą być przerwane przez inne wątki Stan niezmienny po utworzeniu, stan obiektu nie może się zmienić

13 Thread local storage Niektóre systemy lub języki programowania pozwalają tworzyć zmienne, których wartość może być różna w każdym wątku każdy wątek otrzymuje inną kopię tej samej zmiennej Najbardziej popularnym przykładem jest zmienna errno (kod ostatniego błędu) ze standardowej biblioteki języka C gdyby istniała tylko 1 zmienna errno dla wszystkich wątków mielibyśmy łatwo do czynienia z wyścigami (operacje z różnych wątków nadpisują swoje kody błędu) Jak używać? C++11 słowo kluczowe thread_local używane z globalnymi/statycznymi zmiennymi MSVC deklarator _declspec(thread) dla zmiennych GNU C deklarator thread POSIX pthread_key_create()/pthread_setspecific()/pthread_key_delete() Windows TlsAlloc()/TlsSetValue()/TlsGetValue()/TlsFree()

14 Operacje atomowe Procesory posiadają instrukcje, które są nieprzerywalne, tzn. ich wykonanie chwilowo wstrzymuje przerwania sprzętowe (które są używane do przełączania wątków) gwarancja, że instrukcja zakończy się deterministycznym wynikiem na systemach jednoprocesorowych Niektóre procesory posiadają również instrukcje, które uniemożliwiają innym procesorom równoczesną modyfikację tych samych komórek pamięci kosztem spadku wydajności wynikającego z wyczyszczenia cache procesora Każda operacja może być zmieniona w atomową poprzez zamknięcie w sekcji krytycznej dodanie obiektów synchronizacji wzajemnego wykluczenia (mutex) uniemożliwiających innym wątkom równoczesne wykonanie W C++11 używaj szablonu klasy std::atomic<> aby tworzyć atomowe typy podstawowe

15 Kod bezpieczny ze względu na wątki Atomowość poprzez synchronizację (mutual exclusion) Bezpieczny ale nie reentrant globalne zmienne chronione przez mutex Atomowa zmienna globalna

16 Wzorzec singleton i problem równoczesnej inicjalizacji Singleton jest wzorcem projektowym, który ogranicza klasę do stworzenia pojedynczej instancji obiektu (AKA There can be only one) co jest często pożądane Wprowadza to do programu stan globalny Zmienna globalna + wielowątkowość = problemy Co stanie się kiedy kod inicjujący instancę singletona jest wykonany równocześnie przez wiele wątków? (AKA concurrent initialization problem odnosi się to do wszystkich zmiennych globalnych)

17 Problem równoczesnej inicjalizacji Naiwny singleton Działający singleton

18 Biblioteka OpenMP Open Multi-Processing wieloplatformowe, ustandaryzowane API do tworzenia aplikacji wielowątkowych Zwłaszcza do tworzenia wysokowydajnych programów do mielenia numerków Zalety Wady Przenośność (Portability) nie trzeba znać API wątków specyficznego dla danej platformy (jak pthreads albo Windows threads) Proste API w porównaniu do natywnych Ten sam kod może działać jako szeregowy lub równoległy w zależności od konfiguracji środowiska OpenMP, nie trzeba zmieniać projektu aplikacji Proste nie tak wyrafinowane API jak natywne Brak możliwości obsługi błędów OpenMP program się po prostu wywala Brak jawnego użycia obiektów synchronizacji trudne do wykrycia bugi

19 OpenMP keidy używać? Gdy dekomponujemy problem polegający na wykonaniu tego samego zadania na różnych partycjach danych (data parallelism) Przykład: przeprowadź filtrację wielu kanałów danych dźwiękowych równocześnie użycie #pragma omp parallel for

20 Konstrukcje OpenMP Podział/zrównoleglenie pracy tworzenie równoległych pętli i dystrybucja sekcji szeregowego kodu do wątków Podział/zdrównoleglenie danych oznaczenie zmiennych jako współdzielonych albo prywatnych dla wątków Map/reduce określenie zmiennych odbierających wynik redukcji danych z wątków i operacji redukcji Synchronizacja tworzenie sekcji krytycznych, operacje atomowe & bariery wątków Szeregowanie określenie modelu szeregowania dla równoległych pętli Zrównoleglenie warunkowe Detekcja liczby procesorów, funkcje do mierzenia czasu

21 Więcej o OpenMP Rozszerzenia OpenMP stanowią w zasadzie osobny język programowania, który nie jest trywialny W OpenMP nie ma niczego, czego by się nie dało zrobić za pomocą natywnych API, ale czasem OpenMP sprawia, że jest to: Łatwiejsze i szybsze w implementacji Mniej czytelne i trudniejsze do zrozumienia OpenMP pozwala uruchamiać ten sam kod na procesorach CPU i platformach GPGPU domowy superkomputer (patrz również OpenCL ) OpenMP najlepiej sprawdza się przy problemach zawstydzająco równoległych (embarrassingly parallel), bardziej złożone zadania lepiej zostawić dla specjalnie zaprojektowanych modeli używających przenośnych narzędzi wątków jak nagłówek <thread> z C++11 lub biblioteka boost.threads

22 Obiekty synchroniozacji Mutex Semaphore Condition variable Monitor (właściwie nie pojedynczy obiekt) Barrier Read/Write Lock Event (Windows)

23 Mutex MUTual EXclusion object Podstawowe narzędzie tworzenia sekcji krytycznych Tylko jeden wątek może przejąć własność mutexa Inne wątki usiłujące przejąć własność mutexa będą oczekiwać aż pierwszy wątek odda własność Operacje: acquire (lock) release (unlock) try acquire (try lock) zwraca wartość logiczną, czy własność została przekazana

24 Mutex

25 Rodzaje Mutexów W odniesieniu do granic procesów Inter-process używany do IPC, umożliwia blokowanie wątków należących do różnych procesów (POSIX: pthread_mutex_create(); Windows: CreateMutex()) Intra-process tani mutex do używania wewnątrz jednego procesu (Windows: InitializeCriticalSection()) W odniesieniu do rekurencji zwykły zgłosi błąd kiedy ten sam wątek będzie chciał wejść w mutex ponownie rekursywny pozwoli na wejście kilka razy (i będzie wymagał tyle samo odblokowań) tylko takie są dostępne natywnie na Windows

26 wzorzec Scoped lock (C++) Użycie funkcji lock()/unlock() mutexu jest zwykle niebezpieczne (lub niewygodne) w przypadku kodu z wyjątkami W takiej sytuacji sprawdzi się dodatkowa klasa pomocnicza scoped lock, która zablokuje mutex w konstruktorze i odblokuje w destruktorze, więc nawet w przypadku wystąpienia wyjątku, mutex zostanie odblokowany zapobiegając deadlockowi

27 Semaphore Obiekt synchronizacji, który przechowuje licznik zablokowań (i opcjonalnie posiada ograniczenie na maksymalną liczbę zablokowań) Licznik zablokowań zwiększa się za pomocą operacji signal (podniesienie semafora) Licznik zmniejsza się operacją wait; oczekiwanie na semaforze z zerowym licznikiem będzie blokować tak długo, aż semafor zostanie podniesiony Semafor nie ma pojęcia właściciela każdy wątek może czekać lub podnosić semafor Mutex jest specjalnym przypadkiem semafora z maksymalną liczbą zablokowań 1 i ograniczeniem, że tylko wątek który zajął semafor (operacja wait zakończyła się sukcesem) może go zwolnić (podnieść, zasygnalizować) Semafory są trudniejsze do zrozumienia i poprawnego używania niż mutexy, więc raczej należy ich unikać, chyba że się wie co się robi ;)

28 Condition variable Podstawowy składnik monitor-a Wątki będą czekać na obiekcie CV dopóki jeden z nich nie zostanie wypuszczony za pomocą operacji signal (lub wszystkie za pomocą broadcast) CV musi być użyty razem z mutexem wątek, którego oczekiwanie zakończy się sukcesem, automatycznie uzyskuje własność mutexa (atomowo)

29 Condition variable

30 wzorzec użycia Condition variable

31 wzorzec Monitor Sposób użycia CV razem z mutexem z poprzedniego przykładu to wzorzec Monitor Jest to podstawowy schemat postępowania w przypadku gdy wątek oczekuje na jakieś zdarzenie wewnątrz sekcji krytycznej, zaś zdarzenie będzie sygnalizowane z innego wątka Jest to jedyny dostępny konstrukt synchronizacji/oczekiwania w Javie Jest to bezpieczny i sprawdzony sposób na uniknięcie wyścigów podczas oczekiwania na zdarzenie, ponieważ operacja oczekiwania i zwalniania mutexu oraz budzenia i blokowania mutexu odbywają się atomowo

32 Barrier Barrier (lub rendezvous point) jest to miejsce w kodzie, gdzie grupa wątków jest blokowana i nie może kontynuować dopóki wszystkie wątki w grupie nie osiągną bariery Bariera wymusza synchronizację wątków jest to użyteczne w wysokowydajnych obliczeniach i mieleniu numerków

33 Read/Write lock Obiekt nazywany również shared mutex Specjalny rodzaj mutexa, który pozwala wielu wątkom równocześnie wykonać operację read ale tylko jeden wątek może mieć dostęp write Możliwy wzrost wydajności w przypadku, kiedy operacja write zdarza się rzadko, a operacje read często Natywne wsparcie w POSIXach, na Windows brak Jak działa? Zablokowanie dla zapisu zablokuje wszystkie inne wątki, zarówno czytające, jak i piszące Wątki zapisujące będą czekać aż wszystkie wątki piszące i czytające opuszczą RWLock Operacje specjalne: upgrade rwlock z trybu czytania do trybu zapisu Dużo wątków czytających może zagłodzić wątki piszące nigdy nie umożliwając im wejść w rwlock

34 Events (zdarzenia) Windows Specjalny przypadek binarnego semafora (licznik 0/1), który w przeciwieństwie do mutexa nie uznaje własności 2 rodzaje: Manual reset kiedy wątek zakończy sukcesem oczekiwanie na zdarzeniu, musi zostać ręcznie zresetowany do stanu niesygnalizowanego (pozostaje podniesiony dopóki nie zostanie jawnie opuszczony) Automatic reset kiedy wątek zakończy sukcesem oczekiwanie na zdarzeniu, obiekt jest automatycznie, atomowo resetowany do stanu nie-sygnalizowanego (semafor opuszczony) Specyficzne i trudne w poprawnym użyciu lepiej stosować standardowe obiekty (monitor)