docPrzetwarzanie rozproszone
download 
Reklamacja Transkrypt
Przetwarzanie rozproszone
Spis treści Wykład #1: Wprowadzenie ..................................................................................................................... 8 Cechy systemów rozproszonych ......................................................................................................... 8 Problemy związane z konstrukcją systemów rozproszonych .............................................................. 9 Motywy.............................................................................................................................................. 10 Rozproszony system informatyczny .................................................................................................. 10 Środowisko przetwarzania rozproszonego ................................................................................... 10 Zbiór procesów rozproszonych ..................................................................................................... 11 Skala przetwarzania ....................................................................................................................... 12 Klasy zastosowao ........................................................................................................................... 12 TOP 500 ......................................................................................................................................... 12 Przykłady środowisk .......................................................................................................................... 13 Internet .......................................................................................................................................... 13 GRID ............................................................................................................................................... 13 Cloud computing ........................................................................................................................... 14 Przykład: Sortowanie rozproszone .................................................................................................... 15 Problem zakooczenia..................................................................................................................... 16 Definicje............................................................................................................................................. 16 Awaria............................................................................................................................................ 16 Błąd ................................................................................................................................................ 16 Wada ............................................................................................................................................. 16 Detektory awarii ................................................................................................................................ 16 Rozproszony konsensus..................................................................................................................... 16 Wykład #2: Przetwarzanie rozproszone ................................................................................................ 20 Procesy rozproszone i sekwencyjne .................................................................................................. 20 Proces rozproszony- definicja........................................................................................................ 20 Proces sekwencyjny....................................................................................................................... 20 Klasy operacji ..................................................................................................................................... 20 Komunikat- definicja ......................................................................................................................... 20 Kanał- definicja .................................................................................................................................. 21 Kanały incydentny, wejściowe i wyjściowe ................................................................................... 21 Stan kanału .................................................................................................................................... 21 Rodzaje komunikacji .......................................................................................................................... 23 Komunikacja synchroniczna .......................................................................................................... 23 Komunikacja asynchroniczna ........................................................................................................ 23 Model formalny procesu sekwencyjnego ......................................................................................... 23 Stan procesu .................................................................................................................................. 23 Zdarzenia ....................................................................................................................................... 23 Funkcja tranzycji ............................................................................................................................ 24 Procesy zakooczone, wstrzymane ................................................................................................. 25 Procesy aktywne, pasywne ........................................................................................................... 25 Modele żądao .................................................................................................................................... 26 Model jednostkowy ....................................................................................................................... 26 Model AND .................................................................................................................................... 26 Model OR ....................................................................................................................................... 26 Podstawowy model spośród ................................................................................................... 27 Model OR-AND .............................................................................................................................. 27 Dysjunkcyjny model spośród .................................................................................................. 28 Model predykatowy ...................................................................................................................... 28 Wykład #3: Proces rozproszony ............................................................................................................ 29 Proces rozproszony ........................................................................................................................... 29 Zbiór stanów globalnych ............................................................................................................... 29 Zbiór stanów globalnych początkowych ....................................................................................... 29 Zbiór zdarzeo globalnych............................................................................................................... 29 Globalna funkcja tranzycji ............................................................................................................. 30 Częściowe wykonanie procesu ...................................................................................................... 30 Stan osiągalny ................................................................................................................................ 30 Historia wykonania ........................................................................................................................ 30 Proces rozproszony jako graf ........................................................................................................ 30 Relacja poprzedzania zdarzeo ....................................................................................................... 31 Diagramy przestrzenno-czasowe................................................................................................... 31 Graf stanów osiągalnych ............................................................................................................... 32 Diagramy równoważne.................................................................................................................. 33 Monitor.............................................................................................................................................. 34 Cechy monitora ............................................................................................................................. 34 Konwencja zapisu algorytmów .......................................................................................................... 34 Typ FRAME..................................................................................................................................... 34 Typ MESSAGE ................................................................................................................................ 34 Typ CONTROL ................................................................................................................................ 35 Typ SIGNAL .................................................................................................................................... 35 Typ PACKET .................................................................................................................................... 35 Wykład #4: Czas wirtualny, złożonośd algorytmów .............................................................................. 36 Czas wirtualny ................................................................................................................................... 36 Zegar logiczny- definicja ................................................................................................................ 36 Zegar skalarny- definicja ................................................................................................................ 37 Algorytm Lamporta........................................................................................................................ 37 Zegar wektorowy- definicja ........................................................................................................... 38 Algorytm Matterna ........................................................................................................................ 39 Kanały ................................................................................................................................................ 40 Kanały FIFO .................................................................................................................................... 40 Kanały typu FC ............................................................................................................................... 41 Funkcje kosztu ................................................................................................................................... 49 Oznaczenia..................................................................................................................................... 49 Definicja ......................................................................................................................................... 49 Rząd funkcji ................................................................................................................................... 49 Złożonośd czasowa ........................................................................................................................ 50 Złożonośd komunikacyjna.............................................................................................................. 50 Warunki poprawności ....................................................................................................................... 50 Wykład #5, 6: Detekcja zakleszczenia ................................................................................................... 52 Wprowadzenie .................................................................................................................................. 52 Nieformalna definicja problemu zakleszczenia ............................................................................. 52 Procesy aktywne i pasywne............................................................................................................... 52 Warunek uaktywnienia ................................................................................................................. 53 Zakleszczenie ..................................................................................................................................... 53 Zakleszczenie- definicja ................................................................................................................. 53 Przykłady zakleszczeo .................................................................................................................... 54 Klasyfikacja problemów detekcji zakleszczenia............................................................................. 55 Model aplikacyjnego przetwarzania rozproszonego ..................................................................... 56 Algorytm Chandy, Misra, Hass dla modelu AND ........................................................................... 57 Algorytmy detekcji zakleszczenia dla modelu OR ......................................................................... 58 Złożonośd czasowa algorytmu detekcji zakleszczenia w środowisku synchronicznym dla modelu spośród .................................................................................................................................... 66 Algorytm detekcji zakleszczenia w środowisku asynchronicznym ................................................ 66 Dwufazowy algorytm detekcji zakleszczenia................................................................................. 68 Detekcja zakleszczenia dla modelu predykatowego ..................................................................... 73 Wykład #7, 8: Konstrukcja spójnego obrazu stanu globalnego............................................................. 76 Konfiguracja....................................................................................................................................... 76 Konfiguracja spójna ....................................................................................................................... 76 Linia odcięcia, odcięcie spójne .......................................................................................................... 77 Predykaty globalne i ich własności .................................................................................................... 79 Stan globalny systemu ....................................................................................................................... 79 Modele stanów globalnych ........................................................................................................... 80 Metoda wyznaczania stanu globalnego ........................................................................................ 83 Algorytmy konstrukcji spójnego obrazu stanu globalnego ........................................................... 85 Niedeterminizm przetwarzania rozproszonego .............................................................................. 104 Wykład #9, 10: Problem detekcji zakooczenia .................................................................................... 105 Przykład ilustrujący potrzebę poprawnej detekcji zakooczenia ...................................................... 105 Definicja zakooczenia ...................................................................................................................... 105 Definicja nieformalna zakooczenia.............................................................................................. 105 Definicja formalna zakooczenia................................................................................................... 105 Zakooczenie dynamiczne ............................................................................................................. 106 Zakooczenie statyczne ................................................................................................................. 106 Klasyczna definicja zakooczenia .................................................................................................. 107 Problem detekcji zakooczenia ......................................................................................................... 107 Model przetwarzania synchronicznego........................................................................................... 107 Detekcja zakooczenia dla modelu synchronicznego ................................................................... 107 Model przetwarzania dyfuzyjnego .................................................................................................. 110 Algorytm Dijkstry-Scholten’a ....................................................................................................... 111 Model przetwarzania asynchronicznego ......................................................................................... 114 Algorytm detekcji zakooczenia dla systemów asynchronicznych ............................................... 114 Cechy algorytmu Misra................................................................................................................ 116 Model atomowy przetwarzania ...................................................................................................... 116 Algorytm z licznikami wiadomości Matterna .............................................................................. 117 Jednofazowy algorytm detekcji zakooczenia .............................................................................. 120 Wektorowy algorytm detekcji zakooczenia ................................................................................ 122 Detekcja zakooczenia statycznego .................................................................................................. 125 Koncepcja algorytmu ................................................................................................................... 125 Algorytm detekcji zakooczenia statycznego................................................................................ 125 Dowód poprawności algorytmu .................................................................................................. 127 Złożonośd algorytmu ................................................................................................................... 129 Detekcja zakooczenia dynamicznego .............................................................................................. 129 Koncepcja algorytmu ................................................................................................................... 129 Algorytm detekcji zakooczenia dynamicznego............................................................................ 129 Złożonośd algorytmu i jego cechy................................................................................................ 133 Wykład #11: Niezawodnośd przetwarzania......................................................................................... 135 Poprawnośd procesu ....................................................................................................................... 135 Pojęcia podstawowe ....................................................................................................................... 135 Klasy awarii procesów ..................................................................................................................... 135 Modele kanałów komunikacyjnych ................................................................................................. 136 Kanały rzetelne ............................................................................................................................ 136 Kanały wytrwałe .......................................................................................................................... 137 Kanały niezawodne...................................................................................................................... 138 Modele systemów rozproszonych w kontekście niezawodności .................................................... 140 Systemy asynchroniczne.............................................................................................................. 140 Systemy synchroniczne ............................................................................................................... 140 Systemy częściowo synchroniczne .............................................................................................. 140 Detektory awarii .............................................................................................................................. 141 Wzorzec awarii ............................................................................................................................ 142 Historia detektora awarii ............................................................................................................. 143 Formalna definicja detektora awarii ........................................................................................... 143 Własności detektorów................................................................................................................. 143 Klasyfikacja detektorów .............................................................................................................. 144 Jakośd detekcji- metryki .............................................................................................................. 146 Implementacja detektora awarii ..................................................................................................... 150 Mechanizm pulsu ........................................................................................................................ 150 Mechanizm odpytywania ............................................................................................................ 150 Implementacja detektora P: mechanizm pulsu........................................................................... 151 Implementacja detektora P: mechanizm pulsu......................................................................... 153 Problem wyboru lidera .................................................................................................................... 154 Algorytm wyboru ostatecznego lidera ........................................................................................ 155 Modele przetwarzania..................................................................................................................... 158 Wykład #12: Mechanizmy rozgłaszania niezawodnego ...................................................................... 160 Rozgłaszanie niezawodne ................................................................................................................ 160 Definicja nieformalna .................................................................................................................. 160 Klasy mechanizmów rozgłaszania niezawodnego ....................................................................... 160 Podstawowe rozgłaszanie niezawodne ........................................................................................... 161 Specyfikacja ................................................................................................................................. 161 Operacje komunikacyjne ............................................................................................................. 162 Algorytm ...................................................................................................................................... 162 Zgodne rozgłaszanie niezawodne.................................................................................................... 163 Specyfikacja ................................................................................................................................. 163 Operacje komunikacyjne ............................................................................................................. 164 Algorytm pasywny ....................................................................................................................... 164 Algorytm aktywny ....................................................................................................................... 166 Jednolite rozgłaszanie niezawodne ................................................................................................. 168 Specyfikacja ................................................................................................................................. 168 Operacje komunikacyjne ............................................................................................................. 169 Algorytm z potwierdzeniami od wszystkich ................................................................................ 169 Algorytm z potwierdzeniami od większości ................................................................................ 171 Probabilistyczny algorytm rozgłaszania niezawodnego .................................................................. 172 Problem implozji potwierdzeo .................................................................................................... 172 Specyfikacja ................................................................................................................................. 173 Operacje komunikacyjne ............................................................................................................. 173 Idea algorytmu plotkowania ....................................................................................................... 174 Algorytm aktywny ....................................................................................................................... 175 Algorytm pasywny ....................................................................................................................... 177 Zgodne rozgłaszanie niezawodne z przyczynowym uporządkowaniem wiadomości ..................... 181 Specyfikacja ................................................................................................................................. 181 Operacje komunikacyjne ............................................................................................................. 182 Algorytm ...................................................................................................................................... 182 Zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości ............................ 184 Specyfikacja ................................................................................................................................. 184 Operacje komunikacyjne ............................................................................................................. 184 Algorytm ...................................................................................................................................... 184 Wykład #13: Problem konsensusu ...................................................................................................... 190 Konsensus- wprowadzenie .............................................................................................................. 190 Konsensus a zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości.... 191 Konsensus w systemach w pełni asynchronicznych .................................................................... 191 Konsensus w systemach częściowo synchronicznych ................................................................. 192 Detektory awarii a konsensus ..................................................................................................... 192 Konsensus podstawowy .................................................................................................................. 192 Specyfikacja ................................................................................................................................. 192 Operacja propose ........................................................................................................................ 193 Operacja decide ........................................................................................................................... 193 Algorytm rozgłoszeniowy ............................................................................................................ 194 Algorytm hierarchiczny................................................................................................................ 200 Konsensus jednolity......................................................................................................................... 206 Specyfikacja ................................................................................................................................. 206 Operacja propose ........................................................................................................................ 207 Operacja decide ........................................................................................................................... 207 Algorytm rozgłoszeniowy ............................................................................................................ 207 Algorytm hierarchiczny................................................................................................................ 209 Konsensus probabilistyczny............................................................................................................. 211 Specyfikacja ................................................................................................................................. 211 Operacja propose ........................................................................................................................ 212 Operacja decide ........................................................................................................................... 212 Algorytm ...................................................................................................................................... 212 Algorytm zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości ..... 217 Złożonośd ..................................................................................................................................... 219 Wykład #1: Wprowadzenie Plan wykładu a) b) c) d) Wprowadzenie Podstawowe definicje Charakterystyka środowiska przetwarzania rozproszonego Przykłady środowisk: Internet GRID Przetwarzanie rozproszone… @Home Google Cechy systemów rozproszonych a) Duża wydajnośd (duża moc obliczeniowa i maksymalna przepustowośd, krótki czas odpowiedzi) wynikająca z możliwości jednoczesnego udziału wielu jednostek i systemów w realizacji wspólnego celu przetwarzania. Jeśli pewne obliczenia da się rozłożyd na zbiór obliczeo cząstkowych, które można wykonywad współbieżnie, to system rozproszony umożliwia przydzielenie tych obliczeo do poszczególnych stanowisk i współbieżne ich wykonanie. Ponadto, jeżeli pewne stanowisko jest w danej chwili przeciążone zadaniami, to częśd z nich można przenieśd do innego, mniej obciążonego stanowiska. Takie przemieszczanie zadad nazywa się dzieleniem obciążeo (ang. load sharing). b) Duża efektywnośd inwestowania (względnie niskie koszy niezbędne do uzyskania wymaganej wydajności systemu) wynikająca z korzystnego stosunku ceny do wydajności; c) Wysoka sprawnośd wykorzystania zasobów (wysoki stopieo wykorzystania zasobów i współczynnik jednoczesności) wynikająca z możliwości współdzielenia stanowisk usługowych, specyficznych urządzeo, programów i danych przez wszystkich użytkowników systemu, niezależnie od fizycznej lokalizacji użytkowników i zasobów. Po połączeniu ze sobą różnych stanowisk (o różnych możliwościach) użytkownik jednego stanowiska może korzystad z zasobów dostępnych na innym (np. użytkownik węzła A może korzystad z drukarki laserowej zainstalowanej w węźle B, natomiast użytkownik węzła B może w tym samym momencie mied dostęp do pliku znajdującego się w A); d) Skalowalnośd (możliwośd ciągłego i praktycznie nieograniczonego rozwoju systemu bez negatywnego wpływy na jego wydajnośd i sprawnośd) wynikająca z modularności systemu i otwartości sieci komunikacyjnej. Moc i możliwości przetwarzania może wzrastad w miarę dodawania do systemu nowych zasobów, w szczególności komputerów. W praktyce skalowalnośd jest często ograniczona poprzez przepustowośd sieci oraz, niekiedy, poprzez np. specyficzne protokoły wymiany informacji. Niemniej skalowalnośd systemu rozproszonego jest nieporównywalnie lepsza w stosunku do systemu scentralizowanego; e) Wysoka niezawodnośd (odpornośd na błędy) wynikająca z możliwości użycia zasobów alternatywnych. W przypadku awarii jednego stanowiska w systemie rozproszonym pozostałe mogą kontynuowad pracę. Jeżeli system składa się z dużych, autonomicznych instalacji (tzn. komputerów ogólnego przeznaczenia), to awaria jednego z nich nie wpływa na działanie pozostałych. Natomiast, gdy system składa się z małych maszyn, z których każda odpowiada za jakąś istotną funkcję (np. za wykonywania operacji wejścia- wyjścia z koocówek konwersacyjnych lub za system plików), wówczas z powodu jednego błędu może zostad wstrzymane działanie całego systemu. Ogólnie można powiedzied, że istnienie w systemie wystarczającego zapasu (zarówno sprzętu, jak i danych) sprawia, że system może pracowad nawet po uszkodzeniu pewnej liczby jego węzłów. f) Otwartośd funkcjonalna (łatwośd realizacji nowych, atrakcyjnych usług komunikacyjnych, informatycznych i informacyjnych) wynikająca z integracji otwartej sieci komunikacyjnej i efektywnych, uniwersalnych jednostek przetwarzających; g) Współdzielenie zasobów (ang. resource sparing) wiąże się z tym, że wielu użytkowników systemu może korzystad z danego zasobu (np. drukarek, plików, usług, itp.); h) Transparentnośd (ang. transparency) oznacza ukrycie przed użytkownikiem szczegółów rozproszenia, np. gdzie ulokowane są zasoby lub jak są one fizycznie zaimplementowane, pod jakim systemem pracują itd. Przezroczystośd ma zasadnicze znaczenie dla komfortu działania użytkownika oraz dla niezawodności budowanego oprogramowania. Niekiedy, np. dla celów optymalizacyjnych, użytkownik może zrezygnowad z pełnej przezroczystości. Przykładem przezroczystości jest Internet- klikając w aktywne pole na stronie WWW nie interesujemy się, gdzie znajduje się odpowiadająca mu strona oraz jak i na czym jest zaimplementowane. Problemy związane z konstrukcją systemów rozproszonych Pełne wykorzystanie wymienionych cech systemów rozproszonych wymaga jednak efektywnego rozwiązania wielu problemów. Problemy, które wiążą się z konstrukcją systemów rozproszonych to: a) b) c) d) Optymalne zrównoleglenie algorytmów przetwarzania Ocena poprawności i efektywności algorytmów rozproszonych Alokacja zasobów rozproszonych Synchronizacja procesów- charakterystyczny dla systemów rozproszonych asynchronizm komunikacji i działania procesów implikuje niedeterminizm przetwarzania. Dodatkowo brak wspólnej pamięci ogranicza dostępne wprost mechanizmy komunikacji i synchronizacji. e) Ocena globalnego stanu przetwarzania f) Realizacja zaawansowanych modeli przetwarzania g) Niezawodnośd h) Nieprzewidywalnośd- system rozproszony jest nieprzewidywalny w swoim działaniu, ponieważ zakłócenia mogą byd powodowane przez wiele przyczyn: małą przepustowośd i awarię łączy lub komputerów, zbyt duże obciążenie danego serwera, lokalne decyzji administracyjne serwera, itd. i) Bezpieczeostwo- dla systemu scentralizowanego wystarcza w zasadzie strażnik z karabinem. System rozproszony nie może byd chroniony w ten sposób, przez co może byd narażony na różnorodne ataki (włamania, wirusy, sabotaż, odmowa płatności, itd.) z wielu stron, które trudno zidentyfikowad. Konieczne jest zatem wprowadzenie dodatkowych mechanizmów ochronnych. j) Złożonośd- systemy rozproszone są trudniejsze do zaprogramowania i do administrowania niż systemy scentralizowane. Zależą od własności sieci, np. jej przepustowości i czasu transmisji, co utrudnia zaprojektowania i zrealizowanie wielu algorytmów i procesów przetwarzania. Utrudnione zarządzanie systemem rozproszonym jest spowodowane tym, że konsekwencje różnych działao administracyjnych są trudniejsze do zidentyfikowania- podobnie z przyczynami sytuacji anormalnych, w szczególności awarii. Motywy a) Ogromne rzeczywiste zapotrzebowanie na systemy rozproszone b) Dostępnośd środków technicznych i praktyczne możliwości realizacji systemów rozproszonych c) Różnorodnośd otwartych problemów związanych z konstrukcją i zarządzaniem systemami rozproszonymi Rozproszony system informatyczny Rozproszony system informatyczny obejmuje: Środowisko przetwarzania rozproszonego Węzły (autonomiczne jednostki przetwarzające) Łącza (zintegrowana sied komunikacyjna pomiędzy łączami) Środowisko przetwarzania rozproszonego jest zbiorem autonomicznych jednostek przetwarzających (węzłów, zbioru niezależnych komputerów i zasobów komputerowych zdolnych do kooperacji postrzeganych przez użytkownika jako całościowo spójny system), zintegrowanych siecią komunikacyjną (środowiskiem komunikacyjnym, łączami komunikacyjnymi, łączami transmisyjnymi). Ogólnym celem projektowym systemów rozproszonych jest stworzenie przezroczystego, otwartego, elastycznego, wydajnego i skalowalnego mechanizmy współdzielenia zasobów. Komunikacja Komunikacja między węzłami możliwa jest tylko przez transmisję pakietów informacji (wiadomości, komunikatów) łączami komunikacyjnymi. Zegary Jednostki przetwarzające realizują przetwarzanie z prędkością narzucaną przez lokalne zegary. Jeżeli zegary te są niezależne dla węzłów, to mówimy o ich asynchronicznym działaniu, natomiast jeżeli zegary lokalne są zsynchronizowane lub istnieje wspólny zegar globalny dla wszystkich węzłów, to mówimy, że działają one synchronicznie. Węzeł Jednostka przetwarzająca obejmującym: a) b) c) d) (węzeł) jest elementem środowiska przetwarzania rozproszonego Procesor Lokalną pamięd operacyjną Interfejs komunikacyjny Oprogramowanie zarządzające Łącze komunikacyjne Łącze komunikacyjne jest elementem umożliwiającym transmisję informacji między interfejsami odległych węzłów. Wyróżnia się łącza jedno- i dwu-kierunkowe. Bufory łącza Łącza wyposażone są w bufory o określonej pojemności (ang. links capacity). Jeżeli łącze nie posiada buforów (innymi słowy, posiada bufory o zerowej pojemności), to mówimy o łączu niebuforowanym, w przeciwnym razie- o łączu buforowanym. Kolejność odbierania komunikatów a) Łącza FIFO- kolejnośd odbierania komunikatów wysyłanych z danego węzła jest zgodna z kolejnością ich wysyłania b) Łącza nonFIFO- w przeciwnym wypadku Łącza mogą gwarantowad również, w sposób niewidoczny dla użytkownika, że żadna wiadomośd nie jest tracona, duplikowana lub zmieniana- są to tzw. łącza niezawodne (ang. reliable, lossless, duplicate free, error free, uncorrupted, no spurious). Czas transmisji w takim łączu niezawodnym (ang. transmission delay, in-transit time) może byd ograniczony lub jedynie określony jako skooczony lub nieprzewidywalny (dla nieprzewidywalnego czasu transmisji wiemy, że wiadomośd dotrze, ale nie wiemy, kiedy). Zbiór procesów rozproszonych Zbiór procesów sekwencyjnych realizujących wspólne cele przetwarzania Struktura środowiska przetwarzania równoległego często przedstawiana jest jako graf: w którym: Wierzchołki grafu reprezentują jednostki przetwarzające , Krawędzie grafu niezorientowanego lub łuki grafu zorientowanego, reprezentują odpowiednio łącza dwu- lub jedno-kierunkowe Przykłady topologii połączeo między węzłami: Skala przetwarzania a) Systemy koocowe (ang. end systems)- stosunkowo mała liczba komponentów dobrze zintegrowanych ze sobą, zaprojektowanych z myślą o wydajnej współpracy b) Klastry- zwiększona skala przetwarzania, koniecznośd zastosowania nowych algorytmów, zredukowana integracja pomiędzy elementami c) Sieci intranetowe- różnorodnośd, wiele centrów zarządzania, brak wiedzy o stanie globalnym, d) Internet- brak scentralizowanego zarządzania, rozproszenie geograficzne, międzynarodowy charakter sieci Klasy zastosowań a) Aplikacje wykorzystujące przetwarzanie rozproszone na wielu jednostkach obliczeniowych (ang. distributed supercomputing) b) Aplikacje wymagające dużej przepustowości (ang. high throughput) c) Aplikacje „na żądanie” (ang. on demand) d) Aplikacje intensywnie przetwarzające dane (ang. data intensive) e) Aplikacje umożliwiające współpracę (ang. collaborative) TOP 500 Stan na lipiec 2010r. Wartości Rmax oraz Rpeak są wyrażone w TFlops’ach. Rank Site 1 Oak ridge National Laboratory 2 National Supercomputing Centre in Shenzhen (NSCS) China 3 DOE/NNSA/LANL United States 4 National Institute for Computational Computer/Year Vendor Jaguar - Cray XT5-HE Opteron Six Core 2.6 GHz / 2009 Cray Inc. Nebulae - Dawning TC3600 Blade, Intel X5650, NVidia Tesla C2050 GPU / 2010 Dawning Roadrunner BladeCenter QS22/LS21 Cluster, PowerXCell 8i 3.2 Ghz / Opteron DC 1.8 GHz, Voltaire Infiniband / 2009 IBM Kraken XT5 - Cray XT5-HE Opteron Six Core 2.6 GHz Cores Rmax Rpeak Power 224162 1759.00 2331.00 6950.60 120640 1271.00 2984.30 122400 1042.00 1375.78 2345.50 98928 831.70 1028.85 Sciences/University of / 2009 Tennessee Cray Inc. United States Forschungszentrum JUGENE - Blue Gene/P Juelich (FZJ) Solution / 2009 294912 825.50 5 Germany IBM Prawo Moore’a na temat szybkości komputerów jest nadal prawdziwe! 1002.70 2268.00 Przykłady środowisk Internet 1995 45 Liczba użytkowników sieci Internet *mln+ 2002 2005 445,9 1080 (?)2015 2000 Dostęp do sieci Internet wg krajów *mln osób+ USA 197,8 Chiny 119,5 Japonia 86,3 Indie 50,6 Niemcy 46,3 Polska 10,6 GRID „Grid obliczeniowy to infrastruktura sprzętu i oprogramowania, która umożliwia niezawodny, wiarygodny, spójny, wszechobecny i niedrogi dostęp do olbrzymich możliwości obliczeniowych” /Ian Foster/ Grid tworzą maszyny połączone w sied i oprogramowane w taki sposób, by możliwe było współdzielenie zasobów (obliczeniowych, dyskowych) pomiędzy użytkowników gridu. Oprogramowanie gridu umożliwia kierowanie zadao obliczeniowych do wolnych zasobów, koordynowanie równoległej pracy wszystkich maszyn gridu i zapisywanie wyników obliczeo na uwspólnionych zasobach pamięci masowych. Mocną stroną gridów jest możliwośd wykorzystania ich do spożytkowania wolnych mocy obliczeniowych maszyn (np. stacji roboczych niewykorzystywanych w nocy). Cechy: o Usługa wiarygodna Użytkownicy żądają pewności, że otrzymają przewidywalny, nieprzerwany poziom wydajności dzięki różnym elementom tworzącym GRID. o o o Usługa wszechobecna (powszechnie dostępna) Usługa zawsze powinna byd dostępna, niezależnie od tego, gdzie znajduje się użytkownik tej usługi. Usługa spójna Potrzebny jest standardowy serwis, dostępny poprzez standardowe interfejsy, pracujący ze standardowymi parametrami. Usługa relatywnie tania Dostęp do usługi powinien byd relatywnie tani tak, by korzystanie z takiej usługi było atrakcyjne także z ekonomicznego punktu widzenia. Trzy spojrzenia na GRID: o Użytkownik- wirtualny komputer, który minimalizuje czas wykonania obliczeo oraz zapewnia dostęp do zasobów. o Programista- zestaw narzędzi i interfejsów zapewniających przezroczysty dostęp do danych. o Administrator- środowisko umożliwiające monitorowanie, administrowanie i bezpieczne używanie rozproszonych zasobów obliczeniowych, dyskowych oraz sieciowych. Czego GRID nie może: o Naruszad bezpieczeostwa i autonomii poszczególnych jednostek wchodzących w jego skład o Powodowad konfliktów w działaniu z istniejącym już oprogramowaniem o Narzucad użytkownikom języków programowania, narzędzi, bibliotek do programowania równoległego, itp. Co GRID powinien: o Umożliwiad rozproszenie geograficzne zasobów o Obsługiwad heterogenicznośd sprzętową i programową o Byd połączony poprzez heterogeniczną sied o Korzystad z ogólnie dostępnych, standardowych protokołów i interfejsów o Byd odporny na zawodny sprzęt o Pozwalad na dynamikę dostępu do sprzętu o Zrzeszad różne organizacje (wirtualne) z ich własnymi politykami bezpieczeostwa i dostępu do zasobów Cloud computing Chmura obliczeniowa (ang. cloud) to zbiór zasobów wraz z oprogramowaniem, zarządzanych i udostępnianych z użyciem usług przez dostawcę. Typowa charakterystyka Skalowalne, dostępne na żądanie Napędzane ekonomią, nie standardami; pay-as-you-go Łatwe w użyciu Dostępne dla wielu użytkowników z pomocą wirtualizacji Możliwości i ryzyka „płacisz za tyle, ile używasz” Eliminacja kosztów inwestycyjnych- infrastruktury… ryzyka Automatyzacja zarządzania przez dostawcę, automatyzacja użycia przez użytkownika (skalowalnośd na żądanie itp.) Iluzja dostępu do nieskooczonej puli zasobów dostępnych na żądanie; dowolne zastosowanie Gdzie są moje dane? Nad czym mam kontrolę? Co jeśli jeden dostawca nie działa?... Przykład: Sortowanie rozproszone Rozważmy problem sortowanie rozproszonego zbioru składającego się z naturalnych, w środowisku rozproszonym o węzłach (procesorach), gdzie . Zadaniem każdego procesu jest uporządkowanie przypisanej mu części zbioru liczb naturalnych i wyznaczenie elementu minimalnego. Element minimalny jest później wysyłany do lewych sąsiadów każdego procesora. Po otrzymaniu wiadomości z wartością minimalną, proces wyznacza element maksymalny i wysyła go do prawego sąsiada. Kroki powyższe są powtarzane dopóki zbiór nie zostanie uporządkowany. Zbiór wstępnie podzielony na podzbiory oraz : różnych liczb w taki sposób, że dla każdego mamy , - liczba elementów zbioru minimalny element zbioru maksymalny element zbioru procesy tworzące przetwarzanie rozproszone o topologii łaocucha, skojarzone ze zbiorami . Pary procesów składowych , połączone są kanałami dwukierunkowymi. Każdy z procesów ma za zadanie uporządkowad przypisany mu na wstępie zbiór i wyznaczyd element . Następnie procesy wysyłają elementy do swoich lewych sąsiadów (procesów ) i oczekują na odpowiedź zawierającą . Po otrzymaniu wiadomości z wartością , a przed wysłaniem odpowiedzi, proces wyznacza nowy element . W ogólności, nowowyznaczony może byd równy otrzymanego ostatnio . Następnie każdy z procesów wysyła odpowiedź ze swoim elementem maksymalnym do prawego sąsiada. Po otrzymaniu odpowiedzi, procesy znów sortują zbioru i jeśli w wyniku tego sortowania wartośd różnid się będzie od poprzednio wysłanego elementu minimalnego, to proces wysyła ten nowy element do lewego sąsiada. Cel sortowania rozproszonego zostaje osiągnięty, gdy uporządkowany zostanie każdy zbiór ponadto dla każdego : , , a Problem zakończenia Problem jednak w tym, że każdy proces ma tylko wiedzę lokalną, dotyczącą jego lokalnego zbioru i częściowo zbiorów bezpośrednich sąsiadów. Na tej podstawie nie mogą jednak wnioskowad o zakooczeniu całego przetwarzania. Potrzebny jest zatem dodatkowy mechanizm pozwalający stwierdzid, że globalne warunki zakooczenia sortowania rozproszonego zostały spełnione. Definicje Awaria Awaria (ang. failure)Błąd Błąd (ang. error)- Wada Wada (ang. fault)- działanie (zachowanie) procesu niezgodnie ze specyfikacją składnik stanu procesu odpowiedzialny za będącą jego następstwem awarię. Może on byd symptomem awarii, która ujawni się natychmiast lub dopiero w przyszłości. stwierdzona lub hipotetyczna przyczyna wystąpienia błędu Detektory awarii Detektor awarii to mechanizm rozproszony udostępniający procesom przetwarzania rozproszonego informacje o awariach procesów. W ogólności, detektory nie są doskonałe: mogą się mylid. Istnieją klasy detektorów o różnej jakości detekcji. (patrz: Wykład #11: Detektory awarii) Rozproszony konsensus Problemem konsensusu nazywamy sytuację, w której potrzebne jest ustalenie „kompromisu” przez wszystkie procesy biorące udział w przetwarzaniu i wybraniu przez wszystkie procesy jednej opcji zaproponowanej przez jeden z nich. Przykładowym problemem konsensusu jest wybranie pewnej liczby przez wszystkie procesy. Każdy z nich wybiera pewną wartośd i proponuje ją jako jedna z możliwości, wysyłając tę wartośd do pozostałych jednostek przetwarzających. Po zebraniu informacji od pozostałych procesów, każdy z nich ustala, która z zaproponowanych wartości jest najlepsza i tę wartośd wybiera (ostatecznie każdy z procesów musi wybrad tę samą liczbę). Wybrana liczba musi pochodzid ze zbioru początkowo zaproponowanego przez jeden z procesów uczestniczących w przetwarzaniu rozproszonym. Problem: jak dokonad wyboru? Pierwsza otrzymana wartośd (błąd- kanały komunikacyjne mogą dostarczad wiadomości w innej kolejności różnym procesom) Od predefiniowanego nadawcy (błąd- niektóre procesy mogą ulec awarii) Najmniejsza/największa otrzymana wartośd (?) Większe wartości (?) Ponadto, należy zastanowid się, jak długo czekad na zebranie propozycji. Problem dwóch armii Problem wygląda następująco: na wzgórzu znajduje się armia generała C, licząca 5000 żołnierzy, natomiast po dwóch stronach wzgórza znajdują się wrogie jemu jednostki generałów A i B o liczności po 3000 żołnierzy każda. Kryterium zwycięstwa jest licznośd armii w momencie rozpoczęcia walki, zatem, aby zwyciężyd generałowie A i B muszą zaatakowad w tym samym momencie. W tym celu generał A wysyła do generała B posłaoca z wiadomością: „Atakujemy o świcie”. Generał B, po odebraniu informacji decyduje się odesład gooca z informacją, że otrzymał wiadomośd. Gdy generał A, otrzymuje odpowiedź od generała B, że ten zna moment ataku, musi upewnid generała B o tym, że jego posłaniec dotarł do niego z potwierdzeniem. Generał A przesyła zatem informację, że wiadomośd generała B do niego dotarła. Generał B jednak, po otrzymaniu kolejnej wiadomości, zastanawia się jednak, skąd generał A będzie wiedział, że jego posłaniec dotarł na drugą stronę wzgórza przez wrogie tereny. Myśli zatem o ponownym wysłaniu posłaoca z powrotem do generała A… Łatwo zauważyd, że armie generała A i B tak naprawdę mogą nigdy nie zaatakowad, bo wciąż będą „potwierdzad potwierdzenia”. Uzgadnianie bizantyjskie Innym znanym problemem dotyczącym przetwarzania rozproszonego jest uzgadnianie bizantyjskie, które również łatwo można zobrazowad przez ukazanie kilku armii i dowodzących nimi generałów. Załóżmy, że mamy 5 armii, z jedną wyróżnioną, gdzie znajduje się dowódca. Z uwagi na znaczne siły wroga, tylko równoczesny atak wszystkich armii może doprowadzid wojska czerwone do zwycięstwa nad wojskiem żółtym. Dowódca w pewnym momencie wydaje rozkaz do ataku i przesyła go do armii A i B. Armia B po otrzymaniu komunikatu ma za zadanie przesład go dalej do armii C i D. Wszystko działa bardzo dobrze, o ile nie założymy, że armia B zdradzi i prześle do armii C i D rozkaz o odwrocie (symulacja awarii procesu). Wówczas wojsku naszego dowódcy grozi zagłada. Czy awaria jednego z procesów zawsze będzie w stanie zaszkodzid ogólnemu celowi przetwarzania rozproszonego? Jeśli spośród jest , to: procesów poprawnych jest co najmniej dwukrotnie więcej niż uszkodzonych, a tych Można rozwiązad uzgadnianie bizantyjskie w rundach rozgłaszania decyzji (duża złożonośd komunikacyjna) Można rozwiązad szybciej, pod warunkiem, że wykorzystamy do podpisywania przekazywanych rozkazów kryptograficzną pieczęd nadawcy. Załóżmy, że każdy z procesów-generałów posiada tablicę , której elementy wskazują na ilośd żołnierzy generała -tego. I tak, początkowo, każdy z generałów posiada jedną wartośd w tej tablicy, a mianowicie, ilośd żołnierzy własnej armii. Następnie każdy z procesów wysyła do wszystkich pozostałych procesów ilośd żołnierzy w jego armii. Generał C, który symuluje zdrajcę przesyła do innych armii różne wartości (co się stanie jeśli ?). Następnie, gdy każdy z procesów dostanie wszystkie komunikaty, następuje wymiana całych tablic pomiędzy każdą parą procesów. Proces z awarią (tzn. proces C) prześle natomiast zupełnie różne tablice do pozostałych. Zakładając, że mamy procesów, ostatecznie każdy z nich będzie posiadał tablic z różnymi wartościami. Jeżeli jest więcej niż procesów poprawnych, to dany proces -ty będzie posiadał na pozycji -tej wartości w tablicach, z których większośd będzie wskazywała na wartośd rzeczywistą. Dodatkowo, każdy z poprawnych procesów będzie wiedział, który z pozostałych jest błędny, ponieważ każda z wartości w otrzymanych tablicach na pozycji C będzie inna. Wykład #2: Przetwarzanie rozproszone Plan wykładu: a) b) c) d) e) f) g) h) Proces sekwencyjny Komunikaty, kanały komunikacyjne Stan kanału Operacje komunikacyjne Model formalny procesu sekwencyjnego Zdarzenia Warunek uaktywnienia Modele żądao Procesy rozproszone i sekwencyjne Proces rozproszony- definicja Procesem rozproszonym nazywamy współbieżne i skoordynowane (ang. concurrent and coordinated) wykonanie w środowisku przetwarzania rozproszonego zbioru procesów sekwencyjnych współdziałających w realizacji wspólnego celu przetwarzania. Proces sekwencyjny Nieformalnie, każdy proces sekwencyjny jest działaniem wynikającym z wykonywania w pewnym środowisku (kontekście) programu sekwencyjnego (algorytmu sekwencyjnego), który składa się z ciągu operacji (instrukcji, wyrażeo) atomowych (nieprzerywalnych). Klasy operacji Wyróżnia się dwie podstawowe klasy operacji: a) Wewnętrzne (ang. internal)- odnoszą się tylko do zmiennych lokalnych programu b) Komunikacyjne (ang. communication)- odnoszą się do środowiska i dotyczą komunikatów (ang. messages) oraz kanałów (ang. channels) Komunikat- definicja Komunikat (wiadomośd) jest dynamiczną strukturą danych: w której: oznacza identyfikator typu wiadomości oznacza identyfikator wiadomości oznacza identyfikator procesu nadawcy (ang. sender) oznacza identyfikator procesu odbiorcy (ang. receiver) oznacza dane do przesłania Kanał- definicja Kanał jest obiektem (zmienną) skojarzonym z uporządkowaną parą procesów , modelującym jednokierunkowe łączę transmisyjne. Typem tego obiektu jest zbiór wiadomości, którego rozmiar nazywany jest pojemnością kanału. Kanały incydentny, wejściowe i wyjściowe Kanał skojarzony z parą procesów , oznaczamy przez oraz nazywamy kanałem incydentnym z procesem i z procesem . Ponadto, kanał nazywamy kanałem wyjściowym procesu oraz kanałem wejściowym procesu . Zbiór kanałów wejściowych i wyjściowych danego procesu oznaczamy odpowiednio przez . Zbiór wszystkich kanałów incydentnych procesu oznaczymy przez (oczywiście ) Zbiór sąsiednich procesów wejściowych procesu : Zbiór sąsiednich procesów wyjściowych procesu : oraz Stan kanału Przez stan kanału rozumied będziemy zbiór, lub uporządkowany zbiór, wiadomości wysłanych przez proces , lecz jeszcze nieodebranych przez proces . Modelowanie opóźnienia w kanale W celu modelowania w kanale opóźnieo komunikacyjnych, w zbiorze wiadomości dwa rozłączne podzbiory: zbiór wiadomości transmitowanych zbiór wiadomości dostępnych Oczywiście, w każdej chwili (ang. in-transit) (ang. available, arrived, ready) . wyróżnia się Predykaty opisujące stan kanału Brak wiadomości gotowych do odebrania i brak wiadomości aktualnie wysyłanych kanałem . Istnieją wiadomości aktualnie wysyłane kanałem . Istnieją wiadomości gotowe do odebrania z kanału . Operacje komunikacyjne Operacje komunikacyjne indywidualne Efektem wykonania tej operacji jest umieszczenie wiadomości wykonanie podstawienia w kanale , a więc Jeżeli kanał nie jest pusty (predykat ma wartośd wiadomośd jest bezpośrednio dostępna ( efektem wykonania tej operacji jest pobranie wiadomości wykonanie podstawienia ma wartośd z kanału ) i pewna ), to , a więc Operacje komunikacyjne grupowe Efektem wykonania tej operacji jest umieszczenie wiadomości we wszystkich kanałach takich, że , a więc wykonanie podstawienia dla wszystkich tych kanałów Efektem wykonania tej operacji jest atomowe pobranie wiadomości od procesów i umieszczenie ich w . Tym samym, dla każdego procesu , wykonywane jest kolejno podstawienie oraz Rodzaje komunikacji Kanały o niezerowej pojemności umożliwiają realizację operacji następujących typów komunikacji: Nieblokowanej Blokowanej Komunikacja synchroniczna W komunikacji synchronicznej, nadawca i odbiorca są blokowani aż odpowiedni odbiorca odczyta przesłaną do niego wiadomośd (ang. rendez-vous). Komunikacja asynchroniczna W przypadku komunikacji asynchronicznej, nadawca lub odbiorca komunikuje się w sposób nieblokowany. Model formalny procesu sekwencyjnego Formalnie, proces sekwencyjny może byd opisany (modelowany) przez uporządkowaną czwórkę: gdzie jest zbiorem stanów procesu jest zbiorem stanów początkowych, jest zbiorem zdarzeo procesu jest funkcją tranzycji taką, że: Jeżeli zajście zdarzenia ,a w stanie jest możliwe i prowadzi do zmiany stanu na . Stan procesu Stan procesu w chwili czasu lokalnego jest w ogólności zbiorem wartości wszystkich zmiennych lokalnych skojarzonych z procesem w chwili oraz ciągów wiadomości wysłanych (wpisanych) do incydentnych kanałów wyjściowych i ciągów wiadomości odebranych z incydentnych kanałów wejściowych do chwili . Dla każdego , . W celu uproszczenia notacji, zależnośd stanu od czasu można przyjąd za domyślną i jeśli nie prowadzi to do niejednoznaczności, oznaczad będziemy stan w pewnej chwili przez . Zbiór jest zbiorem stanów początkowych, których wartości są zadawane wstępnie, bądź są wynikiem zajścia wyróżnionego zdarzenia inicjującego . Zdarzenia Zdarzenie odpowiada unikalnemu wykonaniu operacji atomowej, zmieniającemu stan ewentualnie stan incydentnych z procesem kanałów lub . procesu i Jeżeli operacja odpowiadająca zdarzeniu została wykonana, to powiemy, że zdarzenie zaszło. Klasy zdarzeń Zachodzi w procesie , w wyniku wykonania przez ten proces operacji Zachodzi w procesie , w wyniku wykonania przez ten proces operacji Zachodzi w procesie , gdy wykonał operację zmiennej lokalnej wiadomośd pochodziła od procesu , a odczytana do Zachodzi w procesie , a odczytane do zmiennej lokalnej , gdy wykonał operację wiadomości pochodzą od procesów ( ) Zachodzi, gdy proces wykonał operację, która nie zmienia stanu jego kanałów incydentnych. Do zdarzeo lokalnych zalicza się m.in. zdarzenia: o Nadanie procesowi stan (w szczególności stan początkowy) o Zakooczenie wykonywania procesu Dostępnośd wiadomości utożsamiad można z zajściem zdarzeo w środowisku komunikacyjnym: Zdarzenie dostarczenia wiadomości Zdarzenie nadejścia wiadomości Przez oznaczad będziemy zbiór procesów, których wiadomości dotarły i są dostępne dla Funkcja tranzycji Funkcja tranzycji opisuje reguły zmiany stanu na . w wyniku zajścia zdarzenia . Elementy nazwiemy tranzycjami lub krokami. W zależności od zachodzącego zdarzenia , tranzycję nazwiemy odpowiednio tranzycją wejścia, wyjścia lub lokalną. Zdarzenia dopuszczalne Funkcja tranzycji dopuszcza możliwośd zajścia zdarzenia tylko w tych stanach , dla których . Dlatego też, w wypadku gdy , powiemy, że zdarzenie jest dopuszczalne (ang. allowed) w stanie . Wprowadzimy też predykat dopuszczalne. oznaczający, że w danej chwili zdarzenie jest Zdarzenia gotowe Oprócz czynnika wewnętrznego (stanu procesu), zajście zdarzenia może byd dodatkowo uwarunkowane stanem kanałów wejściowych (środowiska). Jeśli zdarzenie może zajśd ze względu na warunki zewnętrzne (stan kanałów), to powiemy, że zdarzenie jest przygotowane lub gotowe (ang. ready). Fakt gotowości zdarzenia Predykat w danej chwili wyrażad będzie predykat . oznacza, że zdarzenie jest aktywne, czyli jednocześnie gotowe i dopuszczalne. Procesy zakończone, wstrzymane Powiemy, że proces jest w stanie koocowym jest pusty. , jeżeli zbiór zdarzeo dopuszczalnych w tym stanie Jeżeli natomiast niepusty zbiór zdarzeo dopuszczalnych zawiera wyłącznie zdarzenia odbioru i żadne z tych zdarzeo nie jest aktywne (gotowe), to powiemy, że proces jest blokowany (zablokowany). Procesy aktywne, pasywne Proces wstrzymany lub zakooczony nazwiemy pasywnym. Przez proces aktywny będziemy natomiast rozumied proces, który nie jest pasywny. Przyjmujemy, że w każdej chwili przyjmująca wartośd stan procesu reprezentuje zmienna logiczna , , gdy proces jest pasywny , gdy proces jest aktywny Proces aktywny ( ) może wysyład i odbierad wiadomości, wykonywad tranzycje lokalne, a więc potencjalnie może również spontanicznie (w dowolnej chwili) zmienid swój stan na pasywny. W stanie pasywnym procesu ( ) dopuszczalne są natomiast co najwyżej zdarzenia odbioru. Zmiana stanu procesu z pasywnego na aktywny uwarunkowana jest osiągnięciem gotowości przez chodby jedno z dopuszczalnych zdarzeo odbioru, czyli spełnieniem tak zwanego warunku uaktywnienia (ang. activation condition). Warunek ten procesu związany jest ze zbiorem warunkującym , zbiorem oraz predykatem . Zbiór warunkujący (ang. dependent set) jest sumą mnogościową zbiorów odbioru dopuszczalnych w danej chwili. Predykat activate Predykat 1. Jeżeli 2. Jeżeli 3. Jeżeli wszystkich zdarzeo zdefiniowany jest w sposób następujący: , to , to i , to: Gdzie oznacza, że pasywny proces skooczony, chod nieprzewidywalnym czasie. Predykat ready Warunek uaktywnienia procesu formalnie wyraża predykat zmieni swój stan na aktywny w Gdy proces jest uaktywniany, to wiadomości, których dostarczanie doprowadziło do spełnienia warunku uaktywnienia, są atomowo pobierane z buforów wejściowych i dalej przetwarzane. Modele żądań 1. 2. 3. 4. 5. 6. 7. Model jednostkowy Model AND Model OR Podstawowy model spośród Model OR-AND Dysjunkcyjny model spośród Model predykatowy Model jednostkowy W modelu jednostkowym warunkiem uaktywnienia pasywnego procesu jest przybycie wiadomości od jednego, ściśle określonego nadawcy. W tym przypadku , dla każdego naturalnego , . Model ten odpowiada szerokiej klasie systemów, w których procesy żądają kolejno po jednym tylko zasobie. Model AND W modelu AND proces pasywny staje się aktywnym, jeżeli dotarły wiadomości od wszystkich procesów tworzących zbiór warunkujący. Model ten nazywany jest również modelem zasobowym. Model OR W modelu OR do uaktywnienia procesu wystarczy jedna wiadomośd od któregokolwiek z procesów ze zbioru warunkującego. Model ten nazywany jest również modelem komunikacyjnym. Podstawowy model spośród W podstawowym modelu spośród z pasywnym procesem , liczba naturalna , , oraz liczba . skojarzony jest zbiór warunkujący W modelu tym proces staje się aktywny tylko wówczas, gdy uzyska wiadomości od co najmniej różnych procesów ze zbioru warunkującego . Model OR-AND W modelu OR-AND zbiór warunkujący pasywnego procesu , gdzie dla każdego naturalnego , , . jest zdefiniowany jako Proces staje się aktywny po otrzymaniu wiadomości od każdego z procesów tworzących zbiór od każdego z procesów tworzących zbiór lub … lub od każdego z procesów tworzących zbiór lub . Dysjunkcyjny model spośród W modelu dysjunkcyjnym spośród z każdym pasywnym procesem skojarzony jest zbiór warunkujący , liczby naturalne , , …, oraz liczby naturalne , , …, , gdzie dla każdego naturalnego , , , Proces staje się aktywny po otrzymaniu wiadomości od wiadomości od różnych procesów ze zbioru lub … lub zbioru . różnych procesów ze zbioru lub wiadomości od różnych procesów ze . Model dysjunkcyjny spośród redukuje się do: Modelu OR-AND, gdy dla każdego Modelu podstawowego spośród , gdy Modelu AND, gdy i Modelu OR, gdy i Model predykatowy W modelu predykatowy, dla każdego pasywnego procesu jest predykat , gdzie . Jak łatwo zauważyd, stosownie definiując predykat wszystkie wcześniej omówione modele żądao. ze zbiorem warunkującym określony można oczywiście uzyskad Wykład #3: Proces rozproszony Plan wykładu: a) b) c) d) e) f) g) h) i) Proces rozproszony Wykonanie procesu, historia procesu Stan osiągalny Relacja poprzedzania zdarzeo Diagramy przestrzenno-czasowe Niedeterminizm przetwarzania Graf stanów osiągalnych Monitory Konwencja zapisu algorytmów Proces rozproszony Proces rozproszony będący współbieżnym wykonaniem zbioru sekwencyjnych , opisuje uporządkowana czwórka procesów gdzie - jest zbiorem stanów globalnych procesu rozproszonego, - jest zbiorem stanów początkowych, - jest zbiorem zdarzeo, - jest funkcją tranzycji taką, że Zbiór stanów globalnych Zbiór stanów globalnych jest podzbiorem iloczynu kartezjaoskiego stanów lokalnych procesów składowych przetwarzania rozproszonego. zbiorów Stan globalny procesu rozproszonego w chwili czasu globalnego1 oznaczony przez , jest więc uporządkowanym zbiorem stanów lokalnych wszystkich procesów składowych w chwili : Zbiór stanów globalnych początkowych Zbiór globalnych stanów początkowych jest podzbiorem iloczynu kartezjaoskiego zbiorów stanów początkowych procesów składowych. Zbiór zdarzeń globalnych Zbiór zdarzeo globalnych jest sumą mnogościową składowych 1 Czas postrzegany przez teoretycznego zewnętrznego obserwatora zbiorów zdarzeo procesów Globalna funkcja tranzycji Globalna funkcja tranzycji jest złożeniem funkcji tranzycji procesów składowych, a więc jest zbiorem trójek , dla których istnieje takie , , że Częściowe wykonanie procesu Częściowe wykonanie procesu rozproszonego utożsamia się z ciągiem , , , zdarzeo takim, że dla każdego , , …, , procesu , składającym się naprzemiennie ze stanów i , Przez wykonanie (realizację) procesu rozpoczynające się stanem początkowym Stan osiągalny Powiemy, że stan , rozumied będziemy natomiast częściowe wykonanie jest osiągalny ze stanu , co oznaczymy przez jeżeli istnieje częściowe wykonanie . , , , , …, , , procesu takie, że ,a Globalny stan osiągalny Oznaczmy przez zbiór wszystkich możliwych wykonao (realizacji) procesu . Jeżeli istnieje wykonanie procesu takie, że jest stanem koocowym, to stan ten nazwiemy globalnym stanem osiągalnym (spójnym) procesu rozproszonego (ang. reachable, consistent). Historia wykonania Każdemu wykonaniu procesu , odpowiada pewien ciąg stanów , , …, , nazywany śladem wykonania (realizacji) procesu , a także ciąg zdarzeo , , …, , nazywany historią wykonania (realizacji) procesu. Historię , , …, oznaczamy przez , a zbiór historii- przez . Proces rozproszony jako graf Proces rozproszony jest często przedstawiany jako graf w którym: Wierzchołki grafu rozproszonego reprezentują procesy składowe przetwarzania Krawędzie grafu , , grafu niezorientowanego lub łuki grafu zorientowanego, reprezentują kanały odpowiednio dwu- lub jednokierunkowe. Graf nazywany jest grafem procesu rozproszonego lub topologią przetwarzania (topologią procesu rozproszonego). Relacja poprzedzania zdarzeń Oznaczmy przez relację poprzedzania (ang. happen before, causal precedence, happened before) zdefiniowaną na zbiorze w następujący sposób: Relacja poprzedzania lokalnego Przez oznaczamy relację poprzedzania lokalnego zdarzeo procesu taką, że wtedy i tylko wtedy, gdy oraz (lub gdy oraz ) Zdarzenia przyczynowo-zależne Zdarzenia i nazywamy przyczynowo-zależnymi, jeżeli W przeciwnym razie zdarzenia te nazwiemy przyczynowo-niezależnymi lub współbieżnymi (ang. concurrent, causally independent), co będziemy oznaczad przez . Diagramy przestrzenno-czasowe Realizację przetwarzania rozproszonego można przedstawid graficznie w postaci diagramu przestrzenno-czasowego (ang. space-time diagram), w którym osie reprezentują upływ czasu globalnego, a punkty na osiach- zdarzenia. Przez analogię do relacji na zbiorze zdarzeo, można zdefiniowad częściowy porządek na zbiorze stanów wszystkich procesów w sposób następujący: Relacja powyższa oznacza, że stan jednego procesu poprzedza przyczynowo stan innego, wtedy i tylko wtedy, gdy zdarzenie rozpoczynające drugi stan zależy przyczynowo bądź jest tożsame ze zdarzeniem kooczącym pierwszy stan. Stany lokalne, dla których nie zachodzi ani relacja ani też relacja , nazywamy współbieżnymi. Graf stanów osiągalnych Zbiór częściowo uporządkowany może byd przedstawiony w postaci grafu zorientowanego, w którym wierzchołki odpowiadają stanom , a łuki oznaczają istnienie zdarzenia dopuszczalnego takiego, że Graf taki, będziemy nazywad grafem stanów osiągalnych przetwarzania rozproszonego lub siatką obliczeo rozproszonych. Przykład: Niedeterminizm przetwarzania W kontekście grafu stanów osiągalnych przetwarzania rozproszonego, każda realizacja przetwarzania rozproszonego jest pewną ścieżką w tym grafie. Istnienie wielu różnych ścieżek ilustruje niedeterminizm przetwarzania rozproszonego, oznaczający, że dla danego stanu może istnied wiele stanów następnych. Lokalne zdarzenie procesu jest niedeterministyczne, gdy jego zajście może byd zastąpione przez zajście innego zdarzenia i wybór ten nie jest przewidywalny. Jeżeli przykładowo sekwencyjne wykonanie procesu może byd w każdej chwili zmienione w wyniku zajścia przerwania zewnętrznego, to wszystkie zdarzenia tego procesu są niezdeterminowane. Przetwarzanie nazywamy zdeterminowanym jeżeli wszystkie zdarzenia są zdeterminowane. W przeciwnym wypadku, przetwarzanie nazywamy niedeterministycznym. Przetwarzanie quasi-deterministyczne W ramach niedeterministycznego przetwarzania rozproszonego wyróżnia się podklasę przetwarzania quasi-deterministycznego (ang. quasi-deterministic, piece-wice deterministic, event-driven), w której niedeterminizm jest wyłącznie konsekwencją niedeterminizm operacji odbioru. Diagramy równoważne Należy zauważyd, że w ogólności istnieje wiele różnych diagramów przestrzenno-czasowych, którym odpowiada taki sam zbiór częściowo uporządkowany . Diagramy takie nazywamy diagramami równoważnymi. Przykład diagramów równoważnych: Monitor Ocena wartości predykatów globalnych wymaga w pierwszej kolejności obserwacji (monitorowania) stanów lokalnych procesów składowych. W tym celu przyjmiemy, że z każdym procesem skojarzony jest proces monitora . Cechy monitora Monitor może odczytywad (obserwowad) zmienne lokalne procesu Monitor może obserwowad i kontrolowad zdarzenia komunikacyjne Monitor nie ma natomiast możliwości zmiany stanu procesu przez przypisanie jego zmiennym lokalnym nowych wartości Konwencja zapisu algorytmów Typy komunikatów: Aplikacyjne Kontrolne Sygnały Pakiety Wspólne atrybuty: Identyfikator typu komunikatu Identyfikator komunikatu Identyfikator nadawcy Identyfikator odbiorcy Typ FRAME Typ MESSAGE Struktura komunikatów aplikacyjnych, nazwana MESSAGE, jest wywiedziona ze struktury FRAME, a jej precyzyjna definicja zawarta jest w programie aplikacji rozproszonej i nie jest istotna z punktu widzenia prezentowanych dalej algorytmów. Przyjmiemy zatem tylko, że szkielet definicji struktury MESSAGE ma poniższą postad: Typ CONTROL Typ SIGNAL Typ PACKET Wykład #4: Czas wirtualny, złożoność algorytmów Plan wykładu: a) Zegary logiczne: Skalarne Wektorowe b) Kanały: FIFO Typu FC c) Rząd funkcji, funkcja kosztu d) Złożonośd komunikacyjna i czasowa algorytmu e) Warunki poprawności algorytmu Czas wirtualny Zegary realizowane w systemach asynchronicznych mają stanowid aproksymację czasu rzeczywistego. Aproksymacja taka uwzględnia jedynie zachodzące w systemie zdarzenia i dlatego czas ten nazywany jest czasem wirtualnym (logicznym). W odróżnieniu od czasu rzeczywistego upływ czasu wirtualnego nie jest więc autonomiczny, a zależy od występujących w systemie zdarzeo i stąd określone wartości czasu wirtualnego mogą nigdy nie wystąpid. Czas wirtualny wyznacza się za pomocą zegarów logicznych (ang. logical clocks). Zegar logiczny- definicja Zegar logiczny systemu rozproszonego jest funkcją zbiór uporządkowany taką, że: gdzie jest relacją porządku na zbiorze , odwzorowującą zbiór zdarzeo w . Należy zauważyd, że w ogólności relacja odwrotna nie musi byd spełniona, tzn. . Ogólnie mówiąc, zegarem logicznym systemu rozproszonego nazywamy pewien abstrakcyjny mechanizm, który każdemu zdarzeniu przyporządkowuje pewną wartośd określaną czasem wirtualnym. Zegary logiczne- właściwości a) Jeśli zdarzenie zachodzi przed w tym samym procesie, to wówczas wartośd zegara logicznego odpowiadającego zdarzeniu jest mniejsza od wartości zegara logicznego odpowiadającego zdarzeniu . b) W przypadku przesyłania wiadomości , czas logiczny przyporządkowany zdarzeniu nadania wiadomości jest zawsze mniejszy niż czas logiczny przyporządkowany zdarzeniu odbioru tej wiadomości. Zegar skalarny- definicja Jeżeli przeciwdziedzina funkcji zegara logicznego jest zbiorem liczb naturalnych rzeczywistych , to zegar ten nazywany jest zegarem skalarnym. Realizacja zegarów skalarnych Funkcja implementowana jest przez zmienne naturalne procesami (monitorami ). Wartośd zmiennej reprezentuje w każdej chwili wartośd funkcji ostatniego zdarzenia , jakie zaszło w procesie logicznego w tym procesie. , lub , skojarzone z , odnoszącą się do , a tym samym reprezentuje upływ czasu Algorytm Lamporta Algorytm umożliwia synchronizację zegarów systemowych w sieci rozproszonej. Lamport wykazał, że synchronizacja zegarów nie musi byd absolutna, tzn. do poprawnego działania algorytm nie wymaga zegarów odmierzających czas fizyczny (wystarczające są zegary logiczne, mierzące czas wirtualny). Idea algorytmu Lamporta polega na dokonywaniu korekty czasu procesu odbierającego komunikat zgodnie z relacją poprzedzania zdarzeo (patrz: Wykład 3: Relacja poprzedzania zdarzeo). Proces, odbierający komunikat, sprawdza czas nadania tego komunikatu i porównuje ze swoim czasem odbioru. Jeśli czas odbioru jest późniejszy, dokonywana jest korekta, jeśli natomiast czas odbioru jest wcześniejszy od czasu nadania, to proces odbierający koryguje swój czas tak, żeby czas odbioru był o jeden impuls późniejszy względem czasu nadania (poprzez dodanie odpowiedniej ilości impulsów). Głównym założeniem tego algorytmu jest fakt, że nie jest ważny czas absolutny, a jedynie następstwo zdarzeo poszczególnych procesów. Zatem nie jest ważnym z punktu widzenia pojedynczego procesu czas systemowy. type PACKET extends FRAME is record of : INTEGER : MESSAGE end record : MESSAGE : PACKET : INTEGER : INTEGER 1 2 3 4 5 6 7 8 9 10 when do end when when do 11 12 13 14 15 16 end when when do end when Przykład synchronizacji zegarów logicznych Relacja między zbiorem zdarzeo i zbiorem wartości zegara skalarnego: Zegar wektorowy- definicja Zegarem wektorowym jest zegar logiczny, dla którego przeciwdziedzina funkcji (w przypadku zegarów wektorowych dla odróżnienia funkcję oznacza się przez ) jest zbiorem -elementowych wektorów liczb naturalnych lub rzeczywistych. Realizacja zegarów wektorowych Funkcja implementowana jest przez zmienne tablicowe , , skojarzone z poszczególnymi procesami. Zmienna jest tablicą liczb naturalnych, odpowiadającą pewnej aproksymacji czasu globalnego z perspektywy procesu . W efekcie aktualna wartośd tablicy odpowiada w każdej chwili wartości funkcji odnoszącej się do ostatniego zdarzenia, jakie zaszło w procesie . Algorytm Matterna type PACKET extends FRAME is record of : array of INTEGER : MESSAGE end record : MESSAGE : PACKET : array : INTEGER : INTEGER 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 of INTEGER when do end when when for all do do end for end when when end when do Twierdzenie 1 W każdej chwili czasu rzeczywistego gdzie zmienna reprezentuje skalarny czas lokalny procesu , a zmienna , aktualne wyobrażenie procesu o bieżącym skalarnym czasie lokalnym procesu , . Relacje na etykietach wektorowych Twierdzenie 2 Niech oraz będą wartościami zegarów wektorowych zdarzeo i . Wówczas Kanały Kanały FIFO Kanały gwarantujące porządek odbioru wiadomości zgodny z kolejnością wysyłania będziemy nazywad kanałami FIFO (ang. First-In-First-Out). Algorytm Müllender’a type PACKET extends FRAME is record of : INTEGER : MESSAGE end record : MESSAGE : PACKET : array of set of PACKET : array : array : BOOLEAN 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 of INTEGER of INTEGER when do end when when if then do else end if while for all if do do then end if end for end while end when Cechy kanałów FIFO są pewnym mechanizmem synchronizacji wymaganym przez wiele aplikacji ułatwiają znalezienie rozwiązania i konstrukcję algorytmów rozproszonych dla wielu problemów ograniczają, w porównaniu z kanałami nonFIFO, współbieżnośd komunikacji, a tym samym efektywnośd przetwarzania Kanały typu FC Kanały typu FC (ang. Flush Channels) łączą zalety kanałów FIFO i nonFIFO (pewien stopieo synchronizacji i współbieżnej komunikacji). Mechanizmy (operacje) komunikacji zdarzenia Wiadomości (ang. two-way-flush send) (ang. forward-flush send) (ang. backward-flush send) (ang. ordinary send) Wyprzedzanie wiadomości Powiemy, że wiadomośd wyprzedza wiadomośd w kanale , jeżeli wiadomośd wysłana przez wcześniej niż , lecz proces najpierw odebrał wiadomośd . została Wiadomośd typu TF (ang. two-way-flush send); operacja Wiadomośd typu FF (ang. forward-flush send); operacja Wiadomośd typu BF (ang. backward-flush send); operacja Wiadomośd operacja typu OF (ang. ordinary send); Łatwo zauważyd, że najmniejszą swobodę w komunikacji i w efekcie najmniejszy poziom współbieżności, oferuje operacja , a największą swobodę- operacja . Pierwsza z nich modeluje w istocie kanały FIFO, a ostatnia- kanały nonFIFO. Implementacja kanałów FC Kanały typu FC mogą byd implementowane z użyciem różnych mechanizmów: selektywnego rozgłaszania liczników potwierdzeo … Relacja binarna poprzedzania - stan kanału - binarna relacja poprzedzania typu F, zdefiniowana na zbiorze Jeżeli zachodzi predykat: : to mówimy, że bezpośrednio poprzedza i fakt ten oznaczamy przez , czyli Konstrukcja relacji poprzedzania W celu implementacji kanałów FC należy rozwiązad problem efektywnego wyznaczenia relacji przekazywania istotnych jej elementów do monitora odbiorcy. Mechanizm sukcesywnej konstrukcji relacji wysyłaniu kolejnych wiadomości. Niech poprzez stosowne uaktualnienie relacji przy oznacza ostatnią wiadomośd typu TF lub BF wysłaną kanałem Jeżeli jest typu OF i , to Jeżeli jest typu BF i , to Następnie i : . Jeżeli jest typu FF, to dla wszystkich takich, że nie ma następnika w , Jeżeli jest typu TF, to dla wszystkich takich, że nie ma następnika w , Następnie Przekazywanie informacji o relacji poprzedzania W tym celu można zaproponowad przesyłanie wiadomości aplikacyjnych w pakietach, zawierających dodatkowo: Typ wiadomości (OF, BF, FF, TF) Numer sekwencyjny wiadomości ( ) Numer sekwencyjny wiadomości bezpośrednio poprzedzającej Algorytm Kearnsa, Campa i Ahuja type PACKET extends FRAME is record of : enum(OF, BF, FF, TF) : INTEGER : INTEGER : MESSAGE end record : MESSAGE : PACKET : array : array : array : array : BOOLEAN : INTEGER 1 2 3 procedure do if 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 of set of PACKET of INTEGER of INTEGER of set of INTEGER then if then end if else /* if */ then end if end if end procedure when do end when when do end when when do 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 end when when do end when when do if then else end if while do for all if end if end for end while end when do then Środowisko zachowujące uporządkowanie przyczynowe Algorytm Birmana, Schipera i Stephensona type PACKET extends FRAME is record of : array of INTEGER : MESSAGE end record : MESSAGE : PACKET : array : INTEGER 1 2 3 4 5 6 7 8 when of INTEGER do end when when do 9 wait until 10 11 12 13 14 15 16 17 if then end if for all do end for end when Algorytm Schipera, Egli, Sandoza type PACKET extends FRAME is record of : array of INTEGER : set of record of : PROCESS_ID : array of INTEGER end record : MESSAGE end record 1 2 3 4 5 6 7 8 9 10 11 : MESSAGE : PACKET : array of INTEGER : set of record of : PROCESS_ID : array of INTEGER end record : BOOLEAN : set of PACKET : set of PACKET : array of INTEGER procedure TryToDeliver( : PACKET) do if then else end if if for all if then do then 12 13 else 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 for do for all do end for end for end if end for for all do end for end if end procedure when do for do end for end when when do while for all end for end while end when do do Funkcje kosztu Oznaczenia zbiór wszystkich poprawnych danych wejściowych koszt wykonywania algorytmu rozmiar danych wejściowych , jest zadaną funkcją. W praktyce, zamiast kosztu . algorytmu dla danych , gdzie i (rozmiar zadania) taki, że , gdzie stosuje się zwykle jego oszacowanie w funkcji rozmiaru zadania Definicja Funkcją kosztu wykonania algorytmu nazywad będziemy odwzorowanie gdzie jest zbiorem wszystkich poprawnych danych wejściowych o rozmiarze algorytmu . Najczęściej stosowane jest odwzorowanie pesymistyczne (najgorszego przypadku), zdefiniowane w następujący sposób: Rząd funkcji Niech i będą dowolnymi funkcjami odwzorowującymi w . Mówimy, że funkcja jest co najwyżej rzędu funkcji , co zapisujemy: istnieje stała rzeczywista oraz takie, że dla każdej wartości zachodzi: Mówimy, że funkcja jest dokładnie rzędu funkcji , co zapisujemy: Mówimy, że funkcja jest co najmniej rzędu funkcji , co zapisujemy: jeżeli , jeżeli jeżeli Złożoność czasowa W wypadku algorytmów rozproszonych, złożonośd czasowa jest funkcją kosztu wykonania, wyrażoną przez liczbę kroków algorytmu do jego zakooczenia przy założeniu, że: Czas wykonywania każdego kroku (operacji) jest stały Kroki wykonywane są synchronicznie Czas transmisji wiadomości jest stały W analizie złożoności czasowej algorytmów rozproszonych przyjmuje się też na ogół, że: Czas przetwarzania lokalnego (wykonania każdego kroku) jest pomijalny (zerowy) Czas transmisji jest jednostkowy Złożoność komunikacyjna Złożonośd komunikacyjna jest funkcją kosztu wykonania algorytmu wyrażaną przez: Liczbę pakietów (wiadomości) przesyłanych w trakcie wykonywania algorytmu do jego zakooczenia Sumaryczną długośd (w bitach) wszystkich wiadomości przesłanych w trakcie wykonywania algorytmu W konsekwencji wyróżniamy złożonośd pakietową i bitową. Przykład #1- Bariera a) b) c) d) Topologia połączeo- graf w pełni połączony Koordynator rozgłasza komunikat początku bariery ( komunikatów) Wszyscy uczestnicy odbierają komunikat i odsyłają potwierdzenia ( komunikatów) Po otrzymaniu potwierdzeo od wszystkich procesów, koordynator rozsyła komunikat kooca bariery ( komunikatów). Razem mamy komunikatów. Przykład #2- Bariera a) Topologia połączeo- pierścieo logiczny b) Koordynator wysyła komunikat początku bariery c) Wszyscy uczestnicy odbierają komunikat i przesyłają go dalej (komunikaty płyną wzdłuż pierścienia przez wszystkie procesy, aż komunikat początku bariery wróci do koordynatora, zatem mamy komunikatów) d) Po otrzymaniu komunikatu rozpoczynającego operację bariery, koordynator przesyła komunikat kooca bariery (sytuacja podobna co przy przesłaniu komunikatu o rozpoczęciu bariery, zatem również komunikatów). Razem mamy komunikatów. Warunki poprawności Analizę poprawności algorytmu rozproszonego (procesu rozproszonego) dekomponuje się zwykle na analizę jego bezpieczeostwa i żywotności. Właściwośd bezpieczeostwa (ang. safety, consistency) Własnośd ta wyraża, jakie operacje proces rozproszony może wykonad, a jakie są mu zabronione. Przykładami są tutaj: Wzajemne wykluczanie (ang. mutual exclusion)- nie więcej niż jeden proces może korzystad w danym momencie z sekcji krytycznej Brak zakleszczenia- żaden proces nie jest kiedykolwiek opóźniany przez oczekiwanie na zdarzenie, które nigdy nie nastąpi Częściowa poprawnośd (ang. partial correctness)- jeśli algorytm zakooczy się, rezultat jego działania jest taki, jaki był wymagany Własnośd bezpieczeostwa jest przedstawiana jako niezmiennik przetwarzania, czyli warunek, który jest spełniony w każdym możliwym punkcie wykonania programu. Jest ona dowodzona przez wykorzystanie indukcji, co oznacza, że dowodzi się prawdziwości wyznacznika dla początkowego stanu procesu rozproszonego i dla każdej tranzycji pomiędzy kolejnymi stanami przetwarzania. Właściwośd żywotności (postępu) (ang. liveness, progress) Własnośd ta wyraża, co program musi zrobid, a także co się wydarzy w procesie rozproszonym, pod wpływem pewnego zdarzenia. Do przykładów należą: Zaufana komunikacja- wiadomośd, która została wysłana przez pewien proces, musi zostad odebrana Globalna poprawnośd- algorytm zakooczy się, a rezultat jego działania jest taki, jaki był wymagany Własnośd żywotności jest przedstawiana jako zbiór aksjomatów żywotności, a jej poprawnośd dowodzi się przez weryfikację tychże aksjomatów. Dowody własności bezpieczeostwa są często odseparowane od ich odpowiedników dla własności żywotności, natomiast dowody własności żywotności często opierają się na dowodach warunku bezpieczeostwa. Wykład #5, 6: Detekcja zakleszczenia Plan wykładu: a) b) c) d) e) f) Procesy aktywne i pasywne Definicja zakleszczenia Problem detekcji wystąpienia zakleszczenia Detekcja zakleszczenia dla modelu OR Detekcja zakleszczenia dla modelu AND Detekcja zakleszczenia w środowisku synchronicznym dla modelu spośród . Wprowadzenie Procesy tworzące przetwarzanie rozproszone komunikują się ze sobą za pomocą mechanizmu wymiany wiadomości, realizując wspólny cel przetwarzania. Jedne procesy wysyłają komunikaty zawierające żądania przydziału pewnych zasobów, inne- w odpowiedzi- przesyłają ewentualne komunikaty potwierdzające przydział żądanych zasobów. Nieformalna definicja problemu zakleszczenia W przetwarzaniu rozproszonym może w ogólności wystąpid sytuacja, w której wszystkie procesy pewnego niepustego zbioru procesów oczekują na wiadomości (potwierdzające na przykład przydział zasobów) od innych procesów tego właśnie zbioru. Stan taki nazywamy zakleszczeniem rozproszonym (ang. distributed deadlock). Mówimy też, że proces jest w stanie zakleszczenia, jeżeli oczekuje on na zdarzenie, które nigdy nie nastąpi. Zakleszczenie może mied miejsce w czasie komunikacji między procesami, ale również- przede wszystkim- jest związane z zarządzaniem zasobami. W tym kontekście istnieją cztery warunki dla powstania zakleszczenia: Procesy muszą żądad wyłącznego dostępu do pewnego zasobu Procesy muszą przetrzymywad pewne zasoby w czasie czekania na inne (zdobywanie zasobów jeden po drugim) Zasoby nie mogą byd usuwane z oczekujących procesów Istnieje pierścieo procesów, w którym każdy z nich przetrzymuje jeden lub więcej zasobów wymaganych przez następny proces w łaocuchu Techniki, umożliwiające unikanie lub odtwarzanie stanu sprzed zakleszczenia, polegają na uniemożliwieniu zaistnienia chodby jednego z powyższych warunków. Jedną z najlepiej udokumentowanych technik, służących powyższemu celowi, chod wielce niepraktyczna, jest algorytm bankiera autorstwa Dijkstry. Procesy aktywne i pasywne W każdej chwili proces może byd w jednym z dwóch stanów: aktywnym lub pasywnym. Proces aktywny może realizowad przetwarzanie, wykonując operacje odpowiadające zajściu zdarzeo wewnętrznych i komunikacyjnych. Aby stad się aktywnym, proces pasywny musi spełnid warunek uaktywnienia. Warunek uaktywnienia Warunek uaktywnienia jest wyrażony przez predykat Zakleszczenie Zakleszczenie- definicja Przez oznaczamy predykat stwierdzający, że w danej chwili , niepusty zbiór procesów jest zbiorem procesów zakleszczonych. Zakleszczenie w modelu jednostkowym Zakleszczenie w modelu AND Zakleszczenie w modelu OR Zakleszczenie w podstawowym modelu spośród Zakleszczenie w modelu OR-AND Zakleszczenie w modelu dysjunkcyjnym spośród Zakleszczenie w modelu predykatowym Przykłady zakleszczeń Każdy proces w grafie z łukiem wychodzącym jest pasywny Procesy bez łuków wychodzących są aktywne Zakładamy, że wszystkie kanały są puste Przykład- model jednostkowy Przykład- model AND Przykład- model OR Przykład- model spośród Klasyfikacja problemów detekcji zakleszczenia a) Problem detekcji wystąpienia zakleszczenia Czy istnieje w pewnej chwili zbiór , dla którego predykat jest prawdziwy? Odpowiedź na to pytanie określa wartośd predykatu: b) Problem detekcji zakleszczenia procesu Detekcja zakleszczenia procesu sprowadza się do sprawdzenia, czy prawdziwy jest predykat: c) Problem detekcji zakleszczenia zbioru procesów Detekcja zakleszczenia zbioru procesów polega na znalezieniu zbioru prawdziwy jest następujący predykat: , dla którego d) Problem detekcji maksymalnego zbioru procesów zakleszczonych Detekcja maksymalnego zbioru zakleszczonego sprowadza się do znalezienia takiego zbioru , dla którego spełniony jest poniższy warunek: gdzie Model aplikacyjnego przetwarzania rozproszonego Algorytm Chandy, Misra, Hass dla modelu AND type PROBE extends FRAME is record of : INTEGER end record 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 : PROBE : array of BOOLEAN : set of PROCESS_ID : array of BOOLEAN : INTEGER : INTEGER : BOOLEAN do when if then for all do end for end if end when when for all do do end for end when when do if then if then 21 22 23 24 25 26 27 28 29 30 else for all do end for end if end if end when Algorytmy detekcji zakleszczenia dla modelu OR Algorytm Chandy, Misra, Hass dla modelu OR Algorytm detekcji zakleszczenia dla modelu OR opiera się na przetwarzaniu dyfuzyjnym (ang. query computation). Twierdzenie 3 Jeżeli inicjator rozpoczyna detekcję w chwili, gdy jego proces aplikacyjny jest zakleszczony, to stwierdzi zakleszczenie procesu w skooczonym czasie (algorytm detekcji zakooczy się). Twierdzenie 4 Jeżeli inicjator deklaruje, że jego proces aplikacyjny jest zakleszczony, to pewnego zbioru procesów zakleszczonych w chwili zakooczenia algorytmu. Algorytm: type CONTROL extends FRAME is record of : INTEGER : INTEGER end record type QUERY extends CONTROL type REPLY extends CONTROL : QUERY : REPLY : set of PROCESS_ID : array of INTEGER : array of INTEGER : array of INTEGER : array of BOOLEAN : INTEGER należy do : INTEGER : BOOLEAN 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 when if do then for all do end for end if end when when if do then if then for all do end for else if then end if end if end if end when when if do then if then 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 if then if then else end if end if end if end if end when when for all do do end for end when W przypadku odebrania przez monitor wiadomości QUERY od monitora , monitor ten sprawdza, czy monitorowany przez niego proces jest pasywny. Jeśli warunek ten jest spełniony, to sprawdzany jest numer sekwencyjny zapytania QUERY. Jeśli jest on większy od największego otrzymanego dotychczas, to aktualizowane są odpowiednio zmienne , oraz . Następnie przygotowywany jest pakiet, zawierający informację o tym numerze sekwencyjnym i inicjatorze detekcji, który zostanie wysłany do wszystkich monitorów, których monitorowane procesy należą do zbioru warunkującego procesu. Po wysłaniu tej wiadomości zmiennej na pozycji odpowiadającej identyfikatorowi przypisywana jest wartośd równa liczbie procesów tworzących zbiór warunkujący. Jeśli natomiast wartośd odebranego w pakiecie numeru sekwencyjnego jest równa wartości zapamiętanej w tablicy i proces był cały czas pasywny od czasu zapisanie tej ostatniej wartości do tablicy, to przygotowuje on odpowiedź typu REPLY i wysyła ją do procesu (monitora związanego z procesem) . Zdarzenie odbioru wiadomości typu REPLY powoduje w przypadku, gdy proces jest pasywny porównanie numerów sekwencyjnych zapisanych w odebranej wiadomości i odpowiedniej tablicy . Jeśli okaże się, że wartości te są sobie równe, a ponadto proces aplikacyjny jest procesem pasywnym od czasu ostatniej aktualizacji porównywanego elementu tablicy , to dekrementowana jest wartośd na odpowiedniej pozycji zmiennej . Jeśli po zmniejszeniu wartośd tej zmiennej wynosi i monitor odbierający komunikat jest inicjatorem detekcji, to stwierdza on, że proces aplikacyjny, który monitoruje jest zakleszczony. Jeśli natomiast wartośd zmiennej po aktualizacji jest równa , czyli proces otrzymał już wszystkie odpowiedzi na zapytanie związanie z ostatnim procesem detekcji zainicjowanym przez proces (ale ), to wysyła on wiadomośd typu REPLY do procesu, od którego otrzymał wiadomośd typu QUERY, która to spowodowała aktualizację tablicy na pozycji odpowiadającej procesowi . Uaktywnienie procesu powoduje ustawienie elementów tablicy procesowi na . Algorytm Bracha, Toueg’a type NOTIFY extends SIGNAL type DONE extends SIGNAL type CONFIRM extends SIGNAL type ACK extends SIGNAL : DONE : NOTIFY : CONFIRM : ACK : set of record of : PROCESS_ID : PROCESS_ID end record : set of PROCESS_ID 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 procedure : set of PROCESS_ID : INTEGER : BOOLEAN : BOOLEAN : INTEGER : BOOLEAN do for all do end for if then end if for all do end for end procedure procedure for all end for do do odpowiadających 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 for all do end for end procedure when NOTIFY_PROC() if do then end if end when when do if then end if end when when if do then end if end when Dla ilustracji działania algorytmu rozważmy przykładowy stan globalny reprezentowany przez graf oczekiwanych potwierdzeo przedstawiony poniżej. Procesy należące do zbioru są pasywne i oczekują na wiadomości od innych procesów ze zbioru , zgodnie z grafem WFG. Dla prostoty prezentacji skojarzymy z każdym wierzchołkiem grafu WFG (procesem) dwa wektory reprezentujące stan algorytmu w danym wierzchołku. Pierwszy wektor, oznaczony przez (ang. process state), jest zmienną reprezentowaną przez tablicę dwóch liczb naturalnych. Wartośd zależy od wartości zmiennej i od liczby odebranych wiadomości typu DONE. Początkowo wartośd . Po nadaniu zmiennej wartości przez monitor , przyjmuje wartośd 1. Następnie, gdy zakooczy się zainicjowana ewentualnie faza potwierdzania i odebrana zostanie ostatnia wiadomośd DONE, wartośd . Podobnie wartośd zależy od zmiennej , a także od liczby odebranych wiadomości typu ACK. Początkowo . Po nadaniu zmiennej wartości przez monitor , przyjmuje wartośd 1. Następnie, po odebraniu ostatniej wiadomości typu ACK, wartośd elementu jest zmieniana na 2. Drugi wektor skojarzony z każdym monitorem , oznaczony przez (ang. communication state), jest zmienną reprezentowaną przez tablicę trzech liczb, której elementy odpowiadają licznikom odebranych wiadomości odpowiednio typu CONFIRM, ACK i DONE. Początkowo, wszystkie te liczniki mają wartośd 0. Są one stosownie zwiększane w wyniku odebrania wiadomości typu CONFIRM, ACK i DONE. Na rysunkach poniżej wektor jest umieszczony wewnątrz wierzchołków, natomiast obok niego. Przykład #1: W rozważanym poniżej przykładzie przyjęto, że jest jedynym inicjatorem procesu detekcji zakleszczenia. Monitor wywołuje procedurę i w konsekwencji jego stan zmienia się, wiadomości typu NOTIFY zostają wysłane, co zaznaczono białym kółkiem i strzałką) do monitorów wszystkich procesów tworzących zbiór warunkujący , a monitor oczekuje na wiadomości typu DONE, potwierdzające wszystkie wiadomości typu NOTIFY. Następnie, monitory odbierają współbieżnie wiadomości typu NOTIFY i w konsekwencji wywołują procedurę , zmieniając tym samym odpowiednio i wysyłając wiadomości NOTIFY do monitorów wszystkich procesów tworzących ich zbioru warunkujące. W następnym kroku, wiadomości typu NOTIFY docierają do monitorów, których flagi są już zapalone ( ). Dlatego, monitory te wysyłają w odpowiedzi wiadomości typu DONE (zaznaczone czarnym kółkiem). W rezultacie, wektory stanów monitorów przyjmują wartośd . Umożliwia to dalej, wysłanie wiadomości typu DONE do inicjatora . Gdy inicjator otrzyma wszystkie oczekiwane wiadomości typu DONE, algorytm kooczy się stwierdzając zakleszczenie procesu . Przykład #2 Złożoność czasowa algorytmu detekcji zakleszczenia w środowisku synchronicznym dla modelu spośród Graf niezorientowany, odpowiadający grafowi WFG, scharakteryzowany jest przez: średnicę grafu , najdłuższą ścieżkę w grafie . Złożonośd całego algorytmu to: złożonośd fazy potwierdzania złożonośd powiadomienia inicjatora fazy potwierdzania złożonośd odpowiadająca przesłaniu wiadomości typu DONE od inicjatora fazy potwierdzania do inicjatora detekcji przesłanie wiadomości typu CONFIRM może zabrad jednostek czasu transmisja wiadomości typu ACK również zabiera w najgorszym wypadku jednostek czasu przesłanie wiadomości typu NOTIFY (równolegle do monitorów wszystkich procesów tworzących zbiór wymaga co najwyżej kroków przesłanie wiadomości typu DONE po zakooczeniu fazy potwierdzania wymaga co najwyżej kroków W efekcie złożonośd czasowa algorytmu wynosi . Algorytm detekcji zakleszczenia w środowisku asynchronicznym Zakładamy, że w rozważanym środowisku rozproszonym czas transmisji w niezawodnych kanałach FIFO jest skooczony, ale nieznany. Wyznaczenie stanu globalnego takiego systemu musi zatem uwzględnid stany kanałów. Wyróżnia się cztery kolory łuków: a) Grey- jeżeli proces wysłał do wiadomośd typu REQUEST, a jeszcze tej wiadomości nie odebrał, ani też nie wysłał jeszcze wiadomości typu CANCEL. b) Black- jeżeli odebrał już wiadomośd typu REQUEST od , ale jeszcze nie wysłał w odpowiedzi wiadomości typu GRANT do , ani też nie wysłał jeszcze wiadomości typu CANCEL do . c) White- jeżeli wysłał już wiadomośd typu GRANT do , ale jeszcze jej nie odebrał, ani też nie wysłał jeszcze do wiadomości typu CANCEL. d) Translucent- jeżeli wysłał wiadomośd typu CANCEL do , lecz jeszcze jej nie odebrał. Załóżmy teraz, że każdy monitor zna odpowiadające mu zbiory oraz oraz kolory wszystkich krawędzi incydentnych grafu . W tym wypadku, w przeciwieostwie do środowiska synchronicznego, nie jest prawdziwa relacja: Algorytm Bracha, Toueg’a dla środowiska asynchronicznego type NOTIFY extends SIGNAL type DONE extends SIGNAL type CONFIRM extends SIGNAL type ACK extends SIGNAL : DONE : NOTIFY : CONFIRM : ACK : set of record of : PROCESS_ID : PROCESS_ID end record : set of PROCESS_ID : set of PROCESS_ID : INTEGER : BOOLEAN : BOOLEAN : INTEGER : array of enum : array of enum : INTEGER 1 2 3 4 5 6 7 8 procedure for all end for if end if : BOOLEAN do do then 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 for all do end for end procedure procedure do for all do end for for all do end for end procedure when NOTIFY_PROC() if do then end if end when when do if then end if end when when if do then end if end when Dwufazowy algorytm detekcji zakleszczenia Algorytm detekcji zakleszczenia rozproszonego w środowisku z niezawodnymi kanałami FIFO dla modelu spośród składa się z dwóch faz wymiany wiadomości: fazy inicjacji (ang. outward sweep) fazy detekcji (ang. inward sweep) Realizacja obu powyższych faz może nakładad się w czasie. Dwufazowy algorytm detekcji zakleszczenia dla modelu type CONTROL extends FRAME is record of : INTEGER : INTEGER : REAL end record spośród type FLOOD extends SIGNAL /* odpowiednik żądao zasobu. Za jego pomocą konstruowany jest w fazie inicjacji graf WFG */ type ECHO extends SIGNAL żądania zasobu */ /* odpowiedź na komunikat typu FLOOD; zgoda na realizację type SHORT extends SIGNAL /* służy do stwierdzenia momentu zakooczenia algorytmu detekcji */ : FLOOD : ECHO : SHORT : array of set of PROCESS_ID : array of set of PROCESS_ID : INTEGER : array of INTEGER : INTEGER : INTEGER : REAL : INTEGER : INTEGER : set of PROCESS_ID : set of PROCESS_ID : BOOLEAN 1 2 3 4 5 6 7 8 9 procedure do end procedure /* Kiedy proces staje się pasywny, jego monitor zapamiętuje stan lokalny procesu oraz skalarny czas logiczny odpowiadający momentowi przyjęcia po raz ostatni przez stanu pasywnego. Następnie, może zainicjowad detekcję zakleszczenia (wówczas oznaczamy przez ), wysyłając wiadomośd typu FLOOD do monitorów wszystkich procesów należących do w chwili */ when do 10 11 12 13 14 15 16 17 18 end when when do if then 19 20 21 22 23 24 25 26 27 28 29 30 31 end if end if 32 if 33 34 35 end if 36 if 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 if then end if if then then then if then end if if then end if end if if then /* zignoruj przetwarzaną wiadomośd typu FLOOD */ end if end when when do 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 if then if then end if if then if then if then end if else end if end if end if end when when if do then /* zignoruj nieaktualną wiadomośd SHORT */ end if if then /* zignoruj wiadomośd */ end if if then /* aktualizacja wagi procesu inicjatora */ if then /* jeśli warunek spełniony, to detekcja jest zakooczona */ end if end if end when Przykład działania dwufazowego algorytmu detekcji zakleszczenia rozproszonego: Analiza złożoności czasowej dwufazowego algorytu detekcji zakleszczenia Parametry grafu niezorientowanego, odpowiadającego WFG: - średnica grafu, - najdłuższa ścieżka w grafie a) Przesłanie wiadomości typu ECHO przez wszystkie krawędzie musi byd poprzedzone wysłaniem wiadomości FLOOD w przeciwnym kierunku. Przejście wiadomości typu FLOOD przez wszystkie krawędzie wymaga kroków. b) Najdłuższa ścieżka w grafie determinuje czas wymagany na propagację wiadomości typu ECHO od monitora procesu aktywnego do inicjatora. Złożonośd czasowa algorytmu wynosi . Detekcja zakleszczenia dla modelu predykatowego W algorytmie detekcji zakleszczenia dla modelu predykatowego wykorzystana jest koncepcj ciągu (łaocucha, sekwencji) cykli detekcyjnych (ang. wave sequence), polegająca na wielokrotnym w ogólności komunikowaniu się inicjatora procesu detekcji z pozostałymi monitorami w celu wyznaczenia stanu globalnego lub wartości predykatu globalnego. W celu uproszczenia prezentacji algorytmu detekcji zakleszczenia dla modelu predykatowego przyjmiemy, że monitory procesów aplikacyjnych tworzą strukturę pierścienia: Algorytm: type PACKET extends FRAME is record of : MESSAGE end record type TOKEN extends FRAME is record of : set of PROCESS_ID : BOOLEAN end record type ACK extends SIGNAL 1 2 3 procedure if : MESSAGE : PACKET : TOKEN : ACK : BOOLEAN : BOOLEAN : INTEGER : set of PROCESS_ID : set of PROCESS_ID : INTEGER : BOOLEAN : BOOLEAN do then 4 end if 5 wait until 6 if 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 then end if end procedure when do end when when if do then end if end when when do if then else end if end when when end when do 47 48 49 50 51 52 53 54 55 56 57 58 59 60 when do end when when do end when when end when do Wykład #7, 8: Konstrukcja spójnego obrazu stanu globalnego Plan wykładu: a) b) c) d) e) f) Stan globalny Konfiguracja i konfiguracja spójna Odcięcie oraz linia odcięcia Predykaty globalne Modele stanów globalnych Koncepcja konstrukcji spójnego obrazu stanu globalnego Przypomnij sobie definicje procesu rozproszonego, wykonania procesu oraz częściowego wykonania procesu, stanu osiągalnego, a także globalnego stanu osiągalnego oraz historii wykonania przed rozpoczęciem tego wykładu (patrz: Wykład #3). Konfiguracja Zbiór konfiguracji (obrazów stanu globalnego) składowych procesu rozproszonego Konfiguracja - wektor stanów lokalnych wszystkich składowych procesów sekwencyjnych procesu rozproszonego taki, że dla każdego , Łatwo zauważyd, że jest iloczynem kartezjaoskim stanów procesów , zawiera zbiór stanów osiągalnych procesu rozproszonego . Konfiguracja spójna Konfigurację nazwiemy konfiguracją spójną lub obrazem spójnym jeżeli: (patrz: relacja poprzedzania zdarzeo). Warunek powyższy oznacza, że jeśli jakieś zdarzenie jest elementem konfiguracji spójnej , to również wszystkie zdarzenia , od których jest przyczynowo-zależny (czyli ) również są elementami tej konfiguracji spójnej. Twierdzenie 5 Konfiguracja , reprezentująca stan osiągalny przetwarzania rozproszonego jest konfiguracją spójną. Powyższe twierdzenie wynika wprost z definicji stanu osiągalnego. Wszystkie zdarzenia wchodzące w skład stanu osiągalnego procesu rozproszonego pojawiły się w wyniku pewnego wykonania. Oznacza to, że jeżeli jakieś zdarzenie wchodzi w skład stanu osiągalnego, to także muszą się w nim znaleźd wszystkie zdarzenia, od których jest przyczynowo-zależne. Twierdzenie 6 Jeżeli jest konfiguracją spójną, w której lokalne stany składowe są osiągalne w pewnej realizacji przetwarzania rozproszonego , to istnieje stan osiągalny taki, że dla każdego , , Dowód powyższego twierdzenia wynika wprost z definicji konfiguracji spójnej i stanu osiągalnego. Linia odcięcia, odcięcie spójne Oznaczmy przez odpowiadających stanom ciąg wybranych punktów (zdarzeo pozornych) odcinków czasu, poszczególnych procesów zaznaczonych na pewnym diagramie przestrzenno-czasowym. Linię łamaną łączącą punkty nazywamy linią odcięcia, która dzieli zbiór zdarzeo na przeszłośd (te zdarzenia, które zaszły przed linią odcięcia) i przyszłośd (te zdarzenia, które zaszły po linii odcięcia). Odcięciem zbioru zdarzeo nazwiemy skooczony zbiór taki, że: Definicja powyższa mówi, ze jeżeli jakieś zdarzenie należy do odcięcia, to także wszystkie zdarzenia , które są lokalnie poprzedzane przez należą do tego odcięcia. Odcięcie zbioru zdarzeo nazwiemy odcięciem spójnym, gdy: Powyższa definicja mówi, że jeśli jakieś zdarzenie należy do odcięcia, to także wszystkie zdarzenie , od których jest zależne przyczynowo, należą do tego odcięcia. Odcięcie jest późniejsze od , jeżeli . Oznacza to, że odcięcie nie zawiera żadnego takiego zdarzenia nienależącego do , który by lokalnie poprzedzało jakiekolwiek zdarzenie znajdującego się w odcięciu . Przykład #1: Na rysunku widzimy dwa odcięcia spójnei . Pierwsze z nich obejmuje dwa zdarzenia oraz . Reprezentuje ono konfigurację, w której wiadomośd jest w kanale. Drugie jest późniejsze od ( - wszystkie zdarzenia należące do należą także do ) i obejmuje dodatkowo zdarzenia oraz . Odcięcie to reprezentuje sytuację, w której wszystkie kanały są puste. Gdyby odcięcie obejmowało dodatkowo zdarzenie , nie byłoby odcięciem spójnym, gdyż istniałoby takie zdarzenie ( ), od którego byłoby przyczynowo-zależne, które równocześnie nie należałoby do odcięcia . Natomiast rozszerzenie o zdarzenie również byłoby odcięciem spójnym. Przykład #2: Odcięcia przedstawione powyżej nie są odcięciami spójnymi, co łatwo wykazad. Odcięcie zawiera , które jest zdarzeniem odbioru wiadomości wysłanej w wyniku zdarzenia . Zachodzi zatem przyczynowa zależnośd między tymi dwoma zdarzeniami ( ), podczas gdy nie należy do odcięcia . Zgodnie z twierdzeniem 9 odcięcie to nie reprezentuje więc żadnej spójnej konfiguracji. Analogiczna sytuacji zachodzi w przypadku odcięcia . W tym przypadku, zawiera ono zdarzenie odbioru wiadomości wysłanej w wyniku zdarzenia . Zachodzi więc, podobnie jak poprzednio, przyczynowa zależnośd między oraz ( ), podczas gdy zdarzenie nie należy do odcięcia . Aby te odcięcia stały się odcięciami spójnymi, należy albo je poszerzyd o dodatkowe zdarzenia, albo pewne zdarzenia z nich usunąd. W przypadku odcięcia należałoby albo usunąd zdarzenie , albo dodad zdarzenie . W przypadku odcięcia , aby stało się ono odcięciem spójnym, należałoby je poszerzyd o zdarzenie , albo usunąd z niego zdarzenie . Twierdzenie 7 Dla odcięcia spójnego z linią odcięcia żadna para stanów (zdarzeo), odpowiadających linii odcięcia nie jest wzajemnie zależna. Twierdzenie 8 Dla każdego diagramu przestrzenno-czasowego z odcięciem spójnym określonym przez linię odcięcia istnieje równoważny diagram przestrzenno-czasowy, w którym linię odcięcia tworzą zdarzenia równoczesne w sensie czasu globalnego . Twierdzenie powyższe oznacza, że linie łamane reprezentujące odcięcia na diagramach przestrzennoczasowych można „przesuwad” tak, by otrzymad równoległe linie proste reprezentujące równoważne odcięcia. Zgodnie z definicją, każdemu odcięciu konfiguracja opisanemu przez linię odcięcia odpowiada . Twierdzenie 9 Niech będzie konfiguracją, a odpowiadającym jej odcięciem. Konfiguracja spójną, wtedy i tylko wtedy, gdy jest odcięciem spójnym. jest konfiguracją Predykaty globalne i ich własności Predykat globalny - predykat zdefiniowany na zbiorze osiągalnych stanów globalnych przetwarzania rozproszonego. Predykat stabilny- prawdziwośd predykatu w stanie globalnym implikuje jego prawdziwośd we wszystkich stanach osiągalnych z (patrz: stan osiągalny). Przykładowymi predykatami stabilnymi są predykaty definiujące stan zakleszczenia, zakooczenie przetwarzania, utraty znacznika, przekroczenia czasu obliczeo, czy czasu transmisji itp. Predykaty można także klasyfikowad w inny sposób. Przykładem są tutaj predykaty słabe, które uznaje się za predykaty prawdziwe w przetwarzaniu rozproszonym, jeżeli istnieje taki spójny stan globalny, w którym są spełnione, oraz predykaty silne, które uznaje się za prawdziwe w przetwarzaniu rozproszonym, gdy są uznawane za prawdziwe w pewnej chwili przez wszystkich uczestników przetwarzania. Duże znaczenie praktyczne posiadają też predykaty zdefiniowane na zbiorze wykonao historia wykonania), a w szczególności poniższe predykaty: (patrz: Predykat - zachodzi wtedy i tylko wtedy, gdy istnieje wykonanie , zawierające stan globalny , dla którego zachodzi predykat . Predykat - jest prawdziwy wtedy i tylko wtedy, gdy w każdym możliwym wykonaniu osiągalny jest stan , dla którego zachodzi . W ogólności wyznaczenie predykatów globalnych w pełni asynchronicznym systemie rozproszonym bez przyjęcia dodatkowych założeo jest niemożliwe, jeżeli chociaż jeden proces może ulec awarii. Stan globalny systemu W systemach rozproszonych, bardzo wiele problemów praktycznych i teoretycznych sprowadza się wprost do ciągłej lub okresowej obserwacji stanu globalnego systemu określonego jako zbioru stanów lokalnych procesów oraz wiadomości znajdujących się w kanałach komunikacyjnych. Znajomośd takiego stanu pozwala bowiem na wykrycie specyficznych sytuacji, niewidocznych z perspektywy pojedynczego procesu, i podjęcie stosownych działao. Przykładamy problemów redukujących się w istocie do oceny stanu globalnego są: Śledzenie i sterowanie wykonywaniem programu rozproszonego (ang. monitoring and debugging) Detekcja stanów awaryjnych (np. utraty wiadomości, zakleszczenia) lub oczekiwanych (np. zakooczenie obliczeo rozproszonych). Stany takie można wykryd tworząc obraz stanu globalnego, a następnie dokonując jego analizy (należy jednak wspomnied, że rozwiązania specjalizowane są często bardziej efektywne). Dostosowywania konfiguracji i funkcji systemu do zmieniającego się obciążenia (np. podział i równoważenie obciążenia, adaptacyjny wybór połączeo) Wyliczenie pewnej globalnej wartości zarządzanej przez program rozproszony Utworzenie kopii zapasowych stanu globalnego programu Obraz stanu globalnego nazywa się też czasami migawką stanu globalnego (ang. global snapshot). Nieformalnie, obraz stanu globalnego określid można jako spójny, jeżeli dla każdego z procesów wygląda, jak gdyby został wyznaczony w jednej chwili we wszystkich częściach systemu. Można tutaj określid stan globalny jako zbiór stanów wyznaczonych w jednej chwili we wszystkich częściach systemu- w asynchronicznym środowisku rozproszonym taka definicja jest jednak nierealna. Zamiast tego więc, mówi się raczej o zbiorze stanów niezależnych wzajemnie od siebie. Modele stanów globalnych Jako przykładowy problem wyznaczania obrazu stanu globalnego rozważmy przetwarzanie rozproszone obejmujące trzy procesy , które współdzielą pewien zasób w trybie wzajemnego wykluczania. Jak wiadomo, problem wzajemnego wykluczania można stosunkowo łatwo rozwiązad, przyjmując, że warunkiem koniecznym dostępu do współdzielonego zasobu (sekcji krytycznej) jest posiadanie w danej chwili unikalnego komunikatu- znacznika (ang. token). Znacznik krążąc między procesami połączonymi w logiczny pierścieo (reprezentowany przez graf cykliczny) wskazuje kolejno procesy uprawnione do operowania na zasobie współdzielonym. Innymi słowy, tylko proces posiadający w danej chwili znacznik posiada równocześnie dostęp do zasobu. Stan procesu zmienne: w każdej chwili czasu globalnego (rzeczywistego) zdefiniowany jest przez trzy - przyjmuje wartośd tylko wówczas, gdy znacznik typu TOKEN znajduje się w chwili w procesie (proces ten posiada znacznik i jednocześnie dostęp do współdzielonego zasobu). - kolejka znaczników wysłanych do chwili przez proces . - kolejka znaczników odebranych przez proces do chwili . Przykład: Zakładamy, że w globalnym stanie początkowym wszystkie kolejki są początkowo puste oraz znacznik znajduje się w procesie . ,a Przedstawione podejście jest powszechnie stosowane, a jego dużą zaletą jest ograniczanie liczby składowych stanu globalnego do liczby procesów ( ). Z drugiej jednak strony, ma ono z praktycznego punktu widzenia pewne określone wady: Podejście jest adekwatne tylko dla systemów z kanałami niezawodnymi Poważną trudnośd stanowi koniecznośd pamiętania wszystkich dotychczas wysłanych i odebranych wiadomości. Z upływem czasu rośnie bowiem istotnie koszt przechowywania i przetwarzania tej informacji. Podejście alternatywne Wady przedstawionego podejścia powodują, że w praktyce stosowane jest też podejście alternatywne, polegające na definiowaniu stanu globalnego jako złożenia stanów lokalnych procesów i stanów kanałów komunikacyjnych. Prowadzi to do reprezentacji stanu globalnego przez składowych, odpowiadających stanom lokalnym wszystkich procesów i wszystkich kanałów. Liczba składowych jest w tym wypadku oczywiście większa, lecz reprezentacja stanu procesu może byd dużo prostsza i w rezultacie efektywniejsza z punktu widzenia zajętości pamięci i kosztów przetwarzania (prostsza reprezentacja stanu procesu kosztem większej liczby składowych). W celu ilustracji podejścia alternatywnego rozważmy jeszcze raz poprzedni przykład. Przyjmijmy, że stan procesu jest w każdej chwili określony przez zmienną logiczną oraz przez liczniki (ang. sent number) i (ang. receive number), o wartościach równych liczbie dotychczas wysłanych i odebranych znaczników typu TOKEN. Z kolei stan kanału określony może byd przez zbiór znaczników, znajdujących się aktualnie w kanale . Możliwa jest też reprezentacja jeszcze prostsza, w której stan procesu określony jest przez zmienną , a stan kanału przez analogiczną zmienną . Zmienne te przyjmują wartości tylko wówczas, gdy znacznik typu TOKEN znajduje się aktualnie w odpowiednim procesie lub kanale. Przykład: Niech dla prostoty zapisu „1” oznacza obecnośd znacznika, a „0”- jego brak. W efekcie stan globalny możemy przedstawid w naszym przypadku w sposób następujący: Tym samym kolejne stany mają postad: do do do - znacznik jest w posiadaniu procesu , kanały są puste - znacznik znajduje się w kanale (został wysłany przez , ale jeszcze nie dotarł - znacznik jest w posiadaniu procesu , kanały są puste - znacznik znajduje się w kanale (został wysłany przez , ale jeszcze nie dotarł - znacznik jest w posiadaniu procesu , kanały są puste - znacznik znajduje się w kanale (został wysłany przez , ale jeszcze nie dotarł ) ) ) Graf stanów osiągalnych Graf stanów osiągalnych przedstawiony poniżej odpowiada przesyłaniu unikalnych znaczników w pierścieniu trzech procesów. Przedstawiony przykład ilustruje dotychczasowe rozumienie stanu lokalnego procesów oraz stanu globalnego przetwarzania rozproszonego- jako historii przetwarzania. Należy zaznaczyd, że rozumienie to pozwala na określenie w każdej chwili aktualnego stanu kanałów na podstawie stanów lokalnych procesów. Ocena stanów globalnych W rozważanych przypadkach ocena stanów globalnych w wybranych momentach czasu może mied na celu sprawdzenie, czy rzeczywiście w każdej chwili w systemie jest dokładnie jeden znacznik. Zaginięcie znacznika, wynikające na przykład z błędu programu, w którymkolwiek węźle, uniemożliwia procesom w sposób trwały wejście do sekcji krytycznej, co może prowadzid do blokady całego systemu. Z kolei stwierdzenie zwielokrotnienia znaczników oznacza możliwośd jednoczesnego działania dwóch lub więcej procesów w sekcjach krytycznych, co w ogólności prowadzi do błędów współbieżnego działania procesów. Porównanie reprezentacji stanów globalnych Przedstawione reprezentacje stanów globalnych nie są równoważne: Pierwsza reprezentacja operuje na informacji najpełniejszej: unikalnych znacznikach i całej historii komunikacji Druga reprezentacja utożsamia wszystkie znaczniki i wyróżnia tylko stany ich obecności oraz nieobecności w poszczególnych procesach i kanałach Powstaje zatem problem wyboru odpowiedniego modelu stanu globalnego. Warto tu podkreślid, że wybór ten zależy istotnie od zastosowania, które w dużej mierze narzuca wymaganą precyzję reprezentacji stanu lokalnego i globalnego. Metoda wyznaczania stanu globalnego Analizując dotychczas przedstawione modele stanów globalnych, abstrahowano od problemu jednoczesnego wyznaczenia poszczególnych składowych stanu globalnego, a więc wyznaczenie stanów lokalnych wszystkich procesów i ewentualnie kanałów w określonej, tej samej chwili. Oznaczało to niejawne założenie istnienia idealnego obserwatora zewnętrznego, który ma dostęp jednocześnie do wszystkich procesów tworzących przetwarzanie, co nie jest niestety możliwe w systemie asynchronicznym. Niestety, w asynchronicznym środowisku rozproszonym takie podejście ma tylko znaczenie teoretyczne z uwagi na jego cechy: Jedyny mechanizm komunikacji i synchronizacji to wymiana komunikatów Brak wspólnej pamięci Proces, chcący wyznaczyd stan globalny, może zatem tylko wysyład żądania wyznaczania stanów lokalnych, a po otrzymaniu odpowiedzi, konstruowad na ich podstawie stan globalny. Niestety, asynchroniczne środowisko rozproszone posiada znacząco utrudniające to zadanie cechy: Brak wspólnego zegara Asynchronizm przetwarzania Nieprzewidywalne czasy transmisji (opóźnienia komunikacyjne) W wyniku tego otrzymane składowe stany lokalne procesów mogą byd: Przestarzałe Niekompletne Odpowiadad konfiguracjom niespójnym- reprezentującym stany nieosiągalne, których wystąpienia zewnętrzny, idealny obserwator nigdy nie mógłby stwierdzid. W tym kontekście jest jasne, że żaden lokalny, rzeczywisty proces dążący do wyznaczenia stanu globalnego przetwarzania rozproszonego nie może w ogólności wyznaczyd chwilowych wartości stanu. Proste i naturalne zwiększenie prędkości transmisji może oczywiście poprawid obraz stanu globalnego w sensie aktualności i kompletności, lecz nie jest wystarczające dla zapewnienia spójności. Dodatkowym źródłem trudności przy ocenie obrazu stanu globalnego jest relatywizm obserwacji, istotny zwłaszcza przy współbieżnej konstrukcji obrazów przez wiele procesów. Nawet, gdy każdy z utworzonych obrazów jest spójny, mogą one się różnid na tyle, że procesy monitorujące mogą podejmowad działania konfliktowe. Koncepcja konstrukcji obrazu stanu globalnego Rozważmy na początek problem przy następujących dodatkowych założeniach: Dostępny jest dla wszystkich procesów globalny zegar czasu rzeczywistego Znane jest maksymalne opóźnienie komunikacji Względne prędkości przetwarzania w poszczególnych węzłach są ograniczone Koncepcja wyznaczenia spójnego obrazu przy przyjętych takich założeniach jest bardzo prosta. Wystarczy, by dowolny proces monitora , wybrał chwilę na tyle odległą w przyszłości, by zagwarantowad, że wiadomośd wysłana w danej chwili dotrze do wszystkich procesów przed . W celu wyznaczenia stanu kanałów, można przyjąd, że każda wiadomośd zawiera etykietę czasową, określającą czas rzeczywisty wysłania wiadomości. Zakładając przy tym, że kanały są niezawodnymi kanałami typu FIFO, ideę algorytmu można przedstawid następująco: 1. Proces inicjatora wysyła do monitorów wszystkich procesów przetwarzania rozproszonego wiadomośd: „zapamiętaj stan lokalny w chwili ” 2. Monitory procesów zapamiętują stan lokalny , odpowiadających im procesów aplikacyjnych w chwili i natychmiast wysyłają wiadomośd kontrolną do wszystkich monitorów (wiadomośd ta jest wysyłana wszystkimi kanałami wyjściowymi). Zapamiętują też stan kanałów wejściowych jako zbiór wszystkich wiadomości aplikacyjnych, które zostały wysłane przed , a dotarły do po chwili . Zapamiętywanie stanu lokalnego oraz wysyłanie wiadomości kontrolnej poprzedza przy tym zajście jakiegokolwiek zdarzenia w procesie aplikacyjnym dla . 3. Gdy monitor otrzyma przez kanał pierwszą wiadomośd o etykiecie czasowej większej od (wiadomośd kontrolną), aktualną wartośd uznaje jako stan tego kanału w chwili . 4. Gdy monitor otrzyma wiadomości o etykiecie czasowej większej od przez wszystkie swoje kanały wejściowe, przesyła stan lokalny zapamiętany w chwili oraz wyznaczone stany kanałów wejściowych do inicjatora detekcji . 5. Po odebraniu od wszystkich monitorów wiadomości zawierających stany lokalne oraz stany ich kanałów wejściowych w chwili inicjator konstruuje obraz stanu globalnego . Zauważmy teraz, że jeżeli zapamiętane stany lokalne obejmowałyby historię komunikacji (kolejki wiadomości wysłanych i odebranych do danej chwili przez procesy aplikacyjne), to oczywiście przesyłanie wiadomości kontrolnych nie byłoby potrzebne. Wiadomo jednak z drugiej strony, że pamiętanie całej historii komunikacji może byd zbyt kosztowne w praktyce i wówczas przedstawione podejście będzie w pełni uzasadnione. Warto też zwrócid uwagę, że przesyłanie wiadomości kontrolnych jest krytyczne dla żywotności przedstawionego wyżej algorytmu. Istotnie, w wypadku bowiem, gdyby proces aplikacyjny nie wysłał po chwili wiadomości przez pewien kanał wyjściowy, stan tego kanału nigdy nie zostałby wyznaczony, a zakooczenie konstrukcji obrazu spójnego byłoby całkowicie uzależnione od własności przetwarzania aplikacyjnego. Dowód poprawności koncepcji Łatwo jest dowieśd poprawności przedstawionej koncepcji konstrukcji obrazu spójnego. Skonstruowany obraz reprezentuje stan globalny, który wystąpił w chwili . Argumentując poprawnośd bardziej formalnie, zauważmy, że wyznaczony obraz uwzględnia wszystkie zdarzenia lokalne, które zaszły przed chwilą . Stąd gdzie jest czasem rzeczywistym zajścia zdarzenia . Zegar czasu rzeczywistego spełnia warunek poprawności zegara, zatem: otrzymujemy a to właśnie należało wykazad. Algorytmy konstrukcji spójnego obrazu stanu globalnego Przedstawione zostaną niektóre algorytmy, służące do konstrukcji obrazu spójnego stanu globalnego. Są to algorytmy Chandy-Lamporta dla kanałów FIFO, algorytm Matterna, stosujący zegary wektorowe, algorytm Lai-Yang dla kanałów non-FIFO, a także algorytm kolorujący procesy i wiadomości oraz dwa algorytmy dla kanałów typu FC (Chandy-Lamporta i stosujący znaczniki BF i FF). Dla niektórych algorytmów zostanie również omówiona ich złożonośd czasowa oraz dowiedziona ich poprawnośd. Algorytm Chandy-Lamporta Algorytm ten wymaga przyjęcia kilku założeo dotyczących środowiska przetwarzania: Niezawodne kanały zachowują uporządkowanie wiadomości (niezawodne kanały FIFO) Stan reprezentowany jest w postaci złożenia lokalnych stanów procesów i stanów kanałów Pełen asynchronizm komunikacji i przetwarzania Brak zegara globalnego Koncepcja algorytmu przedstawia się następująco Pewien monitor inicjuje proces konstrukcji (detekcji) spójnego obrazu stanu globalnego zapamiętuje stan lokalny skojarzonego z nim procesu aplikacyjnego i wysyła wiadomośd kontrolną (znacznik) typu MARKER do wszystkich incydentnych monitorów. Każdy monitor po odebraniu znacznika z kanału sprawdza, czy jest to pierwszy znacznik odebrany w danym procesie detekcji (tzn. czy stan procesu został już w tym procesie detekcji zapamiętany). Jeżeli tak jest, to monitor zapamiętuje stan procesu , uznaje stan kanału za pusty, i propaguje znacznik przez wszystkie swoje kanały wyjściowe (wysłanie znacznika musi poprzedzid zdarzenie wysłania danym kanałem kolejnej, po zapamiętaniu stanu, wiadomości aplikacyjnej). Jeżeli stan procesu został już wcześniej zapamiętany, to uznaje za stan kanału zbiór tych wszystkich wiadomości aplikacyjnych, które dotarły tym kanałem po zapamiętaniu stanu, a przed otrzymaniem znacznika. Po odebraniu znaczników ze wszystkich kanałów wejściowych, monitor przesyła zapamiętany stan lokalny procesu oraz stan wszystkich kanałów wejściowych do monitora , konstruującego obraz stanu globalnego. W szczególności możliwe jest oczywiście, że Ilustracja działania algorytmu Chandy-Lamporta Na powyższym przykładzie przyjęto, że linia czerwona oznacza przesłanie wiadomości aplikacyjnej (np. ), natomiast liniami zielonymi oznaczono przesłanie znacznika między monitorami. Założono ponadto, że topologia przetwarzania reprezentuje graf pełny (każdy proces jest incydentny z każdym innym procesem , gdzie ). Inicjatorem detekcji zachodzącego w zmiennej monitorów i . zapamiętanie stanu jest monitor . Na górnej części rysunku w wyniku zdarzenia , w zmiennej zapamiętany zostaje stan lokalny procesu , nadawana jest wartośd początkowa , a znaczniki zostają wysłane do Odebranie pierwszego znacznika przez w wyniku zdarzenia powoduje lokalnego i uznanie kanału wejściowego za pusty (podstawienie ). Z kolei wiadomośd , odebrana przez po zapamiętaniu stanu lokalnego, zostaje uwzględniona w stanie kanału . Zajście zdarzenia powoduje, że ostatecznie stan kanału będzie zawierał wiadomośd . Ostatecznie zatem zostaje wyznaczony następujący stan spójny: Dla porównania stan wyznaczony w procesie detekcji na dolnej części rysunku wygląda następująco: Jak widad, mimo, że proces detekcji w obu przypadkach rozpoczęty został w tej samej chwili przez ten sam monitor, otrzymane konfiguracje spójne i są różne. Łatwo też zauważyd, że reprezentuje stan , podczas gdy reprezentuje stan, który nie wystąpił w rozpatrywanej realizacji (w żadnej chwili nie ma jednocześnie w kanałach i wiadomości). Ta różnica nie powinna zaskakiwad z uwagi na asynchronizm komunikacji i wynikający z tego niedeterminizm przetwarzania. Algorytm Chandy-Lamporta type PACKET extends FRAME is record of : MESSAGE end record type MARKER extends FRAME /* zwykła wiadomośd aplikacyjna */ /* znacznik */ /*wiadomośd, zawierająca stan procesu oraz stan kanałów incydentnych z tym procesem */ type STATE extends FRAME is record of : PROCESS_STATE : array of set of MESSAGE end record : MESSAGE /* wiadomośd wysyłana przez proces aplikacyjny */ /* monitor procesu opakowuje wiadomośd przesyła dalej jako */ : PACKET : TOKEN /* znacznik */ : STATE /* wiadomośd przesyłająca stan */ /* informacje, czy proces otrzymał znacznik od -tego procesu (wartośd elementu równa ) i tym samym został wyznaczony stan kanału */ : array of BOOLEAN /* stan kanałów wejściowych procesu , lista komunikatów odebranych od momentu zapamiętania stanu przez monitor do momentu otrzymania znacznika od zapisywany będzie w */ : array of set of MESSAGE : PROCESS_STATE /* stan procesu */ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. : set of CHANNEL_ID /* zbiór kanałów wejściowych procesu */ : set of CHANNEL_ID /* zbiór kanałów wyjściowych procesu */ /* wartośd zmiennej oznacza, że proces zaangażował się już w konstrukcję obrazu stanu globalnego */ : BOOLEAN /* procedura zapisuje stan procesu, ustawia stan kanałów na oraz zaznacza, że proces wziął już udział w wyznaczaniu obrazu i wysyła znacznik do wszystkich monitorów połączonych z procesem za pomocą kanałów wejściowych */ procedure do for all do end for end procedure /* powoduje przesłanie stanu procesu procedure do do monitora */ end procedure /* proces inicjatora konstrukcji zapamiętuje własny stan i rozsyła znaczniki do incydentnych monitorów za pomocą procedury , ustawia pozycję w tablicy na oraz wysyła swój stan za pomocą procedury */ when do if then end if end when when do end when /* W przypadku otrzymania znacznika monitor zapisuje stan skojarzonego z nim procesu aplikacyjnego (o ile jeszcze tego wcześniej nie wykonał) i przesyła znacznik dalej (przy pomocy procedury ), ustawia odpowiedni wpis w tablicy na . Jeżeli monitor otrzymał już znaczniki wszystkimi kanałami wejściowymi, rozsyła swój stan do incydentnych monitorów */ when do if then 29. 30. 31. end if 32. if 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. then end if end when /* Jeżeli monitor jest już zaangażowany w proces konstrukcji spójnego obrazu stanu globalnego, to otrzymując dowolną wiadomośd aplikacyjną, przed przekazaniem jej do skojarzonego procesu aplikacyjnego dodaje ją do odpowiedniej pozycji zmiennej */ when do if then end if end when Twierdzenie 10 Algorytm Chandy-Lamporta wyznacza w skooczonym czasie konfigurację spójną. Powyższe twierdzenie można dowieśd następująco, korzystając z poniższego lematu: Jeżeli co najmniej jeden proces zainicjuje algorytm, wszystkie procesy zapiszą swój stan lokalny w skooczonym czasie. Ponieważ każdy proces zapisuje stan i wysyła znacznik co najwyżej raz, algorytm się kooczy w skooczonym czasie. Jeżeli jest procesem, który już zapisał stan, a jest sąsiadem , to również zapisał stan. Wynika to z faktu, że znacznik wysłany przez i odebrany przez wymusza na nim zapisanie stanu, jeżeli wcześniej tego nie dokonał. Ponieważ co najmniej jeden proces zainicjował algorytm, co najmniej jeden zapisał stan, a ponieważ zakładamy, że wszystkie procesy są połączone (pośrednio lub bezpośrednio) za pomocą sieci komunikacyjnej, implikuje to, że wszystkie procesy zapisały stan. Należy obecnie wykazad, że wyznaczona konfiguracja jest spójna. Oznacza to, że nie może ona zawierad wiadomości w zapisanym stanie kanałów bądź zdarzeo odbioru wiadomości wysłanych w wyniku pewnego zdarzenia, które by nie zostało zapisane w obrazie stanu globalnego. Przyjmijmy, że jeżeli proces zapisał swój stan, to wysłał również znacznik do wszystkich sąsiadów. Oznacza to, że każde zdarzenie wysłania przez wiadomości do innego procesu po zapisaniu stanu musi byd poprzedzone zdarzeniem wysłania znacznika- z własności FIFO kanałów komunikacyjnych oznacza to, że otrzyma znacznik przed wiadomością . Z algorytmu wynika, że otrzymanie znacznika przez wymusza na nim zapisanie stanu- a więc jest niemożliwe, aby proces ten otrzymał tą wiadomośd przed zapisaniem stanu. Oznacza to, że wyznaczona konfiguracja nie będzie zawierała żadnej wiadomości, której zdarzenie wysłania nie zostało zapisane w którymś ze stanów lokalnych, a więc jest konfiguracją spójną. Twierdzenie 11 Jeżeli proces konstrukcji konfiguracji spójnej rozpoczął się w chwili , a zakooczył w chwili wyznaczona konfiguracja , reprezentująca pewien stan globalny , jest osiągalna ze stanu a stan globalny jest osiągalny ze stanu . Tym samym: , to , Złożoność czasowa Oznaczmy przez średnicę grafu zorientowanego, odpowiadającego topologii przetwarzania rozproszonego, a przez - liczbę krawędzi tego grafu. Wówczas, pomijając fazę przesyłania wiadomości o stanie procesów i kanałów złożonośd czasowa algorytmu Chandy-Lamporta wynosi , a złożonośd komunikacyjna, w sensie liczby przesyłanych znaczników, wynosi (BŁĄD powinno byd chyba ?). Algorytm Lai-Yang Wstęp W algorytmie Chandy-Lamporta przesyłane znaczniki pełniły podwójną rolę. Po pierwsze, dzięki zachowaniu uporządkowania FIFO pakietów, znaczniki określały pośrednio zbiór wiadomości wysyłanych przez nadawcę do w chwili zapamiętania stanu lokalnego procesu . Zbiór jest bowiem jednocześnie zbiorem wiadomości odebranych przez do chwili otrzymania znacznika (wiadomości wysłane przed znacznikiem dotrą przed nim do procesu docelowego), czyli . Jeżeli więc stan procesu zostanie zapamiętany w chwili , to stan kanału w chwili jest równy . Dodatkowo znaczniki przesyłane kanałami FIFO gwarantują oczywiście, że , a tym samym zapewniają spójnośd obrazu stanu globalnego. Lai-Yang przedstawili algorytm, który nie wymaga by kanały były typu FIFO. Założyli oni natomiast, że reprezentacje stanów lokalnych obejmują historię wykonania, a więc odpowiednie zbiory wiadomości dotychczas wysłanych i odebranych. Koncepcja Jeśli po zapamiętaniu stanu proces potrzeby przesłania do znacznika. już nigdy nie wyśle wiadomości do , to nie ma Jeśli wiadomości będą w dalszym ciągu wysyłane, to można do nich zawsze dołączyd znacznik w formie etykiety, a tym samym odróżnid te pakiety od wszystkich pakietów wysłanych przed zapamiętaniem stanu. Wyróżnione pakiety ze znacznikiem przechwytywane są przez monitor odbiorcy i powodują zapamiętanie stanu procesu , a przed przekazaniem wiadomości aplikacyjnej procesowi . Żadna z wiadomości wysłanych przez do po zapamiętaniu stanu procesu , nie zostanie odebrana przez przed zapamiętaniem jego stanu. Oznacza to dalej, że spełniona będzie relacja: która gwarantuje spójnośd konstruowanego obrazu stanu globalnego przetwarzania rozproszonego Algorytm przydziela procesom (monitorom) oraz wiadomościom jeden z dwóch kolorów lub . Przypisanie odpowiedniego koloru pakietowi oznacza: - pakiet bez znacznika - dołączenie znacznika do wiadomości Analogicznie, kolory przypisane są również procesom (kontrolerom): - proces nie zapamiętał jeszcze stanu - stan procesu został już zapamiętany Ogólna idea algorytmu przedstawia się następująco: Każdy proces jest postrzegany przez monitor początkowo jako , a monitor zmienia jego kolor na po zapamiętaniu stanu procesu. Każdej wiadomości wysłanej przez proces koloru przypisany jest kolor , a każdej wiadomości wysłanej przez proces koloru przypisany jest, analogicznie, kolor . Stan procesu koloru można zapamiętad w dowolnej chwili, lecz koniecznie przed odebraniem wiadomości koloru . Algorytm Lai-Yang Algorytm używa dwóch typów wiadomości. Wiadomości aplikacyjne przesyłane są w pakietach typu PACKET, które dodatkowo zawierają etykietę wiadomości w polu , będącą jedną z wartości lub . Drugim typem jest STATE, zawierający pole , określające stan lokalny procesu, ze zbiorem wiadomości aplikacyjnych wysłanych do chwili zapamiętania stanu procesu oraz pole ze zbiorem wiadomości aplikacyjnych odebranych do chwili zapamiętania stanu procesu. type PACKET extends FRAME is record of : enum : MESSAGE end record type STATE extends FRAME is record of : PROCESS_STATE : set of MESSAGE : set of MESSAGE end record : MESSAGE /* wiadomośd aplikacyjna wypakowywana z odebranego przez monitor pakietu, która zostanie dostarczona procesowi aplikacyjnemu */ : PACKET /* monitor procesu opakowuje wiadomośd aplikacyjną i przesyła dalej jako */ : PACKET /* wiadomośd oznaczona specjalnym znacznikiem inicjującym, przenoszący pustą wiadomośd aplikacyjną */ : STATE /* wiadomośd przesyłająca stan */ : PROCESS_STATE /* stan procesu */ : enum /* kolor monitora */ : set of MESSAGE /* określa zbiór wiadomości wysłanych przez proces do chwili zapamiętania stanu procesu */ : set of MESSAGE /* określa zbiór wiadomości wysłanych przez proces do chwili obecnej */ : set of MESSAGE /* określa zbiór wiadomości odebranych przez proces do chwili zapamiętania stanu procesu */ : set of MESSAGE /* określa zbiór wiadomości odebranych przez proces do chwili obecnej */ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. aplikacyjnych aplikacyjnych aplikacyjnych aplikacyjnych /* procedura zapamiętuje stan procesu, przypisując stan lokalny , a zawartośd zmiennych i do oraz */ procedure do do end procedure /* procedura służy do przesłania zapisanego stanu procesu , zajmującego się konstrukcją obrazu spójnego stanu globalnego */ procedure do do monitora end procedure /* Konstrukcja obrazu spójnego stanu globalnego rozpoczynana jest przez monitor . Zapisuje on stan skojarzonego ze sobą procesu aplikacyjnego, zmienia kolor procesu na i wysyła pusty znacznik o kolorze do wszystkich procesów. Następnie rozsyła również swój stan */ when do end when when end when do 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. /* Otrzymując pakiet o kolorze monitor procesu aplikacyjnego o kolorze zmienia jego kolor na i rozsyła jego stan. Przed dostarczeniem wiadomości do procesu monitor zapamiętuje ją w zmiennej */ when do if then end if if then end if end when Złożoność czasowa Dla grafu pełnego, reprezentującego topologię przetwarzania rozproszonego złożonośd czasowa algorytmu Lai-Yanga wynosi , a złożonośd komunikacyjna, w sensie liczby przesyłanych znaczników, wynosi ( oznacza ilośd wierzchołków tego grafu, czyli de facto, liczbę procesów biorących udział w przetwarzaniu rozproszonym), pomijając fazę przesyłania wiadomości o stanach procesów i kanałów. Twierdzenie 12 Konfiguracja wyznaczona przez algorytm Lai-Yang jest konfiguracją spójną. Dla dowodu powyższego twierdzenia przyjmijmy, że istnieje wiadomośd wysłana z do po fakcie zapisania stanu procesu . To oznacza, że znacznik związany z wiadomością musi mied wartośd , co wymusza na zapisanie stanu lokalnego najpóźniej w momencie odebrania . Tak więc, stan zapisany przez nie zawiera zdarzenia odbioru wiadomości . Niech pakiet sterujący będzie wysyłany kanałami, odpowiadającymi krawędziom drzewa rozpinającego o wysokości , grafu reprezentującego topologię przetwarzania. Pomijając fazę zbierania informacji z poszczególnych węzłów i koszt zmiany koloru pakietów, to złożonośd czasowa i komunikacyjna algorytmu Lai-Yanga wynosi odpowiednio i . Można dowieśd, że jeżeli kanały komunikacyjne nie są FIFO oraz nie używa się znaczników dołączanych do wiadomości aplikacyjnych, konstrukcja obrazu stanu globalnego wymaga zatrzymania przetwarzania. W przypadku kanałów FIFO taki algorytm oczywiście istnieje (przykładem jest np. algorytm Chandy-Lamporta) Algorytm Matterna, stosujący zegary wektorowe Rozważmy system, w którym kanały są kanałami nonFIFO. Algorytm wyznaczający stan globalny dla takiego systemu wywodzi się z koncepcji wyznaczania stanu globalnego z użyciem zegara czasu rzeczywistego (patrz: Wykład #4: zegary). Ogólna koncepcja przedstawia się następująco: określenie momentu czasu , odpowiadającego przyszłości, w którym zostaną zapamiętane stany lokalne wszystkich procesów po wyznaczeniu stanów lokalnych w momencie , monitory przesyłają informację o stanach lokalnych do monitora konstruującego obraz globalny W celu adaptacji powyższej koncepcji do asynchronicznego systemu rozproszonego, proces inicjatora określa wektorowy czas wirtualny momentu zapamiętania w przyszłości stanu lokalnego procesu. Twierdzenie 13 W chwili, gdy uaktualniony został zegar wektorowy procesu , zachodzi: Powyższa własnośd oznacza w praktyce, że zmiana wektorowego zegara lokalnego w pewnym procesie określa czas wirtualny, który z perspektywy wszystkich pozostałych procesów z pewnością nie jest czasem odnoszącym się do przeszłości. Algorytm Matterna Algorytm wykorzystuje pięd różnych typów komunikatów. Typ PACKET służy do przenoszenia wiadomości aplikacyjnych i posiada pole , które jest wektorową etykietą czasową pakietu. Typ komunikatu CONTROL zawiera pole , będące polem zadanego czasu zapamiętania stanu. Komunikaty typu PROC_STATE zawierają stan procesu w polu . Stan kanału przesyłany jest w polu wiadomości typu CHAN_STATE. Wreszcie, wiadomości typu ACK są prostymi potwierdzeniami, niezawierającymi żadnych pól. type PACKET extends FRAME is record of : array of INTEGER : MESSAGE end record type CONTROL extends FRAME is record of : array of INTEGER end record type PROC_STATE extends FRAME is record of : PROCESS_STATE end record type CHAN_STATE extends FRAME is record of : MESSAGE end record type ACK extends FRAME : MESSAGE /* wiadomośd aplikacyjna wypakowywana z odebranego przez monitor pakietu, która zostanie dostarczona procesowi aplikacyjnemu */ : PACKET /* monitor procesu opakowuje wiadomośd aplikacyjną i przesyła dalej jako */ : PACKET /* specjalny pakiet, zawierający pusty komunikat aplikacyjny, wysyłany przy rozpoczęciu algorytmu */ : CONTROL /* pakiet kontrolny */ : ACK /* pakiety potwierdzenia */ : PROC_STATE /* służy do przesyłania stanu procesu */ : CHAN_STATE /* służy do przesyłania stanu kanału */ : array of INTEGER /* wektorowy zegar logiczny procesu */ : array of INTEGER /* reprezentuje logiczny czas zadanego momentu zapamiętania obrazu spójnego*/ : PROCESS_STATE /* stan procesu */ : BOOLEAN /* określa, czy został już zapamiętany stan procesu */ /* Dla uproszczenia będziemy zakładad, że : monitor inicjatora zwiększa pozornie wartośd swojego zegara wektorowego i tym samym wyznacza moment z jego perspektywy w przyszłości o czasie tym informuje wszystkie pozostałe monitory, wstrzymując jednocześnie postęp lokalnego czasu wirtualnego (blokuje postęp przetwarzania aplikacyjnego) Dopiero po upewnieniu się, że wszystkie monitory znają wyznaczony moment w przyszłości, uwalniane jest przetwarzanie aplikacyjne, a więc również zegar lokalny. Monitor zapisuje wtedy stan skojarzonego z nim procesu aplikacyjnego i rozsyła pustą wiadomośd , zaznaczając jednocześnie, że stan procesu został już zapisany. */ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. when for all do do end for end when /* otrzymując wiadomośd kontrolną monitor zapamiętuje w zmiennej moment wyznaczenia stanu lokalnego, a następnie odsyła potwierdzenie */ when do end when /* wysyłając wiadomośd monitor modyfikuje zegar wektorowy w zwykły sposób */ 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. when do end when when for all do do end for if then end if if end if if then then end if end when Otrzymując pakiet aplikacyjny monitor modyfikuje zegar wektorowy w zwykły sposób. Jeżeli monitor zapisywał już stan aplikacyjny, a etykieta odebranego pakietu jest wcześniejsza od momentu wyznaczenia stanu zapisanego w , monitor wysyła informację o otrzymaniu tego pakietu do inicjatora konstrukcji spójnego obrazu stanu globalnego. W wyniku dalszej komunikacji między procesami aplikacyjnymi, bądź w wyniku przesłania dodatkowych wiadomości synchronizujących między monitorami, każdy z procesów osiągnie w koocu, lub będzie usiłował przekroczyd, wyznaczony moment . Przed przekroczeniem wartości , zapamiętany zostanie stan lokalny procesu. Kolekcja takich stanów tworzy konfigurację spójną. Algorytm kolorujący procesy i wiadomości Koncepcja Wadą przedstawionego algorytmu Matterna jest zawieszenie przetwarzania aplikacyjnego procesu do momentu uzyskania przez monitor potwierdzeo odebrania wiadomości kontrolnej, zawierającej żądany moment zapamiętania w przyszłości stanu lokalnego od wszystkich pozostałych monitorów. Problemu tego można uniknąd wprowadzając dodatkową pozycję w wektorze czasu, której wartośd jest zwiększana tylko przez wyróżniony monitor nieskojarzony z żadnym procesem aplikacyjnym. Należy zauważyd, że w nowym wektorze czasu istotne znaczenie będzie miała teraz tylko pozycja , a wszystkie pozostałe mogą byd pominięte. W konsekwencji można też pominąd całą fazę rozgłaszania wartości . W tym wypadku procesy będą zapamiętywad stan lokalny, gdy uzyskają wektor z nową, powiększoną wartością pozycji . Algorytm można dalej uprościd zauważając, że w kontekście detekcji stanu globalnego znaczenie ma w istocie tylko zmiana stanu na pozycji , i stąd dwa stany tej pozycji są wystarczające dla rozróżnienia kolejnych faz wyznaczania obrazu globalnego: - przed zapamiętaniem stanu lokalnego procesu - po zapamiętaniu stanu lokalnego procesu Podobnie, kolory można przypisad pakietom. Kolor i pakietu oznacza, że został on wysłany, odpowiednio, przed lub po zapamiętaniu stanu lokalnego procesu. Monitory procesów wysyłają tylko pakiety koloru , a monitory procesów - tylko pakiety koloru . Każdy proces pierwotnie ma kolor , a staje się po zapamiętaniu jego stanu lokalnego a przed przekazaniem mu pierwszej wiadomości z pakietem koloru . Inicjator detekcji stanu globalnego zapamiętuje stan lokalny procesu, staje się i wysyła pusty pakiet koloru do wszystkich monitorów Wiadomości będące w wyznaczonym obrazie stanu globalnego w kanałach, to wiadomości w pakietach koloru odebrane przez monitor koloru . Za każdym razem, gdy monitor otrzymuje tego typu pakiet, przesyła zawartą w nim wiadomośd do inicjatora Poprawnośd algorytmu wynika z faktu, że nie istnieje pakiet wysłany przez monitor , którego wiadomośd przekazana zostałaby procesowi aplikacyjnemu koloru , gdyż taki pakiet spowodowałby zmianę koloru procesu odbierającego na przed przekazaniem wiadomości. Zakłada się, że inicjator nie inicjuje współbieżnie wielu detekcji, dlatego wprowadzenie większej liczby kolorów (wartości elementu czasu wektorowego) jest niekonieczne. Łatwo zauważyd, że algorytm staje się praktycznie identyczny jak wcześniej przedstawiony algorytmu Lai-Yanga. Różnicą jest jedynie prostsza reprezentacja stanu lokalnego, gdzie nie ma potrzeby pamiętania historii komunikacji, co jednak pociąga za sobą koniecznośd wprowadzenia dodatkowego mechanizmu wyznaczania stanów kanałów komunikacyjnych. Jedynym problemem w tym przypadku jest wyznaczenie momentu zakooczenia konstrukcji obrazu stanu globalnego- tzn. podjęcia przez inicjatora decyzji, że zebrany dotychczas stan jest stanem kompletnym i żaden z monitorów nie prześle w przyszłości pakietu koloru . Problem ten, znany jest jako problem detekcji zakooczenia przetwarzania rozproszonego. Algorytm kolorujący procesy i wiadomości Tak zmodyfikowany algorytm używa trzech zamiast pięciu typów komunikatów. Struktura tych typów jest identyczna jak poprzednio, z jednym wyjątkiem: pakiet typu PACKET zamiast etykiety czasu wektorowego posiada pole oznaczającego kolor pakietu ( , ). Również liczba używanych zmiennych jest mniejsza niż w poprzednim algorytmie, a główna różnica wynika z braku oraz oraz wprowadzenie zmiennej, zawierającej kolor procesu, . type PACKET extends FRAME is record of : enum : MESSAGE end record type PROC_STATE extends FRAME is record of : PROCESS_STATE end record type CHAN_STATE extends FRAME is record of : MESSAGE end record : MESSAGE /* wiadomośd aplikacyjna wypakowywana z odebranego przez monitor pakietu, która zostanie dostarczona procesowi aplikacyjnemu */ : PACKET /* monitor procesu opakowuje wiadomośd aplikacyjną i przesyła dalej jako */ : PACKET /* specjalny pakiet, zawierający pusty komunikat aplikacyjny, wysyłany przy rozpoczęciu algorytmu */ : PROC_STATE /* służy do przesyłania stanu procesu */ : CHAN_STATE /* służy do przesyłania stanu kanału */ : PROCESS_STATE : enum 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. when do end when when do end when when do if then end if if then 22. 23. 24. 25. 26. 27. 28. 29. 30. end if if then end if end when Algorytm Chandy-Lamporta dla kanałów FC Przypomnijmy, że kanały FC (patrz: Wykład #4) umożliwiają dobór operacji komunikacji i tym samym własności przesyłanych wiadomości, stosownie do wymaganego zastosowania. Użycie wyłączenie operacji powoduje, że kanał typu FC ma własności kanału FIFO Użycie tylko operacji , to kanał typu FC równoważny byłby kanałowi nonFIFO Zatem kanały typu FC są elastycznym mechanizmem, oferującym dobór operacji komunikacji i tym samym różne stopnie współbieżności komunikacji. Możliwa jest modyfikacja algorytmu Chandy-Lamporta, polegająca na zastąpieniu znacznika przysłanego kanałem FIFO, przez znacznik typu TF- TMARKER. Poza tym algorytm nie różni się istotnie od pierwowzoru. Algorytm Chandy-Lamporta dla kanałów FC Typy komunikatów używane w przedstawionym algorytmie nie różnią się od typów używanych w wersji algorytmu dla kanałów FIFO. Różnica polega na zastąpieniu typu MARKER typem TMARKER, będącego komunikatem typu TF (patrz: Wykład #4: Wyprzedzanie wiadomości). Zmienne używane w algorytmie posiadają znaczenie analogiczne do wcześniej przedstawionego algorytmu ChandyLamporta dla kanałów FIFO. type PACKET extends FRAME is record of : MESSAGE end record type TMARKER extends FRAME type STATE extends FRAME is record of : PROCESS_STATE : array of set of MESSAGE end record : MESSAGE : PACKET : TMARKER : STATE : array of BOOLEAN : array of set of MESSAGE : PROCESS_STATE : set of CHANNEL_ID : set of CHANNEL_ID : BOOLEAN 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. procedure for all do do end for end procedure /* Inicjator zapamiętuje spontanicznie stan skojarzonego z nim procesu aplikacyjnego i wysyła wiadomośd kontrolną (znacznik) typu TMARKER do wszystkich incydentnych monitorów. W odróżnieniu od wersji algorytmu dla kanałów FIFO, nie jest wysyłany stan za pomocą procedury SEND_STATE */ when do end when when do end when /* W przypadku otrzymania znacznika z kanału monitory sprawdzają, czy stan lokalny został już wcześniej zapamiętany. Jeśli okazuje się, że jest to pierwszy znacznik typu TMARKER odebrany w danym procesie konstrukcji obrazu spójnego, to stan lokalny jest zapamiętany przed dopuszczeniem do wysłania kolejnej wiadomości aplikacyjnej, a znacznik typu TMARKER wysyłany jest poprzez wszystkie kanały wyjściowe. Stan kanału przyjmuje się przy tym jako zbiór pusty. Jeżeli odebrano już znaczniki TMARKER z wszystkich kanałów wejściowych, rozsyłany jest stan procesu i kanałów do wszystkich pozostałych monitorów */ when do if then end if if then 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. end if end when /* Podczas odbioru wiadomości aplikacyjnej następuje sprawdzenie, czy stan lokalny był już zapamiętany. Jeżeli tak, to wszystkie wiadomości odebrane między momentem zapamiętania stanu, a momentem otrzymania znacznika są włączane do zbioru określającego stan kanału wejściowego */ when if do then end if end when Algorytm ze znacznikami BF I FF Koncepcja Rozwinięcie poprzedniego algorytmu opiera się na spostrzeżeniu, ze do utworzenia spójnego obrazu przetwarzania rozproszonego wystarczy, by stany lokalne zapamiętane były w wyniku odebrania znaczników typu BF (BMARKER, patrz: Wykład #4: Wyprzedzanie wiadomości). Znacznik ten nie może byd wyprzedzony przez żadną wiadomośd, i stąd pakiety wysłane po zapamiętaniu stanu i po wysłaniu znacznika typu BF dotrą do monitora docelowego z pewnością po zapamiętaniu stanu lokalnego adresata. Nie zaistnieje więc sytuacja, prowadząca do niespójnej konfiguracji, w której wiadomośd nieuwzględniona w stanie lokalnym przez nadawcę (wysłana po zapamiętaniu stanu) zostanie uwzględniona w stanie lokalnym odbiorcy (odebrana przed zapamiętaniem stanu). Znacznik typu FF (FMARKER) wysłany kanałem zaraz po zapamiętaniu stanu lokalnego procesu, nie wyprzedzi pakietów wysłanych przed nim. Jeśli zatem monitor będzie zapamiętywał wszystkie wiadomości otrzymane danym kanałem od momentu zapamiętania stanu do momentu odebrania znacznika FMARKER, to zbiór tych wiadomości obejmie wszystkie wiadomości tworzące stan kanału (wysłane przed znacznikiem, a odebrane po zapamiętaniu stanu procesu docelowego) oraz wiadomości wysłane po znaczniku FMARKER, które znacznik ten wyprzedził. Algorytm Wiadomości aplikacyjne typu PACKET zawierają pole , określające numer sekwencyjny komunikatu. Znaczniki FMARKER, będące komunikatami typu FF, zawierają pole , określające numer sekwencyjny poprzedniego pakietu. Znaczniku typu BMARKER to komunikaty typu BF. Wreszcie pakiet STATE posiada identyczne znaczenie, jak poprzednio. type PACKET extends FRAME is record of : INTEGER : MESSAGE end record type FMARKER extends FRAME is record of : INTEGER end record type BMARKER extends FRAME type STATE extends FRAME is record of : PROCESS_STATE : array of set of MESSAGE end record : MESSAGE : PACKET : TMARKER /* pakiet typu FMARKER */ : TMARKER /* pakiet typu BMARKER */ : STATE : array of set of PACKET /* zapamiętuje zbiór pakietów odebranych od momentu zapamiętania stanu przez monitor do momentu otrzymania znacznika FMARKER od */ : array of BOOLEAN : array of set of MESSAGE : PROCESS_STATE : set of CHANNEL_ID : set of CHANNEL_ID : BOOLEAN : INTEGER /* numer sekwencyjny ostatnio wysłanego pakietu przez monitor */ 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. procedure for all do do end for end procedure /* Inicjator zapamiętuje spontanicznie stan skojarzonego z nim procesu aplikacyjnego i wysyła wiadomośd kontrolną (znacznik) typu TMARKER do wszystkich incydentnych monitorów. W odróżnieniu od wersji algorytmu dla kanałów FIFO, nie jest wysyłany stan za pomocą procedury */ when do 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. end when when if do then end if end when /* Monitor , który już zapisał swój stan, otrzymując zwykły pakiet aplikacyjny od monitora , od którego nie otrzymano dotąd znacznika FMARKER, dopisuje otrzymany pakiet do zbioru na odpowiedniej pozycji tablicy */ when do if then end if end when /* Otrzymanie znacznika typu FMARKER nadesłanego przez monitor powoduje zapisanie tego faktu w tablicy poprzez nadanie -temu elementowi wartości . Następnie opróżniana jest odpowiednia -ta pozycja tablicy , po czym dodane są do niej wszystkie takie pakiety z -tego wpisu tablicy, których numer sekwencyjny jest niewiększy niż numer sekwencyjny z pola nadesłanego znacznika. Jeżeli znacznik typu FMARKER otrzymano już wszystkimi kanałami wejściowymi, rozsyłany jest stan procesu */ when do for all if do then end if end for if then end if end when /* Wysyłając wiadomośd aplikacyjną, monitor inkrementuje zawartośd licznika oraz dołącza go do wysyłanego pakietu obudowującego tą wiadomośd */ when do 46. 47. 48. end when Niedeterminizm przetwarzania rozproszonego Poniżej widzimy różne realizacje przetwarzania rozproszonego klient-serwer jako wynik nieprzewidywalnych czasów transmisji. Załóżmy istnienie dwóch procesów i , żądające realizacji usługi przez dwa serwery i . Proces jest przy tym repliką procesu . Przyjmijmy ponadto, że dla prawidłowego działania procesów użytkowych muszą one korzystad z obu serwerów w trybie wzajemnego wykluczania. Aby to osiągnąd, każdy z procesów i wysyła komunikaty zawierające żądania, odpowiednio do obu serwerów, w celu uzyskania wyłącznego do nich dostępu. Ponieważ zdarzenia wysyłania żądao są współbieżne, a kanały wnoszą nieprzewidywalne opóźnienia, żądania mogą dotrzed do serwerów w różnej kolejności. Jeśli przyjmiemy jeszcze, że procesy i mogą kontynuowad działanie dopiero po otrzymaniu potwierdzeo od obu procesów i , skutki niedeterminizmu transmisji mogą byd bardzo istotne. Na górnej części rysunku, w chwili (po zakooczeniu przesyłania wszystkich wiadomości) został osiągnięty pewien stan , w którym proces może kontynuowad działanie, a proces oczekuje na zwolnienie serwerów przez . Stan ten można uznad za poprawny. Natomiast w dolnej części rysunku widzimy osiągnięcie pewnego stanu , w którym proces otrzymał potwierdzenie od , a proces otrzymał potwierdzenie od . Dla każdego z procesów i z osobna, otrzymane potwierdzenia nie są wystarczające do kontynuacji działania i dalej zwolnienia potwierdzonych serwerów. Zauważmy też, że jeżeli inne, zewnętrzne w stosunku do , procesy nie wymuszą na lub zwolnienia serwerów, to wówczas zarówno serwery, jak i procesy żądające usług pozostaną zablokowane. W rozważanym przykładzie, wykrycie wystąpienia stanu , odpowiadającego trwałej blokadzie wszystkich procesów, miałoby na celu zainicjowanie specjalnych działao prowadzących do osiągnięcia stanu, w którym dalsze poprawne przetwarzanie byłoby możliwe. Wykład #9, 10: Problem detekcji zakończenia Plan wykładu: a) b) c) d) e) f) g) h) i) j) Problem zakooczenia- przykłady Definicje zakooczenia Zakooczenie dynamiczne i statyczne Detekcja zakooczenia dla synchronicznego modelu przetwarzania Detekcja zakooczenia dla dyfuzyjnego modelu przetwarzania Algorytm z licznikami wiadomości Jednofazowy algorytm detekcji zakooczenia Wektorowy algorytm detekcji zakooczenia Detekcja zakooczenia statycznego Detekcja zakooczenia dynamicznego Problem detekcji zakooczenia został wstępnie omówiony w wykładzie #1 (patrz: sortowanie). Przykład ilustrujący potrzebę poprawnej detekcji zakończenia W celu ilustracji problemu detekcji zakooczenia wrócimy ponownie do wcześniej omawianego algorytmu Matterna konstrukcji spójnego obrazu stanu globalnego w środowisku z kanałami nonFIFO (patrz: Wykład #8). Ze względu na możliwe zmiany uporządkowania wiadomości w kanałach otrzymanie wiadomości koloru nie przesądzało o tym, że w kanałach nie ma już wcześniej wysłanych wiadomości koloru . Ponieważ jednak zbiór otrzymanych przez proces koloru wiadomości określa stan kanału w wyznaczanym obrazie stanu globalnego, niezbędne jest niezależne od procesu konstrukcji obrazu stanu globalnego sprawdzenie, czy w kanałach nie ma jeszcze wiadomości koloru . Dopiero bowiem wówczas, gdy stwierdzimy, że wszystkie wiadomości koloru zostały odebrane, wyznaczone stany kanałów odpowiadają spójnemu obrazowi stanu globalnego. Definicja zakończenia Definicja nieformalna zakończenia Nieformalnie problem detekcji zakooczenia przetwarzania rozproszonego polega na sprawdzeniu, czy wszystkie procesy przetwarzania są w stanie pasywnym oraz, czy żadna wiadomośd będąca w kanale (transmitowana lub dostępna) nie uaktywni któregokolwiek z tych procesów. Przez proces aktywny rozumiemy tutaj wykonujący kroki algorytmu; w przeciwnym wypadku uznajemy go za pasywny. Dokładne definicje zostały przedstawione na wcześniejszych wykładach. Przez zakooczenie obliczeo rozproszonych mamy tutaj na myśli osiągnięcie pewnej koocowej konfiguracji, w której nie są już możliwe dalsze kroki algorytmu. Definicja formalna zakończenia W formalnej definicji tego problemu wykorzystane są następujące oznaczenia: - zmienna logiczna (predykat), przyjmująca wartośd wtedy i tylko wtedy, gdy proces jest pasywny - tablica zmiennych logicznych procesu skojarzona z wiadomościami dostępnymi - -ty element tablicy dostępna wiadomośd wysłana przez - tablica zmiennych logicznych procesu skojarzona z wiadomościami transmitowanymi - -ty element tablicy , przyjmujący wartośd , gdy wiadomośd wysłana przez do należy do zbioru , a więc jest transmitowana i nie , przyjmujący wartośd , gdy dla jest jest jeszcze dostępna Zakończenie dynamiczne Nieformalnie, przetwarzanie rozproszone jest w danej chwili w stanie zakooczenia dynamicznego, jeżeli żaden proces składowy przetwarzania rozproszonego nie będzie już nigdy uaktywniony. Stan ten będzie utrzymywany pomimo, że pewne wiadomości są wciąż transmitowane, a pewne wiadomości są już dostępne. Przetwarzanie rozproszone jest poniższy predykat: jest w danej chwili w stanie zakooczenia dynamicznego, gdy spełniony Predykat ten oznacza, że żaden proces składowy przetwarzania rozproszonego nie będzie już nigdy uaktywniony. Stan ten będzie utrzymywany pomimo, że pewne wiadomości są wciąż transmitowane , a pewne wiadomości są już dostępne . Takie sformułowanie definiującego stan zakooczenia jest interesujące z praktycznego punktu widzenia, gdyż pozwala stwierdzid zakooczenie przetwarzania nawet przed dotarciem wszystkich wiadomości do procesów (węzłów) docelowych. Definicja zakooczenia dynamicznego uwzględnia rzeczywistą aktywnośd procesów wyrażoną przez zmienną oraz potencjalną aktywnośd wyrażoną przez predykat . Predykat jest predykatem stabilnym. Zakończenie statyczne Przetwarzanie rozproszone jest w danej chwili w stanie zakooczenia statycznego, jeżeli: a) wszystkie procesy składowe są pasywne ( ) b) wszystkie wiadomości w kanałach są dostępne ( ) c) dla żadnego procesu nie jest spełniony warunek uaktywnienia (patrz: Wykład #5,6) ( ) Przetwarzanie rozproszone predykat: jest w danej chwili w stanie zakooczenia statycznego, gdy spełniony jest Oznaczenia w powyższym wzorze wprost odpowiadają wcześniej podanej definicji. Definicja ta uwzględnia zatem zarówno stany procesów, jak i kanałów. Porównując z , predykat odpowiada detekcji nieco późniejszej, gdyż dodatkowo wymaga się, by wiadomości nie były już transmitowane. Niech oznacza, że zajście predykatu prowadzi w skooczonym, chod nieprzewidywalnym, czasie do zajścia predykatu . Twierdzenie 14 Klasyczna definicja zakończenia W klasycznej definicji zakooczenia przyjmowano, że przetwarzanie rozproszone jest w stanie zakooczenia, jeżeli w danej chwili wszystkie procesy są pasywne i wszystkie kanały są puste, a więc gdy zachodzi następujący predykat: Rozważmy teraz relację między ,a . Twierdzenie 15 Jeżeli procesy są natychmiastowo uaktywnione przez każdą dostępną wiadomośd, to przetwarzanie rozproszone, obejmujące zbiór procesów jest statycznie zakooczone wtedy i tylko wtedy, gdy zachodzi predykat . Problem detekcji zakończenia Problem detekcji zakooczenia przetwarzania rozproszonego, obejmującego zbiór procesów, sprowadza się do sprawdzenia, czy przetwarzanie osiągnęło określony stan zakooczenia, a więc, czy zachodzi odpowiedni predykat: , , . Można dowieśd, że jeżeli w czasie przetwarzania aplikacyjnego wymienianych jest wiadomości, to niemożliwa jest konstrukcja algorytmu detekcji zakooczenia o złożoności komunikacyjnej mniejszej niż . Model przetwarzania synchronicznego W modelu przetwarzania synchronicznego przyjmuje się, że transmisje są natychmiastowe. Stąd kanały mogą byd uznane za puste przez cały czas i problem zakooczenia sprowadza się do sprawdzenia, czy wszystkie procesy są jednocześnie pasywne. Stan zakooczenia opisuje zatem następujący predykat: Detekcja zakończenia dla modelu synchronicznego Zostanie obecnie omówiony algorytm autorstwa Dijkstry, Feijen oraz van Gasterena detekcji zakooczenia dla modelu przetwarzania synchronicznego. Wykorzystuje on koncepcję ciągu cykli detekcyjnych i zakłada, że wszystkie monitory procesów aplikacyjnych połączone są w logiczny pierścieo i obserwują stany procesów aplikacyjnych. Monitorom (procesom) przypisany jest kolor lub Monitory przesyłają wzdłuż pierścienia wiadomośd kontrolną- znacznik typu TOKEN, który również może mied kolor lub Początkowo monitory mają kolor , a zmieniają go na , gdy odpowiadający im proces aplikacyjny wyśle wiadomości do procesu o indeksie większym Monitor inicjujący detekcję zakooczenia wysyła znacznik koloru do swego następnika w pierścieniu , jeżeli obserwowany przez niego proces aplikacyjny jest pasywny Każdy kolejny monitor , odbierający znacznik czeka aż obserwowany przez niego proces stanie się pasywny i wówczas wysyła znacznik o kolorze zgodnym z kolorem monitora. Po wysłaniu znacznika monitorowi (procesowi) przypisywany jest kolor Algorytm kooczy się, gdy znacznik koloru dotrze do inicjatora. Dla uproszczenia prezentacji, w algorytmie wykorzystano funkcje: Przykład detekcji zakończenia Runda zakooczona niepowodzeniem Inicjator (proces ) przesyła znacznik koloru do swojego następnika- . Następnie znacznik ten jest przesyłany w pierścieniu do kolejnego procesu- . Oba te procesy posiadają przypisany kolor , a więc były pasywne w bieżącej rundzie detekcji. Znacznik nie zmienia zatem swojego koloru i pozostaje . Tymczasem proces wysyła wiadomośd aplikacyjną do procesu , co powoduje zmianę jego koloru na . Kiedy więc znacznik dociera od procesu do , zmienia on swój kolor na . Po przejściu całego pierścienia znacznik powraca do inicjatora. Ponieważ znacznik przyjął kolor , detekcja zakooczenia nie została uwieoczona powodzeniem. Kolejna iteracja jest potrzebna w algorytmie detekcji zakooczenia. Runda zakooczona sukcesem Monitor po otrzymaniu znacznika koloru zmienia swój kolor na i ponownie wysyła znacznik o kolorze do swojego następnika w pierścieniu. Sytuacja jest podobna jak poprzednio- znacznik jest przesyłany między procesami od inicjatora , do jego następnika , dalej do . W tym momencie proces wysyła wiadomośd do procesu - nie powoduje to jednak zmiany koloru przypisanego do procesu, gdyż indeks adresata wiadomości jest mniejszy niż indeks nadawcy. Kiedy więc znacznik dociera do procesu , jego kolor się nie zmienia i dalej jest przesyłany również z przypisanym kolorem . Ostatecznie znacznik dociera do inicjatora detekcji, a ponieważ jego kolor pozostaje , inicjator może stwierdzid wykrycie zakooczenia. Algorytm Dijkstra, Feijen, van Gasteren Algorytm wykorzystuje pakiety dwóch typów: pierwszy typ- PACKET- opakowuje wiadomości aplikacyjne. Drugi typ- TOKEN- znacznik posiadający pole , oznaczające kolor znacznika. type PACKET extends FRAME is record of : MESSAGE end record type TOKEN extends FRAME is record of : enum end record : MESSAGE : PACKET : TOKEN : BOOLEAN procesie /* określa obecnośd znacznika w */ : enum : BOOLEAN 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. /* Procedura wywoływana jest przez monitor procedure do ( ) podczas inicjacji kolejnej rundy */ end procedure /* Inicjator wysyła znacznik koloru (wywołując procedurę ) do swego następnika w pierścieniu jeżeli obserwowany przez niego proces aplikacyjny jest pasywny */ when do wait until end when /* Monitor zmienia kolor na jeżeli obserwowany przez niego proces aplikacyjny wysyła wiadomośd aplikacyjną do procesu o wyższym indeksie */ when do if then 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. end if end when when do end when /* Odebranie znacznika przez proces wysłanego przez jego następnika w pierścieniu , powoduje ustawienie zmiennej na . Znacznik jest zatrzymywany w monitorze do czasu aż obserwowany przez niego proces aplikacyjny stanie się pasywny. Jeżeli i kolor zarówno obserwowanego procesu, jak i znacznika są , inicjator kooczy algorytm, decydując o wykryciu zakooczenia. Jeżeli , ale albo kolor procesu, albo kolor znacznika równy jest , inicjator rozpoczyna kolejną rundę algorytmu. Jeżeli zaś , to następuje przesłanie dalej znacznika o kolorze takim samym jak kolor obserwowanego procesu aplikacyjnego, następnie zmienia kolor procesu na oraz zmienia wartośd na wartośd */ when do wait until if then if then else end if else if then end if end if end when Model przetwarzania dyfuzyjnego Przetwarzanie dyfuzyjne (ang. diffusing computation) rozproszonym, w którym wyróżnia się: jest specyficznym przetwarzaniem inicjatora- może w dowolnej chwili rozpocząd przetwarzanie dyfuzyjne, wysyłając wiadomośd aplikacyjną do jednego lub wielu procesów kooperujących (zakłada się, że inicjacja taka zachodzi tylko raz) hierarchię kooperujących procesów Każdy proces po uzyskaniu pierwszej wiadomości aplikacyjnej, nadawcę tej wiadomości traktuje jako proces angażujący (ang. engager) i realizuje dalsze przetwarzanie, wysyłając wiadomości do innych procesów, w tym ewentualnie do inicjatora. Dla ułatwienia opisu przedstawionych poniżej algorytmów, przyjmiemy pewne dodatkowe założenia: proces aktywny staje się procesem pasywnym tylko w wyniku pewnego zdarzenia wewnętrznego proces zawsze staje się aktywny po otrzymaniu wiadomości proces pasywny może stad się aktywny tylko w wyniku otrzymania wiadomości Innymi słowy, proces aplikacyjny może w dowolnej chwili stad się pasywny i oczekiwad na uaktywniającą go wiadomośd aplikacyjną od dowolnego innego procesu. Warunek uaktywnienia procesu definiuje zatem model żądao OR i zbiór warunkujący . Algorytm Dijkstry-Scholten’a Koncepcja algorytmu Monitory procesów aplikacyjnych przesyłają wiadomości kontrolne typu SIGNAL jako pewnego rodzaju odpowiedzi na wiadomości aplikacyjne Monitor pasywnego inicjatora może stwierdzid zakooczenie przetwarzania po odebraniu wiadomości kontrolnych typu SIGNAL od wszystkich monitorów związanych z procesami uaktywnionymi przez inicjatora Graf przetwarzania dyfuzyjnego Inicjatorem przetwarzania dyfuzyjnego w przedstawionym przykładzie jest proces . Staje się on procesem angażującym dla procesów . Każdy z nich z kolei sam angażuje kolejne procesy. Procesy tworzą więc drzewo, a wiadomości są przesyłane od inicjatora (korzenia drzewa) w dół (do liści). Procesy odsyłają specjalne wiadomości, poczynając od liści drzewa. Każdy proces- węzeł drzewa przesyła wiadomośd do swojego procesu angażującego, jeśli zebrał już wiadomości od wszystkich procesów potomnych. W momencie, w którym inicjator zbierze wszystkie wiadomości od swoich procesów potomnych, może uznad, że zostało wykryte zakooczenie przetwarzania. Algorytm detekcji zakończenia dla modelu dyfuzyjnego Algorytm wykorzystuje pakiety dwóch typów: pierwszy, typ PACKET, opakowuje wiadomości aplikacyjne, natomiast drugi typ, SIGNAL, to specjalna wiadomośd kontrolna przesyłana między monitorami. Zmienna zawiera identyfikator monitora, którego proces uaktywnił . Z kolei zbiór oznacza zbiór monitorów różnych od monitora angażującego, od których odebrano pakiet. Zmienne oraz oznaczają, odpowiednio, liczbę wiadomości odebranych bądź wysłanych przez proces , a niepotwierdzonych jeszcze przez wiadomością typu SIGNAL. type PACKET extends FRAME is record of : MESSAGE end record type SIGNAL extends FRAME : MESSAGE : PACKET : SIGNAL : PROCESS_ID : set of PROCESS_ID : INTEGER : INTEGER : BOOLEAN 1. /* Przetwarzanie dyfuzyjne jest inicjowane przez proces , który wysyła wiadomości do swoich bezpośrednich potomków w hierarchii należących do zbioru . Zmienna zawiera liczbę tych wysłanych wiadomości */ when do 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. end when /* Zdarzenie wysłania wiadomości typu SIGNAL może zajśd dla monitora spełniony jest warunek tylko wtedy, gdy . Monitor , wysyłając wiadomośd typu SIGNAL, sprawdza, czy odebrał już wiadomości od wszystkich procesów poza angażującym ( ), nie wysłał żadnej niepotwierdzonej wiadomości ( ), a skojarzony zeo proces jest pasywny. W takim wypadku wysyła procesowi angażującemu sygnał. W przeciwnym wypadku wysyła wiadomośd kontrolną typu SIGNAL do wszystkich monitorów procesów, od których otrzymał jakąś wiadomośd i jeszcze jej nie potwierdził do tej pory wiadomością SIGNAL, poza monitorem procesu angażującego i usuwa te procesy ze zbioru . Wreszcie dekrementuje zmienną */ when do if then else for do 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. end for end if end when /* Monitor , odbierając sygnał, dekrementuje zmienną (gdyż zmienna ta oznacza ilośd niepotwierdzonych wysłanych wiadomości). Jeżeli , to w momencie, w którym skojarzony proces aplikacyjny stanie się pasywny, monitor decyduje o wykryciu zakooczenia przetwarzania */ when do if then wait until end if end when /* Zdarzenie wysłania wiadomości aplikacyjnej może zajśd dla monitora wtedy, gdy */ when do dla tylko 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. end when /* W przypadku otrzymania wiadomości, jeżeli jest to pierwsza otrzymana wiadomośd ( ), to monitor uznaje nadawcę za proces angażujący, a w przeciwnym wypadku dodaje go do zbioru */ when do if then else end if end when Twierdzenie 16 Jeżeli przetwarzanie dyfuzyjne uległo zakooczeniu, to fakt ten stwierdzi algorytm DijkstryScholtena. Model przetwarzania asynchronicznego Dla systemów asynchronicznych (patrz: Wykład #2: Komunikacja asynchroniczna) można wykorzystad w celu detekcji zakooczenia algorytm Misra z roku 1983, który nie czyni żadnych założeo, co do topologii przetwarzania i czasy przesyłania. Algorytm ten wymaga natomiast, by żadne niewiadomości nie były gubione podczas transmisji (niezawodnośd komunikacji) oraz by kanały komunikacyjne zachowywały porządek wysyłania wiadomości (kanały FIFO). Algorytm ten, podobnie jak przedstawiony wcześniej algorytm dla modelu synchronicznego (Dijkstra, Feijen, van Gasteren) używa znacznika, a także kolorowania procesów. Dla ułatwienia analizy, można przyjąd, że topologia przetwarzania to graf pełny, jednakże algorytm łatwo można dostosowad do dowolnej topologii, co zostanie pokazane później. Algorytm detekcji zakończenia dla systemów asynchronicznych Algorytm wykorzystuje dwa typy wiadomości: PACKET i TOKEN. Drugi z nich oznacza specjalną wiadomośd kontrolną- znacznik- przesyłana między monitorami, zawierające pole , które oznacza z kolei liczbę procesów odwiedzonych przez znacznik, które były pasywne. Zmienna oznacza następnik procesu w cyklu, obejmującym wszystkie kanały komunikacyjne. Związane jest to z wymaganiem, by znacznik typu TOKEN odwiedził wszystkie kanały łączące procesy. to zbiór wszystkich kanałów, tworzących cykl, obejmujący wszystkie kanały komunikacyjne. type PACKET extends FRAME is record of : MESSAGE end record type TOKEN extends FRAME is record of : INTEGER end record : MESSAGE : PACKET : TOKEN : BOOLEAN : PROCESS_ID : set of CHANNEL_ID : enum : BOOLEAN 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. /* określa kolor monitora */ /* Zaczynając detekcję, proces wysyła znacznik do swojego następnika w cyklu, przypisując polu tego znacznika wartośd 0 */ when do end when /* Otrzymanie wiadomości aplikacyjnej przez monitor powoduje, poza uaktywnieniem procesu i dostarczeniem wiadomości, zmianę koloru procesu na */ when do end when /* Po otrzymaniu znacznika, monitor przesyła go dalej w momencie, gdy obserwowany przez niego proces staje się pasywny. Jeżeli proces ma kolor , pole znacznika jest zerowane. W przeciwnym razie jest ono inkrementowane. Kolor procesu następnie jest ustawiany na oraz monitor przesyła znacznik do swojego następnika w cyklu. Oznacza to, że każdy proces musi pozostad pasywny pomiędzy wszystkimi odwiedzinami znacznika, a znacznik musi co najmniej dwa razy przejśd cykl */ when do wait until if else end if end when then 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. /* Inicjator przetwarzania, po otrzymaniu znacznika, jeżeli kolor procesu posiada wartośd oraz jeżeli wartośd zapisana w polu otrzymanego znacznika równa jest liczbie kanałów komunikacyjnych (liczbie krawędzi grafu topologii przetwarzania), decyduje o wykryciu zakooczenia. W przeciwnym wypadku przesyła znacznik dalej, byd może zerując wartośd pola nb w podobny sposób, jak każdy inny proces. Warte podkreślenia jest, że w ogólności każdy monitor, a nie tylko inicjator może dokonad decyzji o wykryciu zakooczenia, obserwując wartośd pola oraz kolor obserwowanego przez siebie procesu */ when do if then else if then else end if end if end when /* Zdarzenie wysłania wiadomości aplikacyjnej może zajśd dla monitora wtedy, gdy */ when dla tylko do end when Cechy algorytmu Misra Możliwośd rozszerzenia do dowolnej topologii Aby dostosowad przedstawiony algorytm do dowolnej topologii, wystarczy ustawid odpowiednio wartości zmiennej - wystarczy podzielid graf topologii przetwarzania na zbiór cykli o maksymalnej długości i odwiedzad je po kolei. Wiele monitorów naraz może wykrywad zakooczenia W tym celu należy dodad do znacznika pole wskazujące na inicjatora detekcji. Cykle obejmujące kanały komunikacyjne muszą byd znane z góry Należy podkreślid, że jest to duża wada powyższego algorytmu. Model atomowy przetwarzania W atomowym modelu przetwarzania, czasy przetwarzania lokalnego są zaniedbywane (zerowe), a opóźnienia są związane tylko z transmisją. Można przyjąd, że procesy (uaktywniane natychmiastowo) są przez cały czas pasywne i sprowadzid problem detekcji zakooczenia do wyznaczania stanów kanałów. Przyjmijmy dla uproszczenia, model żądao typu OR (patrz: Wykład #2: Model żądao OR). Oznacza to, że dowolna wiadomośd w kanale uaktywni proces. Wówczas zakooczenie przetwarzania opisuje następujący predykat: Algorytm z licznikami wiadomości Matterna - liczba wiadomości wysłanych do chwili przez - liczba wiadomości odebranych do chwili przez - sumaryczna liczba wiadomości wysłanych przez wszystkie procesy do chwili - sumaryczna liczba wiadomości odebranych przez wszystkie procesy do chwili Dla modelu przetwarzania atomowego, równośd oznacza, że każda wiadomośd wysłana została odebrana. Tym samym wszystkie kanały są w chwili puste, a więc osiągnięty został stan zakooczenia. Problem polega na tym, że wyznaczenie oraz nie jest w systemie rozproszonym proste. Koncepcja Wiadomośd kontrolna wysłana przez inicjatora przesyłana jest między monitorami, a po dotarciu do wszystkich monitorów wraca do Celem wysłania wiadomości kontrolnej jest wyznaczenie sumarycznej liczby wiadomości wysłanych i odebranych przez wszystkie procesy aplikacyjne Każdy z monitorów dodaje do znacznika stany liczników i , odpowiadające bieżącej chwili Ponieważ kanały wprowadzają opóźnienia, zebrane liczniki odpowiadają różnym momentom , W swej idei, algorytmy detekcji z użyciem liczników zakooczenia wykorzystują koncepcję ciągu cykli detekcyjnych. W tym jednak wypadku celem wysłania wiadomości kontrolnej jest wyznaczenie sumarycznej liczby wiadomości wysłanych i odebranych przez wszystkie procesy aplikacyjne. Dlatego wiadomośd kontrolna wysłana przez inicjatora przesyłana jest pomiędzy monitorami, a następnie wraca do monitora . Oznaczmy przez pamiętając, że: i odpowiednio sumy zebranych przez znacznik liczników, a więc: Dla zilustrowania przedstawionej koncepcji rozważmy obecnie dwa przykłady przedstawione poniżej. Na przykładzie po lewej stronie, proces detekcji rozpoczynany jest w chwili przez monitor procesu . W chwili tej oraz . Znacznik jest przesyłany następnie do monitora procesu , który odczytuje wartości oraz . Następnie, kolejno wyznaczane są wartości: oraz , i . W efekcie w chwili otrzymujemy ,a . Z kolei sytuacja na przykładzie po prawej stronie jest następująca: , , , , , , , . Tym samym ,a . Równośd liczników wiadomości wysłanych i odebranych mogłoby sugerowad, że wszystkie kanały są puste, i że tym samym wystąpiło zakooczenie. Zauważmy jednak, że w żadnym momencie z przedziału obserwacji kanały nie są jednocześnie puste, a więc dla każdego , . Powstaje zatem problem, czy i kiedy na podstawie faktu, że można wnioskowad o wystąpienie zakooczenia. Poprawność algorytmu detekcji zakończenia dla atomowego modelu przetwarzania W algorytmie detekcji zakooczenia rozważane są dwie fazy detekcji. Pierwsza rozpoczyna się o chwili i kooczy w chwili , a druga odpowiednio w chwilach i . Przyjęto ponadto, że: Oznaczmy teraz przez i oznaczone w drugiej fazie. liczniki wyznaczone w pierwszej fazie, a przez i liczniki Twierdzenie 17 Jeżeli to monitorowane przetwarzanie aplikacyjne osiągnęło stan zakooczenia przed zakooczeniem procesu detekcji. Dowód: W celu udowodnienia powyższego twierdzenia wykażemy, że jeżeli , to przetwarzanie jest w stanie zakooczenia. W tym wykażemy w dalszym ciągu prawdziwośd pięciu lematów. Lemat 1 Lokalne liczniki wiadomości są monotoniczne, zatem jeżeli , to Lemat 2 Sumaryczna liczba wiadomości wysłanych lub odebranych jest monotoniczna. Jeżeli zatem , to Lemat 3 Dowód powyższego lematu przedstawia się następująco: Z definicji mamy , przy czym dla każdego , . Z kolei . Ponieważ z lematu pierwszego wynika, że liczniki są monotoniczne i dla każdego zachodzi , więc tym samym dla każdego , a w konsekwencji: Lemat 4 Dowód powyższego lematu przedstawia się następująco: Z definicji , przy czym dla każdego , . Z kolei . Z lematu pierwszego wynika, że liczniki są monotoniczne i dla każdego , , stąd zachodzi dla każdego , a w konsekwencji: Lemat 5 Dla wszystkich zachodzi: * Dowód: Relacja jest prawdziwa, gdyż kanały są z założenia niezawodne. Wródmy do dowodu twierdzenia 17. Z założenia wynika, że lematów otrzymujemy, że: . Z kolei z przedstawionych * gdzie: wynika z lematu 4, - z lematu 3. - z lematu 2, - z lematu 5, zaś Relacje * i * zachodzą jednocześnie tylko wówczas, gdy: Tym samym w chwili , wystąpiło zakooczenie przetwarzania. , a to z kolei oznacza, że wszystkie kanały są puste, a więc Jednofazowy algorytm detekcji zakończenia Wadą poprzedniego rozwiązania jest koniecznośd dwukrotnego przesyłania wiadomości kontrolnej do wszystkich procesów. Istnieją propozycje realizacji detekcji zakooczenia w jednym przebiegu, czyli algorytmy jednofazowe. Załóżmy, że monitory dla połączone są w logiczny pierścieo. Ideą rozwiązania jest przesyłanie wiadomości kontrolnej (znacznika) typu TOKEN między kolejnymi monitorami, zawierającego informacje ewentualnie wystarczające inicjatorowi do podjęcia decyzji o wykryciu zakooczenia. Algorytm: W algorytmie detekcji zakooczenia przetwarzania rozproszonego przesyłana jest wiadomośd kontrolna (znacznik) typu TOKEN między kolejnymi monitorami. Wiadomośd ta zawiera: Identyfikator inicjatora Numer sekwencyjny cyklu detekcji zainicjowanego przez Pole , czyli sumy liczników monitorów odwiedzonych już przez znacznik Pole flagi niepoprawności procesu detekcji . Flaga ta przyjmuje ostatecznie wartośd , jeżeli którykolwiek proces aplikacyjny otrzymał między kolejnymi cyklami detekcji wiadomośd, która narusza warunek konieczny poprawności detekcji: , gdzie liczba oznacza numer sekwencyjny cyklu detekcji skojarzony z wiadomością wysłaną najpóźniej, spośród wszystkich wiadomości odebranych przez . Z kolei wiadomości aplikacyjne typu PACKET zawierają dodatkowo pole numer sekwencyjny cyklu detekcji. , zawierające Algorytm wykorzystuje następujące zmienne: - lokalny licznik (ang. send-receive balance) o początkowej wartości 0. Wartośd licznika w każdej chwili jest równa . - numer sekwencyjny cyklu detekcji zakooczenia, zainicjowanego przez monitor - zmienna, określająca numer sekwencyjny cyklu detekcji zakooczenia skojarzony z wiadomością wysłaną najpóźniej, spośród wszystkich wiadomości odebranych przez type PACKET extends FRAME is record of : INTEGER : MESSAGE end record type TOKEN extends FRAME is record of : PROCESS_ID : INTEGER : INTEGER : BOOLEAN end record : MESSAGE : PACKET : TOKEN : INTEGER : INTEGER : INTEGER : BOOLEAN 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. /* Inicjator detekcji inkrementuje licznik cyklu detekcji oraz wysyła znacznik do swojego następnika w pierścieniu. Początkowe wartości pól , , oraz w znaczniku są ustawiane na, kolejno, identyfikator monitora , numer cyklu detekcji, sumę liczników oraz */ when do end when /* Przesyłając wiadomośd aplikacyjną monitor inkrementuje zmienną przypisuje jej numer cyklu detekcji zakooczenia */ when do oraz end when /* Otrzymując wiadomośd aplikacyjną, monitor dekrementuje licznik . Jeżeli wartośd numeru cyklu detekcji przesłana w otrzymanej wiadomości aplikacyjnej jest większa niż bieżąca wartośd , to zmiennej przypisana zostaje właśnie ta wartośd */ when do end when /* W każdym odwiedzanym monitorze uaktualniany jest numer sekwencyjny bieżącego cyklu detekcji. Jeżeli , to inicjator decyduje, że wykryte zostało zakooczenie, jeżeli wartośd pola jest równa zero i równocześnie flaga nie ma przypisanej wartości . Jeżeli znacznik powrócił do inicjatora, ale nie może on podjąd decyzji o zakooczeniu detekcji, to rozpoczyna on nowy cykl detekcyjny */ 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. when do if then if then else end if else end if end when Dla monitorów w powyższej funkcji, fladze przypisywana jest suma logiczna bieżącej wartości tej flagi oraz wartości relacji , która jest prawdziwa, jeżeli do monitora dotarł już pewien pakiet z etykietą o wartości większej lub równej numerowi sekwencyjnemu bieżącego cyklu detekcji . Oznacza to, że pakiet ten został wysłany po wizycie bieżącego znacznika. Zauważmy, że zdarzenie odbioru pakietu będzie uwzględnione w koocowej wartości licznika , a nie będzie uwzględnione zdarzenie nadania tego pakietu. Tym samym, konkluzja dotycząca zakooczenia przetwarzania byłaby formułowana na podstawie niespójnego obrazu przetwarzania, a więc w ogólności byłaby niepoprawna. W takim wypadku, wynik bieżącego cyklu detekcji należy zatem uznad za niepoprawny. W efekcie wykrycie zakooczenia wymaga wykonania kolejnego cyklu detekcji. Wektorowy algorytm detekcji zakończenia Przedstawiony zostanie obecnie algorytm, wykorzystujący wektor liczników , będący tablicą . Przyjęto przy tym, że procesy nie komunikują się same ze sobą, a monitory tworzą strukturę o topologii pierścienia. Algorytm: Cyrkulujący w pierścieniu znacznik typu TOKEN przenosi -elementowy wektor , zawierający sumę wektorów monitorów odwiedzonych już w danym cyklu detekcji przez znacznik. Dodatkowo algorytm wykorzystuje m.in. następujące zmienne: - wektor liczników, będący tablicą . Elementy , dla , każdego procesu określają liczbę wiadomości wysłanych przez proces do od czasu ostatniej wizyty znacznika. Wartośd bezwzględna elementu określa liczbę wiadomości odebranych przez od czasu ostatniej wizyty znacznika. W dowolnej chwili , suma -tych elementów wszystkich liczników , dla każdego oraz wartości pozycji wektora cyrkulującego znacznika , jest równa liczbie wiadomości, będących w drodze do . Zmienna przyjmuje wartośd , jeżeli monitor pierwszy raz otrzymał znacznik. type PACKET extends FRAME is record of : MESSAGE end record type TOKEN extends FRAME is record of : array of INTEGER : MESSAGE end record : MESSAGE : PACKET : TOKEN : array : BOOLEAN : BOOLEAN 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. of INTEGER /* Inicjator detekcji rozpoczyna detekcję, wysyłając znacznik typu TOKEN z wektorem oraz ustawiając wartośd zmiennej na */ when do for all do end for end when /* Po otrzymaniu znacznika monitor sumuje własny wektor wiadomości z wektorem zawartym w znaczniku. Warunek oznacza, że istnieje wiadomośd aplikacyjna uwzględniona już w znaczniku jako wysłana do , a która jeszcze nie została odebrana przez . W tym wypadku znacznik jest zatrzymywany w monitorze , a jego dalsze przesłanie jest uwarunkowane otrzymaniem odpowiedniej liczby wiadomości aplikacyjnych przez */ when do if then 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. if then else for all do end for end if end if end when /* Każdy monitor zwiększając licznik nalicza indywidualnie wiadomości aplikacyjne wysłane przez , na pozycji odpowiadającej procesowi przeznaczenia */ when do end when /* Z drugiej strony monitor zmniejsza licznik własny , gdy odebrana zostanie wiadomośd aplikacyjna wysłana przez proces . Jeżeli , to jeżeli dla każdej pozycji wektora liczników jest ona równa zero i flaga nie jest ustawiona, to zostaje podjęta decyzja o wykryciu zakooczenia. W przeciwnym wypadku rozpoczynany jest kolejny cykl detekcyjny */ when do if then if then else for all end for end if end if end when do Cechy algorytmu wyeliminowanie konieczności dołączania etykiet do wiadomości aplikacyjnych zatrzymanie znacznika do momentu spełnienia koniecznych warunków zakooczenia wykonywanie algorytmu w sposób ciągły aż do momentu stwierdzenia zakooczenia przetwarzania aplikacyjnego algorytm ten kooczy się w ciągu jednej rundy wymiany znacznika od momentu faktycznego zakooczenia przetwarzania aplikacyjnego dużą wadą jest spora liczba informacji przesyłanych w znaczniku Detekcja zakończenia statycznego Koncepcja algorytmu Obecnie przedstawiony zostanie algorytm (Brzezioski, Helary, Raynal), zajmujący się problemem wykrycia faktu zakooczenia statycznego (patrz: Wykład #9: Zakooczenie statyczne). W algorytmie tym wykorzystano koncepcję ciągu cykli detekcyjnych, gdzie monitory są logicznie połączone w strukturę gwiazdy. Detekcja zakooczenia statycznego sprowadza się do wyznaczenia wartości predykatu: Algorytm detekcji zakończenia statycznego Algorytm wykorzystuje cztery typu komunikatów. Typ PACKET służy do przesyłania wiadomości aplikacyjnych. Typ QUERY jest zapytaniem wysyłanym przez inicjatora detekcji. Typ ACK ma za zadanie potwierdzad wiadomości aplikacyjne, i wreszcie typ REPLY jest odpowiedzią na wiadomości QUERY. Ten ostatni typ zawiera pole , które jest flagą, zawierającą wartośd zmiennej nadawcy wiadomości REPLY, w chwili jej wysłania. Aby uniknąd pominięcia wiadomości aplikacyjnej, która została wysłana przed otrzymaniem zapytania QUERY przez pewien monitor , a odebrana po otrzymaniu zapytania przez inny monitor wprowadzona jest zmienna logiczna , która jest inicjowana wartością . Za każdym razem, gdy jest uaktywniany, przyjmuje wartośd . Z kolei, wysyłając wiadomośd kontrolną REPLY monitory nadają zmiennej ponownie wartośd . Wartośd zmiennej w danej chwili oznacza, że proces był pasywny przez cały czas od chwili wysłania ostatniej wiadomości REPLY. Jeżeli zmienna przyjmuje wartośd , to monitor stwierdza zakooczenie statyczne, przypisując wartośd zmiennej . Zmienna jest licznikiem niepotwierdzonych wiadomości. Zbiór zawiera identyfikatory procesów, od których wiadomości aplikacyjne są już dostępne dla . type PACKET extends FRAME is record of : MESSAGE end record type QUERY extends SIGNAL type ACK extends SIGNAL type REPLY extends FRAME is record of : BOOLEAN end record : MESSAGE : PACKET : QUERY : REPLY : ACK : BOOLEAN : BOOLEAN : INTEGER : set of PROCESS_ID : BOOLEAN 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. /* W celu stwierdzenia zakooczenia statycznego przetwarzania aplikacyjnego, inicjator rozpoczyna detekcję przez wysłanie do wszystkich monitorów, w tym do siebie, wiadomości kontrolnej typu QUERY. Po otrzymaniu wszystkich odpowiedzi, inicjator wyznacza iloczyn logiczny otrzymanych zmiennych , jako wartośd zmiennej . Jeżeli przyjmie wartośd , to stwierdza zakooczenie, w przeciwnym razie inicjator ponownie wysyła zapytanie QUERY */ when do repeat for all do end for until end when /* Po otrzymaniu zapytania QUERY w odpowiedzi monitory przesyłają wiadomości typu REPLY natychmiast, gdy skojarzony z nimi proces aplikacyjny staje się pasywny, liczni niepotwierdzonych wiadomości wynosi zero i żadna z dostępnych w danej chwili wiadomości nie wystarcza do aktywacji procesu. Wysyłana wiadomośd zawiera bieżącą wartośd zmiennej logicznej, określającej, czy od czasu wysłania ostatniej odpowiedzi QUERY proces wciąż pozostał pasywny, w polu */ when do wait until 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. end when /* Wysyłając wiadomośd inkrementowany jest licznik , który z kolei jest zmniejszany w wyniku otrzymania potwierdzenia wiadomości */ when do end when when do end when when do end when /* W momencie aktywacji procesu */ when do zmiennej przypisywana jest wartośd end when Dowód poprawności algorytmu Przyjmijmy, że: - czas globalny wysłania odpowiedzi przez monitor czas globalny rozpoczęcia -tego cyklu detekcji czas globalny zakooczenia -tego cyklu detekcji w -tym cyklu detekcji Zachodzi oczywiście następujący związek: - jest wartością zmiennej (predykatu) w chwili inicjator aplikacyjnymi jest dodatkowym procesem, niezwiązanym z procesami Twierdzenie 18 Jeżeli algorytm detekcji zakooczenia statycznego jest wykonywany w chwili, gdy przetwarzanie aplikacyjne osiągnęło stan zakooczenia statycznego, to algorytm ten zakooczy się w skooczonym czasie, stwierdzając wystąpienie zakooczenia statycznego przetwarzania aplikacyjnego ( ) Twierdzenie 19 Jeżeli algorytm stwierdza wystąpienie zakooczenia statycznego przetwarzania aplikacyjnego, to przetwarzanie aplikacyjne jest w istocie w stanie zakooczenia statycznego. Rozważmy dwa kolejne cykle detekcyjne oraz . Załóżmy, że algorytm stwierdza zakooczenie przetwarzania aplikacyjnego koocząc cykl , a więc w chwili . Wówczas jest prawdziwe ( ). Szkic dowodu twierdzenia 19 Ponieważ cykle są inicjowane sekwencyjnie, istnieje taki moment , że Udowodnimy teraz, że jeżeli , to w chwili przetwarzanie aplikacyjne jest statycznie zakooczone, a więc: . Innymi słowy wykażemy, że dla wszystkich procesów spełnione będą następujące warunki: Warunek C1: Warunek C2: jeszcze nie dotarły do Warunek C3: do uaktywnienia procesu (proces -ty jest pasywny w chwili ) (nie ma żadnych procesów, od których wiadomości (dostępne wiadomości nie wystarczają Dowód warunku C1: Z konstrukcji algorytmu wynika, że zakooczy się on w chwili z tylko wówczas, gdy każdy proces był pasywny w czasie między , więc możemy zatem wnosid, że dla każdego , , a . Skoro jednak . Dowód warunku C2: Zgodnie z konstrukcją algorytmu, w każdym cyklu detekcyjnym odpowiedź REPLY jest wstrzymywana aż do momentu nadejścia potwierdzeo od monitorów procesów przeznaczenia, dla wszystkich wysłanych wcześniej wiadomości aplikacyjnych. Wówczas przyjmie wartośd 0. Z drugiej strony, można jednak zauważyd, że od chwili do proces jest ciągle pasywny, a więc nie wysyła wiadomości. Stąd więc wnosimy, że dla każdego procesu , . Dowód warunku C3: W każdym cyklu detekcyjnym odpowiedź jest opóźniana do momentu uzyskania przez predykat wartości ( o wartości ). Skoro algorytm kooczy się w chwili , to predykat miał wartośd . Ponieważ w przedziale proces był przez cały czas pasywny, żadna wiadomośd nie została w tym czasie odebrana. Stąd też, w przedziale tym do zbioru mogły byd co najwyżej dołączone dodatkowe wiadomości. W efekcie: . Z własności monotoniczności predykatu możemy przy tym wnioskowad, że skoro zachodzi , to również zachodzi . Wykazaliśmy zatem, że w chwili , dla każdego procesu spełnione są warunki C1, C2 i C3, a więc predykat zakooczenia statycznego w chwili jest prawdziwy. Ponieważ predykat ten jest stabilny, więc również dla każdego , w tym również dla , . Złożoność algorytmu Efektywnośd, a także złożonośd czasowa i komunikacyjna algorytmu zależy od implementacji cykli detekcyjnych i topologii przetwarzania monitorującego. W celu wyznaczenia złożoności czasowej zauważmy, że po wystąpieniu zakooczenia statycznego, dla jego stwierdzenia potrzebne są w najgorszym wypadku dwa pełne cykle detekcyjne oraz musi byd dokooczony bieżący cykl. W każdym cyklu przesyłanych jest wiadomości typu QUERY i wiadomości typu REPLY, przenoszących jednobitową zmienną. Tak więc, zaniedbując wiadomości potwierdzeo (których liczba jest równa liczbie wiadomości aplikacyjnych), otrzymujemy liczbę wiadomości kontrolnych, wystarczających do stwierdzenia zakooczenia, równą . Przyjmijmy teraz, że struktura topologiczna przetwarzania detekcyjnego jest grafem pełnym. Pomijając ponownie wiadomości potwierdzeo, łatwo już zauważyd, że złożonośd czasowa algorytmu wynosi . Oczywiście przy innych topologiach złożonośd ta odpowiednio się zmienia. Przykładowo, w przypadku pierścienia złożonośd czasowa wynosi . Detekcja zakończenia dynamicznego Koncepcja algorytmu Detekcja zakooczenia dynamicznego (patrz: Wykład #9: Zakooczenie dynamiczne) sprowadza się do wyznaczenia wartości predykatów, definiujących takie zakooczenie, tzn.: W tym celu zaproponowano algorytm (Brzezioski, Helary, Raynal), który stosuje mechanizm cykli detekcyjnych oraz wiadomości kontrolne typu QUERY i REPLY, a także liczniki wiadomości odebranych i wysłanych przez procesy. Algorytm detekcji zakończenia dynamicznego Algorytm wykorzystuje trzy typu komunikatów, z których PACKET służy do przenoszenia wiadomości aplikacyjnych w postaci pakietów. Typ QUERY zawiera pole , będące wektorem liczników wiadomości wysłanych do adresata wiadomości typu QUERY, zgodnie z wiedzą inicjatora . W polu zapisywany jest iloczyn logiczny wartości zmiennej oraz , określającego, czy proces może zostad uaktywniony przez sumę logiczną wiadomości już dostępnych oraz tych, które prawdopodobnie znajdują się jeszcze w kanałach komunikacyjnych. Pole zawiera wektor liczników wiadomości aplikacyjnych wysłanych przez proces obserwowany przez monitor- nadawcę wiadomości REPLY, w chwili jej wysłania. Swoje znaczenie, identyczne do poprzednio omawianego algorytmu detekcji zakooczenia statycznego, zachowują , , , , oraz i . Zmienna jest tablicą wiadomości wysłanych przez do liczników, w której element . Analogicznie, zmienna jest tablicą oznacza liczbę liczników, w której element oznacza liczbę wiadomości odebranych przez od procesu . Ponadto, inicjator przechowuje zmienną , będącą tablicą . Wiersz -ty tej tablicy zawiera wektor przesłany ostatnio do inicjatora przez monitor , w wiadomości kontrolnej typu REPLY. W efekcie, każdy element tablicy reprezentuje wiedzę inicjatora o liczbie wiadomości aplikacyjnych wysłanych z do . Zauważmy, że wiedza ta nie jest precyzyjna, gdyż nadesłane wektory dla , odnoszą się w ogólności do różnych momentów czasu. jest aproksymacją zbioru identyfikatorów procesów, które wysłały wiadomości niedostępne jeszcze dla . Zmienna logiczna posiada wartośd , gdy proces pozostał pasywny od momentu wysłania ostatniej wiadomości typu REPLY. Jeżeli wartośd zmiennej logicznej będzie równy , inicjator podejmie decyzję o wykryciu zakooczenia dynamicznego. type PACKET extends FRAME is record of : MESSAGE end record type QUERY extends FRAME is record of : array of INTEGER end record type REPLY extends FRAME is record of : BOOLEAN : array of INTEGER end record : MESSAGE : PACKET : QUERY : REPLY : array of INTEGER : array of INTEGER : array of INTEGER : set of PROCESS_ID : set of PROCESS_ID : BOOLEAN : BOOLEAN : BOOLEAN /* Inicjator detekcji rozpoczyna cykl detekcyjny, wysyłając do wszystkich monitorów wiadomośd kontrolną typu QUERY, zawierającą w polu odpowiednią kolumnę tablicy , dzięki czemu każdy monitor będzie mógł dokonad aproksymacji liczby wiadomości wysłanych, lecz jeszcze nieodebranych przez (znajdujących się w kanałach komunikacyjnych). Wektor ten informuje odbiorcę o znanej inicjatorowi liczbie wiadomości wysłanych do przez inne procesy. Następnie inicjator oczekuje na zebranie odpowiedzi od wszystkich pozostałych procesów. Później, sumuje on wartości nadesłanych 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. liczników wiadomości aplikacyjnych wysłanych przez te procesy- suma ta zostanie wykorzystana w następnym cyklu detekcyjnym. Algorytm stwierdza wykrycie zakooczenia dynamicznego przetwarzania aplikacyjnego, gdy wszystkie odebrane w danym cyklu przez zmienne mają wartośd . W przeciwnym wypadku, rozpoczyna następny cykl detekcyjny */ when do repeat for all for all do do end for end for for all for all do do end for end for until end when /* Po otrzymaniu zapytania QUERY, monitor może wyznaczyd zbiór , będący aproksymacją zbioru tych procesów, których wiadomości wysłane do są potencjalnie jeszcze w kanałach (porównywany jest wektor odebrany przez z - jeżeli , to w kanale znajdą się wiadomości wysłane przez do , a nieodebrane jeszcze przez ). Następnie każdy z monitorów wyznacza wartośd zmiennej ( wtedy i tylko wtedy, gdy , a predykat ) Po wyznaczeniu wartości monitor wysyła odpowiedź typu REPLY, zawierającą pole oraz aktualny wektor , który będzie użyty przez do uaktualnienia tablicy */ when do end when /* Przy wysyłaniu (odbieraniu) wiadomości aplikacyjnych do ty wpis w tablicy ( ) */ monitor inkrementuje - 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. when do end when /* Wysyłając wiadomośd inkrementowany jest licznik , który z kolei jest zmniejszany w wyniku otrzymania potwierdzenia wiadomości */ when do end when /* W momencie aktywacji procesu */ when do zmiennej przypisywana jest wartośd end when Twierdzenie 20 Jeżeli algorytm jest wykonywany w chwili, gdy przetwarzanie aplikacyjne osiągnęło stan zakoodzenia dynamicznego, to algorytm ten zakooczy się w skooczonym czasie, stwierdzając wystąpienie dynamicznego zakooczenia przetwarzania aplikacyjnego. Dowód powyższego twierdzenia przebiega następująco: Cykl detekcyjny nie jest wstrzymywany przez monitory, a więc inicjator otrzyma odpowiedź od każdego monitora w skooczonym czasie. Zakładamy, że przetwarzanie aplikacyjne osiągnęło stan zakooczenia dynamicznego w chwili ( ). Od tego momentu zatem, wszystkie procesy pozostają ciągle pasywne: oraz , dla każdego . Zatem każdy cykl zainicjowany po czasie , powiedzmy cykl -ty, nada wszystkim zmiennym wartośd i odbierze od monitorów wektor koocowych wartości liczników . Dlatego, w chwili rozpoczęcia kolejnego cyklu detekcyjnego, wysłane zostaną ostateczne wartości liczników wiadomości wysłanych, a stąd . W efekcie otrzymujemy, że: . Ze względu na fakt, że ten ostatni predykat ma wartośd od chwili , a , więc w cyklu wszystkie zmienne będą miały wartośd , i w efekcie algorytm detekcji dynamicznego zakooczenia przetwarzania aplikacyjnego się zakooczy. Twierdzenie 21 Jeżeli algorytm stwierdza wystąpienie dynamicznego zakooczenia przetwarzania rozproszonego, to przetwarzanie aplikacyjne jest w istocie w stanie zakooczenia dynamicznego. Oznaczmy przez k i k+1 dwa ostatnie cykle detekcyjne. Dowód powyższego twierdzenia obejmuje wykazanie, że istnieje taki moment dla którego dla wszystkich procesów są spełnione następujące warunki: Warunek C4: (wszystkie procesy są pasywne w chwili Warunek C5: (ani wiadomości już dostępne, ani znajdujące się w kanałach komunikacyjnych nie wystarczą do uaktywnienia procesu ) Dowód warunku C4 pomijamy, jako identyczny, jak w przypadku warunku C1 (patrz: Twierdzenie 19) dla twierdzenia o poprawności algorytmu detekcji zakooczenia statycznego. Dowód warunku C5: Z konstrukcji algorytmu wynika, że algorytm ten zakooczy się w chwili pod warunkiem, że predykat . Ponieważ każdy proces był pasywny w przedziale dla każdego z nich zachodzi: Warunek C6: oraz Wyznaczając zbiór procesów, od których wiadomości są aktualnie transmitowane do algorytm uwzględnia w istocie następującą zależnośd: gdyż , . Zauważmy, że liczniki są monotoniczne, zatem: Ponieważ dla każdego , różnica między rzeczywistym zbiorem , a jego aproksymacją , może wynikad tylko z dotarcia pewnych wiadomości do procesów docelowych. Wówczas jednak odpowiedni nadawcy zostaną uwzględnieni w zbiorze , zatem biorąc pod uwagę warunek C6 możemy wnioskowad, że: Dalej, z monotoniczności predykatu wynika, że dla każdego : Powyższe oznacza, że warunek C5 jest spełniony. Złożoność algorytmu i jego cechy Aby wykryd wystąpienie zakooczenia dynamicznego, niezbędne są w najgorszym wypadku dwa cykle detekcyjne po zakooczeniu cyklu bieżącego Ponieważ nie są przesyłane potwierdzenia, złożonośd komunikacyjna algorytmu wynosi (zatem jest mniejsza niż w przypadku algorytmu detekcji zakooczenia statycznego przedstawionego wcześniej- ) Porównując dalej algorytmy detekcji zakooczenia statycznego i dynamicznego, widzimy, że wiadomości kontrolne w drugim z nich są bardziej złożone, gdyż zawierają wektory liczników. Opóźnienie detekcji jest mniejsze, ze względu na brak konieczności oczekiwania na potwierdzenia. Wystąpienie zakooczenia dynamicznego wyprzedza w czasie wystąpienie zakooczenia statycznego. Uzyskane w sumie przyspieszenie momentu wykrycia zakooczenia obliczeo rozproszonych może zatem mied istotne znaczenie praktyczne, zwłaszcza w zastosowaniach czasu rzeczywistego. Wykład #11: Niezawodność przetwarzania Plan wykładu: a) b) c) d) Pojęcia podstawowe (awaria, błąd, wada) Klasy awarii procesów Kanały komunikacyjne Modele systemów rozproszonych w kontekście niezawodności (model asynchroniczny, synchroniczny i częściowo synchroniczny) e) Detektory awarii- definicje, zależności, metryki f) Implementacja detektorów awarii klasy i g) Problem elekcji w środowisku zawodnym Poprawność procesu Proces poprawny to taki, który działa zgodnie z algorytmem (specyfikacją). Dla procesu poprawnego predykat Analogicznie, procesem niepoprawnym, nazywamy proces, który działa niezgodnie z algorytmem (specyfikacją); wówczas predykat . Pojęcia podstawowe Awaria (ang. failure)- działanie (zachowanie) procesu niezgodnie ze specyfikacją Błąd (ang. error)- składnik stanu procesu odpowiedzialny za będącą jego następstwem awarię. Może on byd symptomem awarii, która ujawnia się natychmiast lub dopiero w przyszłości. Wada (ang. fault)- stwierdzona lub hipotetyczna przyczyna wystąpienia błędu Klasy awarii procesów Wyróżnia się cztery podstawowe klasy awarii procesów: załamania, zaniechania, awarie powtarzalne i awarie dowolne. Załamanie (ang. crashes) oznacza, że proces działa poprawnie do pewnej chwili , po której zaprzestaje wysyład i odbierad wiadomości, pomimo, że wynika to z algorytmu procesu. Specjalnym przypadkiem jest sytuacja, w której proces ulega awarii przed wykonaniem jakiegokolwiek kroku algorytmu (ang. initially-dead). Zaniechanie (ang. omissions) oznacza, że proces nie wysyła (lub nie dostarcza) wiadomości, pomimo, że powinien to zrobid, zgodnie z wykonywanym algorytmem. Awarie zaniechania mogą byd konsekwencją przepełnienia bufora lub przeciążenia sieci komunikacyjnej. Awaria powtarzalna (ang. crash &recoveries) oznacza, że proces może byd odtworzony (wznowiony) po awarii. Wystąpienie awarii tego typu wstrzymuje proces na pewien czas, po upływie którego proces rozpoczyna ponownie wykonywanie algorytmu. Proces jest uznawany za poprawny, jeżeli istnieje pewna chwila , po której proces wykonuje algorytm i nigdy nie podlega awariom. Innymi słowy, proces poprawny to taki, który ulega skooczonej liczbie awarii, przy czym po każdej z nich możliwe jest odtworzenie jego stanu. Proces błędny w tym modelu to taki, który nie jest wznowiony po kolejnej (w szczególności, pierwszej) awarii lub taki, który wiele razy ulega awarii Awaria dowolna (ang. arbitrary failures) oznacza, że zachowanie procesu odbiega w sposób dowolny od algorytmu, który powinien wykonywad. Na przykład, proces może wysyład w dowolnej chwili różne wiadomości. Szczególnym przypadkiem awarii dowolnych są tzw. awarie bizantyjskie. Jak łatwo zauważyd, najbardziej ogólną klasą awarii jest klasa z awariami dowolnymi. Zaniechania są specjalnym przypadkiem awarii powtarzalnych, natomiast załamania szczególnym przypadkiem zaniechao. W synchronicznych systemach rozproszonych pojawia się dodatkowa klasa awarii związana z wykonywaniem kroków we właściwej kolejności, ale w niewłaściwym czasie. Są to awarie dotyczące czasu (ang. timing errors). Modele kanałów komunikacyjnych Przypomnijmy, że kanał (patrz: Wykład #2: Kanał komunikacyjny) jest obiektem (abstrakcją, mechanizmem) skojarzonym z uporządkowaną parą procesów , modelującym jednokierunkowe łącza transmisyjne. Dotychczas zakładaliśmy, że kanały są niezawodne. Oznaczało to, że każda wiadomośd wysłana kanałem ostatecznie (w koocu) docierała do adresata. Takie założenie nie zawsze jest realizowalne. Przeanalizujemy więc dalej różne modele kanałów komunikacyjnych, uwzględniając możliwe ich awarie. W szczególności omówimy kanały rzetelne (ang. fair loss links), kanały wytrwałe (ang. stubborn links) i kanały niezawodne (ang. perfect links), które będą podstawą konstrukcji wybranych algorytmów rozproszonych w środowisku zawodnym. Kanały rzetelne Specyfikacja Kanał między dwoma procesami nazywad będziemy kanałem rzetelnym, jeżeli posiada on następujące własności: Rzetelne dostarczanie (ang. fair loss delivery) Jeżeli wiadomośd wysyłana jest nieskooczoną liczbę razy przez proces do i żaden z tych procesów nie ulega awarii (oba są poprawne), to wiadomośd jest dostarczana nieskooczoną liczbę razy do . Należy zauważyd, że własnośd ta dopuszcza zagubienie wiadomości - nawet nieskooczoną liczbę razy. Ograniczone powielanie (ang. finite duplication) Jeżeli wiadomośd wysyłana jest skooczoną liczbę razy przez proces do , to wiadomośd ta nie może byd dostarczona nieskooczoną liczbę razy do procesu . Brak samogeneracji (ang. no creation) Jeżeli wiadomośd została dostarczona do procesu , to została ona wcześniej wysłana do tego procesu przez jakiś inny proces . Innymi słowy, kanał nie tworzy samorzutnie wiadomości. Operacje komunikacyjne Operację wysłania wiadomości przez proces rzetelnego oznaczad będziemy przez będziemy jako do procesu , gwarantującą własności kanału , a odpowiadające jej zdarzenie zapisywad . Analogicznie przez oznaczad będziemy operację uaktywniającą zdarzenie i przekazującą wiadomośd do procesu aplikacyjnego lub innego mechanizmu komunikacyjnego (innej warstwy komunikacyjnej). Kanały wytrwałe Specyfikacja Kanał między dwoma procesami nazywad będziemy kanałem wytrwałym (upartym) (ang. stubborn link), jeżeli posiada on następujące własności: Wytrwałe dostarczanie (ang. stubborn delivery) Jeżeli wiadomośd wysyłana jest przez proces do procesu i oba te procesy są poprawne (nie ulegają awarii), to wiadomośd jest dostarczona nieskooczoną liczbę razy do . Brak samogeneracji (ang. no creation) Własnośd taka sama, co w przypadku kanałów rzetelnych. Jeżeli wiadomośd została dostarczona do procesu , to została ona wcześniej wysłana do tego procesu przez jakiś inny proces . Innymi słowy, kanał nie tworzy samorzutnie wiadomości. Operacje komunikacyjne Operację wysłania wiadomości przez proces wytrwałego oznaczad będziemy będziemy jako do procesu , gwarantującą własności kanału , a odpowiadające jej zdarzenie zapisywad . Analogicznie, przez oznaczad będziemy operację uaktywniającą zdarzenie i przekazującą wiadomośd do procesu aplikacyjnego lub innego mechanizmu komunikacyjnego (innej warstwy komunikacyjnej). Implementacja kanałów wytrwałych Algorytm, implementujący mechanizm kanałów wytrwałych (ang. retransmit forever algorithm) zakłada dostępnośd mechanizmu kanałów rzetelnych. W poniższym algorytmie wiadomości aplikacyjne umieszczane są w pakietach typu PACKET. Wiadomości aplikacyjne ( ) są umieszczane w pakietach ( ) i, po odebraniu danego pakietu przez monitor, są one przekazywane procesom aplikacyjnym z użyciem operacji , uaktywniającej zdarzenie w odpowiednim procesie aplikacyjnym. type PACKET extends FRAME is record of : MESSAGE end record : MESSAGE : PACKET 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. /* Po stronie nadawcy implementacja mechanizmu kanałów wytrwałych sprowadza się do wysyłania wiadomości nieskooczoną liczbę razy */ when do while wait end while end when /* Po stronie odbiorcy wiadomości, każde odebrana wiadomośd jest po prostu przekazywana procesowi aplikacyjnemu- adresatowi */ when do end when Kanały niezawodne Specyfikacja Kanał między dwoma procesami jest nazywany kanałem niezawodnym (ang. perfect link, reliable link), jeżeli posiada on następujące własności: Niezawodne dostarczanie (ang. reliable delivery) Jeżeli wiadomośd wysyłana jest przez proces do procesu poprawne, to wiadomośd jest ostatecznie dostarczona do . i oba te procesy są Brak powielania (ang. no duplication) Żadna wiadomośd wysłana do nie może byd dostarczona do więcej niż raz. Brak samogeneracji (ang. no creation) Analogicznie, co w przypadku tej samej własności w kanałach rzetelnych i wytrwałych. Kanał nie tworzy samorzutnie wiadomości. Czasami kanały tego typu nazywa się kanałami ostatecznie niezawodnymi. Operacje komunikacyjne Operację wysłania wiadomości przez proces do procesu niezawodnego oznaczad będziemy będziemy jako , gwarantującą własności kanału , a odpowiadające jej zdarzenie zapisywad . Analogicznie, przez oznaczad będziemy operację uaktywniającą zdarzenie i przekazującą wiadomośd do procesu aplikacyjnego lub innego mechanizmu komunikacyjnego (innej warstwy komunikacyjnej). Implementacja kanałów niezawodnych Algorytm implementujący mechanizm kanałów niezawodnych zakłada dostępnośd mechanizmu kanałów wytrwałych. type PACKET extends FRAME is record of : PROCESS_ID : MESSAGE end record : MESSAGE : PACKET : set of MESSAGE 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. /* Po stronie nadawcy implementacja mechanizmu kanałów niezawodnych jest identyczna, co jej odpowiednik dla mechanizmu kanałów wytrwałych */ when do // patrz: Kanały wytrwałe end when /* Wiadomośd jest dostarczana przez monitor procesowi aplikacyjnemu tylko wtedy, gdy nie zawiera się on w zbiorze . Po dostarczeniu procesowi wiadomości jest ona dodawana do zbioru . Zapobiega to tym samym dostarczania wiadomości więcej niż jednokrotnie */ when do if end if end when then Modele systemów rozproszonych w kontekście niezawodności Jak wcześniej wspomniano, ważnym aspektem, charakteryzującym system rozproszony, są przyjęte założenia, dotyczące zachowania procesów i kanałów komunikacyjnych, uwzględniające upływający czas. W zależności od tego, czy istnieją w danym modelu ograniczenia, dotyczące czasu komunikacji i szybkości względnej procesów możemy wyróżnid systemy asynchroniczne (ang. asynchronous), częściowo synchroniczne (ang. partially synchronous) i synchroniczne (ang. synchronous). Systemy asynchroniczne Dla wielu problemów konstrukcja algorytmów rozproszonych w zawodnych systemach asynchronicznych jest trudna, a często nawet niemożliwa bez dodatkowych założeo, dotyczących synchronizmu lub dostępności specyficznych mechanizmów. Przykładem może byd tutaj problem konsensusu (patrz: Wykład #13). Brak ograniczeo na czas transmisji wiadomości (komunikacji) Brak ograniczeo na czas przetwarzania Brak dostępu do globalnego zegara, np. fizycznego zegara czasu rzeczywistego. Jak wiadomo, pomimo braku dostępu do zegara globalnego, nadal możliwy jest pomiar czasu. Będzie to jednak tylko czas logiczny związany z wymianą komunikatów (patrz: Wykład #4: Czas wirtualny) Systemy synchroniczne W przetwarzaniu synchronicznym istnieje i jest znane górne ograniczenie, dotyczące czasu przetwarzania poszczególnych procesów lub inaczej, względnych prędkości wykonywania procesów. Można zatem łatwo określid moment, po którym dane zadanie powinno zostad wykonane przez proces. Takimi zadaniami może byd wysłanie lub odebranie wiadomości lub też przetwarzanie lokalne. W komunikacji synchronicznej natomiast, istnieje znane z góry ograniczenie czasu transmisji wiadomości przez kanały komunikacyjne. Jest to, innymi słowy, czas potrzebny, aby komunikat wysłany przez nadawcę dotarł do adresata w najgorszym możliwym przypadku. Dostępnośd zegara globalnego oznacza możliwośd lokalnego odczytu przez procesy aktualnego stanu wspólnego zegara. Odczyt ten jest precyzyjny, bądź obarczony znanym maksymalnym błędem odczytu lokalnego w stosunku do wartości zegara globalnego. Niestety, z uwagi na silne założenia, dotyczące czasu, konstrukcja systemów synchronicznych jest bardzo trudna. Ponadto, w systemach tego typu trzeba zakładad czasy maksymalne, na ogół znacznie większe niż czasy średnie. Takie założenie prowadzi zwykle- w praktyce- do istotnego zmniejszenia efektywności aplikacji. Synchroniczne komunikacja Synchroniczna przetwarzanie Dostępny zegar globalny Systemy częściowo synchroniczne Rzeczywiste systemy rozproszone zwykle zachowują się jak systemy synchroniczne, tzn. zazwyczaj znane są pewne ograniczenia na czas dostarczenia wiadomości. System tego typu można by więc nazwad systemem zazwyczaj synchronicznym. Istnieją jednak odcinki czasu, w których te znane ograniczenia czasowe przestają obowiązywad i wtedy system taki zachowuje się jak system asynchroniczny, np. w chwili przeciążenia sieci komunikacyjnej, przepełnienia buforów itp. Z powyższych powodów wprowadzono pojęcie systemów częściowo synchronicznych, które można zdefiniowad na kilka sposobów: Mogą to byd systemy, w których po pewnym, nieznanym czasie, zaczynają obowiązywad przyjęte założenia na górne ograniczenia na czas dostarczenia wiadomości. Innymi słowy, systemy takie ostatecznie zaczynają się zachowywad jak systemy synchroniczne, lecz nie wiadomo, od jakiego momentu Można także przyjąd, że w systemach częściowo synchronicznych istnieją odcinki czasu, w których istnieją ograniczenia na czasy dostarczenia wiadomości i odcinki te są wystarczająco długie, by umożliwid zakooczenie algorytmów. Zaprezentowane definicje nie znaczą oczywiście, że system musi byd początkowo asynchroniczny, czy też, że po pewnym, znanym czasie system taki stanie się systemem synchronicznym na zawsze. Można także dokonad klasyfikacji systemów częściowo synchronicznych na podstawie parametrów, dotyczących właściwości procesów i kanałów komunikacyjnych: Synchronicznośd procesów (istnieje stała taka, że jeżeli pewien proces wykona kroków, to każdy inny proces wykona co najmniej krok) Istnienie ograniczeo na czas przesyłania wiadomości (opóźnienie komunikacyjne) Porządek wiadomości (porządek synchroniczny oznacza, że jeżeli proces wysyła wiadomośd do procesu w czasie oraz proces wysyła wiadomośd do procesu w czasie , to wiadomośd zostanie dostarczona do przed wiadomością . Sposób komunikacji (określenie, czy komunikacja odbywa się za pomocą niepodzielnej komunikacji rozgłaszania, czy też za pomocą komunikacji punkt- punkt) Typ operacji / (określenie, czy są one operacjami atomowymi, tzn. czy operacja wysłania wiadomości kooczy się dopiero po zakooczeniu odbioru tej wiadomości przez adresata, czy też są one rozłączne. Innymi słowy, czy komunikacja między procesami jest synchroniczna, czy też nie) Korzystając z powyższych parametrów można wyodrębnid klasy systemów. Podział ten jednakże nie zdobył powszechnego uznania, głównie z uwagi na to, że w rzeczywistych systemach niektóre parametry są do pewnego stopnia równoważne innym. Na przykład, niepodzielne operacja rozgłaszania i / wymagają istnienia ograniczeo na czas przesyłania wiadomości, by można je było zaimplementowad. Detektory awarii Z praktycznego punktu widzenia, zawodny rozproszony detektor awarii (ang. failure detector) można definiowad jako zbiór „wyroczni”, które są powiązane z poszczególnymi procesami, biorącymi udział w przetwarzaniu rozproszonym. Zadaniem tych wyroczni jest dostarczanie listy procesów podejrzewanych o niepoprawne działanie (procesów, które uległy awarii). Wyrocznie te mogą byd omylne, co oznacza, że mogą podejrzewad o awarię procesy poprawne lub też odwrotnie- nie podejrzewad procesów niepoprawnych. Błędne podejrzenia są oczywiście niepożądane, ale w praktyce są akceptowalne, o ile nie powstrzymują poprawnych procesów przed zachowaniem się zgodnie z ich specyfikacją. Dlatego też mówi się, że detektor „podejrzewa”, a nie „wykrywa” proces niepoprawny. Ponadto, w momencie stwierdzenia przez wyrocznię awarii procesu, proces ten powinien znaleźd się na liście procesów podejrzanych. Natomiast w przypadku odwrotnym, gdy wyrocznia stwierdzi, że proces jest poprawny, proces ten powinien byd usunięty z listy procesów podejrzewanych. Informacje dostarczane przez detektor są tym dokładniejsze, im większy synchronizm systemu rozproszonego. Właściwości detektorów możliwych do zaimplementowania w systemie określają stopieo jego synchroniczności. Rozważany model systemu: System składa się ze zbioru procesów, . Kanały komunikacyjne, łączące wybrane, stosownie do topologii przetwarzania, pary procesów, są niezawodne. Zegar globalny jest dyskretny, a jego dziedzina jest zbiorem liczb naturalnych . Zakłada się też ponadto, że czasy komunikacji i przetwarzania są ograniczone, lecz nieznane. Wzorzec awarii Chandra i Toueg wprowadzili pojęcie zawodnego detektora awarii, jako dostępnego dla programisty mechanizmu, który udziela informacji na temat stanu poszczególnych procesów. Niezwykle ważne jest tu określenie „zawodny”, oznaczające tu, że nie spodziewamy się, iż detektor w każdej chwili udzieli odpowiedzi prawidłowej. Może on wskazywad procesy poprawne jako te, które uległy awarii, bądź na odwrót, przy czym może popełniad pomyłki nieskooczenie wiele razy. Nie może to jednak spowodowad naruszenia warunków poprawności, bądź zakooczenia algorytmu. Niech wzorzec awarii będzie funkcją odwzorowującą w , gdzie oznacza zbiór procesów, które uległy awarii do momentu . Po awarii proces nie jest wznawiany, stąd: Ponadto oraz Historia detektora awarii Rozważmy tylko wzorce , w których co najmniej jeden proces jest poprawny, czyli Każdy detektor utrzymuje listę (zbiór) procesów, które podejrzewa. . Historia detektora awarii to funkcja odwzorowująca iloczyn kartezjaoski zbioru procesów i pewnego okresu czasu w rodzinę wszystkich podzbiorów zbioru ( ). Wartośd jest zbiorem procesów podejrzewanych przez detektor procesu w chwili . Jeżeli , to mówimy, że podejrzewa w chwili w . Formalna definicja detektora awarii Zbiór możliwych historii oznacza sumę mnogościową wszystkich możliwych historii detektora awarii dla wzorca . Detektor awarii detektora awarii jest to funkcja, odwzorowująca wzorzec awarii . w zbiór możliwych historii Własności detektorów Detektory awarii charakteryzowane są przez dwie własności: Kompletnośd (ang. completness) opisuje zdolnośd do podejrzewania wszystkich procesów niepoprawnych. Związana jest ona z możliwością popełnienia pomyłek pierwszego rodzaju- tzn. niepodejrzewania procesów niepoprawnych Dokładnośd (ang. accuracy) opisuje zdolnośd do niepodejrzewania procesów poprawnych. Związana jest ona z możliwością popełnienia pomyłki drugiego rodzaju- tj. podejrzewania przez detektor awarii procesów poprawnych. Zauważmy, że branie pod uwagę tylko jednej z tych własności nie jest wystarczające. W przypadku kompletności trywialny w implementacji detektor, podejrzewający zawsze wszystkie procesy spełniałby zawsze własnośd silnej kompletności- podejrzewając wszystkie procesy, gwarantowałby, że podejrzewa również wszystkie procesy niepoprawne. Analogicznie trywialny przykład detektora, niepodejrzewającego żadnego procesu można by przedstawid dla drugiej z własności. Na tej podstawie jasno widad koniecznośd uwzględnienia obu własności. Własność kompletności Silna kompletnośd (ang. strong completeness *SC+) oznacza, że ostatecznie każdy procesy, który jest niepoprawny, będzie trwale podejrzewany przez każdy poprawny proces. Słaba kompletnośd (ang. weak completeness *WC+) oznacza, że ostatecznie każdy proces, który jest niepoprawny, będzie trwale podejrzewany przez niektóre procesy (przynajmniej jeden). Własność dokładności Silna dokładnośd (ang. strong accuracy *SA+) oznacza, że żaden proces nie jest podejrzewany, dopóki nie stanie się niepoprawny. Słaba dokładnośd (ang. weak accuracy *WA+) oznacza, że niektóre poprawne procesy nie są nigdy podejrzewane Można zdefiniowad dwie dodatkowe własności związane z dokładnością, mówiące, że detektor awarii zacznie działad jak detektor, gwarantujący słabą lub silną dokładnośd, ale dopiero po pewnym nieznanym, ale ograniczonym czasie. Definicje tych własności są następujące: Ostatecznie silna dokładnośd (ang. eventual strong accuracy) oznacza, że po upływie pewnego skooczonego czasu żadne poprawne procesy nie są podejrzewane przez żadne poprawne procesy. Ostatecznie słaba dokładnośd (ang. eventual weak accuracy) oznacza, że po upływie pewnego skooczonego czasu niektóre poprawne procesy (co najmniej jeden) nie są podejrzewane przez żaden poprawny proces. Klasyfikacja detektorów Kompletnośd Silna Dokładnośd Słaba Ostatecznie silna Silna Perfect P Strong S Eventually Perfect P Słaba Q Weak W Q Ostatecznie słaba Eventually Strong S Eventually Weak W Kombinacja wszystkich omówionych własności daje nam w sumie klas detektorów, które zostały zaprezentowane powyżej. Istnieje także wiele innych klas detektorów awarii, różniącymi się wymaganiami odnośnie dokładności i kompletności. Relacja redukcji detektorów Pomiędzy różnymi klasami detektorów awarii można wyznaczyd pewną hierarchię, pozwalającą wykorzystywad detektory (określane nieformalnie jako silniejsze) w celu emulowania własności innych (które określa się wtedy jako detektory słabsze). Mówimy, że istnieje algorytm redukcji on przekształcid wyjście detektora błędów , jeżeli dla każdego przebiegu tego algorytmu potrafi w możliwe wyjście detektora . Jeżeli istnieje algorytm redukcji , przekształcający w , to mówi się, że jest redukowalny do lub słabszy niż , co zapisuje się jako . Oznacza to, że problem rozwiązywalny za pomocą da się także rozwiązad za pomocą detektora . Jeżeli redukuje się do oraz równoważne, co zapisuje się jako redukuje się do Wreszcie, jeżeli redukuje się do jest ściśle słabszy niż . , ale , to mówi się, że nie można zredukowad do oraz są , to mówi się, że Jeżeli natomiast dwa detektory nie redukują się do siebie wzajemnie, to detektory te nazywamy nieporównywalnymi. Relacje między detektorami Doskonały detektor awarii może byd scharakteryzowany własnością silnej kompletności (SC) i własnością silnej dokładności (SA). Może się jednak zdarzyd, że nie będziemy potrzebowad detektora z tak silnymi własnościami, które mogą powodowad zwiększenie wymagao, dotyczących synchronizmu systemu. W takim przypadku możemy osłabid jedną lub obie własności w zależności od potrzeb. Na rysunku poniżej przedstawione są wszystkie możliwości „osłabienia” doskonałego detektora awarii. Do wyboru mamy trzy scenariusze: Osłabiona zostanie silna kompletnośd do słabej kompletności (SC -> WC). W wyniku tego działania powstanie detektor klasy Q. Osłabiona zostanie silna dokładnośd do słabej dokładności (SA -> WA). W wyniku tego działania powstanie detektor klasy S. Osłabiona zostanie silna dokładnośd do ostatecznie silnej dokładności (SA -> ESA). W wyniku tego działania powstanie detektor klasy P Hierarchia detektorów Ostatecznie możemy zobrazowad wszystkie zależności pomiędzy poszczególnymi klasami detektorów awarii przedstawiając sześcian, którego wierzchołkami są właśnie poszczególne klasy detektorów. Każda z krawędzi tego sześcianu będzie reprezentowała pewną relację pomiędzy wierzchołkami (klasami detektorów), które łączy. W ten sposób otrzymujemy: Detektorami równoważnymi są następujące pary klas detektorów: , , , . Krawędzie łączące odpowiednie pary zostały zastąpione symbolem dwukierunkowej strzałki rysowanej linią przerywaną. Inne pary detektorów połączone wspólną krawędzią znajdują się w zdefiniowanej wcześniej relacji redukcji. Dla przykładu można wymienid tutaj pary ( jest ściśle słabszy od ), , , czy też . Wierzchołki, znajdujące się po przekątnych, czy to sześcianu, czy też kwadratu (boku) tworzą pary nieporównywalnych klas. Przykładowo mogą to byd pary , czy też . Jakość detekcji- metryki Detektory awarii można oceniad na podstawie jakości ich usług. Właściwośd kompletności i dokładności, chod o bardzo dużym znaczeniu teoretycznym, mają niewielkie znacznie praktyczne. Osoby, korzystające z systemów z detektorami błędów nie oczekują, że w nieskooczonym czasie ich programy będą działad poprawnie- interesują ich raczej bardziej realistyczne kryteria. Dwoma interesującymi własnościami mogłyby byd prędkośd wykrywania awarii (liczba jednostek czasu wymaganych do wykrycia błędnego procesu) oraz dokładnośd, opisująca, jak dobrze detektorowi udaje się unikad pomyłek. Jednym z propozycji oceny jakości detektorów awarii wprowadziła trzy główne oraz cztery dodatkowe metryki jakości. Do głównych metryk jakości należą: Czas wykrycia awarii (ang. detection time)- czas, który upływa od awarii pewnego procesu do chwili, gdy zacznie on byd permanentnie podejrzewany Czas trwania pomyłki (ang. mistake duration)- czas potrzebny detektorowi, by zaprzestał podejrzewad poprawny proces Czas pomiędzy kolejnymi pomyłkami (ang. mistake recurrence time)- czas między dwiema kolejnymi pomyłkami Do czterech dodatkowych metryk jakości zaliczamy: Prawdopodobieostwo trafności zapytania (ang. query accuracy probability)prawdopodobieostwo prawdziwości osądu detektora Średni współczynnik pomyłek (ang. average mistake rate)- średnia liczba pomyłek w jednostce czasu Okres pracy bezbłędnej (ang. good period duration)- określona jako długośd okresów czasu, podczas których detektor nie popełnia pomyłek. Przyszły okres pracy bezbłędnej (ang. forward good period duration)- określona jako oczekiwana długośd okresu czasu, który mija między losowo wybranym momentem czasu, a chwilą, w której detektor popełnia kolejną pomyłkę Wszystkie metryki zdefiniowane są dla pary procesów i , gdzie monitoruje i nie ulega awarii (założenia te nie wpływają na ogólnośd wyników). W zależności od wymagao aplikacyjnych przedstawione metryki mogą okazad się niewystarczające. Algorytmy detekcji są bardzo różnorodne, ze względu na wymagania, dotyczące warstwy komunikacyjnej, złożoności komunikacyjnej i czasowej oraz stopnia zawodności. Wiedząc, iż dla programisty każde z tych kryteriów może okazad się ważne, wskazane wydaje się stworzenie metryk, uwzględniających te kryteria. Pamiętając o tym, zaproponowano ocenę nowego algorytmu, biorąc pod uwagę pesymistyczne zapotrzebowanie na pasmo. Znajomośd tego parametru jest niezwykle cenna, gdy należy liczyd się z ograniczonymi zasobami transmisyjnymi. Określa więc on skalowalnośd algorytmu- cechę niezwykle pożądaną nie tylko w przypadku detektorów, ale każdego algorytmu rozproszonego. Natomiast, w innej pracy, podczas pomiarów uwzględniono obciążenie procesora i zużycie pamięci przez algorytm detekcji. Należy tu jednak zauważyd, iż metryka ta odzwierciedla w rzeczywistości jakośd implementacji algorytmu, a nie jakośd samego algorytmu. Czas wykrycia awarii Metryka ta określa, jak już opisano wcześniej, jak szybko detektor jest w stanie wykryd awarię węzła. Określa ona czas, który upływa od awarii pewnego procesu do chwili, gdy zacznie on byd permanentnie podejrzewany. Jest to jedyna i wystarczająca metryka, określająca kompletnośd detektora. Jej wartością jest średni czas , jaki upływa od awarii pewnego procesu (na rysunku poniżej awaria ta ma miejsce w chwili (w przykładzie jest to chwila ). ), do momentu ostatecznego wykrycia awarii przez detektor Czas trwania pomyłki Metryka ta jest w rzeczywistości zmienną losową, reprezentującą czas potrzebny detektorowi, by zaprzestał podejrzewad poprawny proces. W przykładzie widocznym poniżej jest to czas pomiędzy chwilą , w której detektor popełnia błąd, niesłusznie podejrzewając proces , a chwilą , w której koryguje swoją pomyłkę, przestając podejrzewad proces . Okres między kolejnymi pomyłkami Metryka ta określa okres czasu, jaki upływa między dwiema kolejnymi pomyłkami detektora. W przykładzie poniżej w chwili detektor niesłusznie zaczął podejrzewad proces . Po kilku jednostkach czasu skorygował swoją pomyłkę, jednak w chwili ponownie zaczął podejrzewad poprawny proces . Prawdopodobieństwo dokładności zapytania jest prawdopodobieostwem, że informacja dostarczona przez detektor w losowym momencie jest poprawna (ang. accurate). Jest to miara, dotycząca dokładności detektora. Warto tutaj zwrócid uwagę, że dla detektorów, spełniających warunek silnej dokładności (patrz: Własnośd dokładności), metryka ta zawsze przyjmuje wartośd , jeżeli detektory pytane są o stan procesu, działającego poprawnie. Podobnie, jeżeli detektor spełnia warunek silnej kompletności (patrz: Własnośd kompletności), to ostatecznie metryka ta będzie przyjmowad wartośd , jeżeli detektory pytane są o stan węzła wadliwego. Stąd, jeżeli detektor jest klasy P, to od pewnego momentu (a dokładnie od momentu określonego przez metrykę ) będzie zawsze przyjmowad wartośd . Przykład #1: Metryka Okazuje się jednak, iż wspomniana metryka nie jest wystarczająca do stwierdzenia, który z detektorów jest lepszy, ze względu na dokładnośd detekcji. Na poniższym rysunku widad, że dla obydwu detektorów metryka przyjmuje taką samą wartośd- 0,75 (w ciągu jednostek czasu, przez jedną jednostkę detektor się myli, stąd myli się przez jednostki czasu na jednostek czasu, stąd , natomiast detektor ). Detektor jednak popełnia pomyłki rzadziej (raz na jednostek czasu), w związku z czym jest on lepszy, chod w świetle tej metryki obydwa detektory są równie dobre. Dla określenia dokładności detekcji, konieczne jest zatem zdefiniowanie dalszych metryk. Średni współczynnik pomyłek Metryka ta określa średnią liczbę pomyłek, jakie detektor popełnia w jednostce czasu. Ponownie, okazuje się, że jest to metryka nie zawsze wystarczająca do stwierdzenia, który z detektorów jest lepszy. Na powyższym przykładzie wartośd tej metryki wynosi Przykład #2: Metryki i Na poniższym diagramie widad, iż detektor ( , zaś . ) oraz jest lepszy od ( ze względu na parametry , zaś ). jednak szybciej koryguje swoje pomyłki, co dla niektórych aplikacji może mied zasadnicze znaczenie. Widad wyraźnie, że nawet połączenie tych metryk nie jest w stanie odzwierciedlid jakości detekcji. Implementacja detektora awarii Mechanizm pulsu Implementacja detektora, wykorzystująca mechanizm pulsu (ang. heartbeat) polega na tym, że proces monitorowany , co pewien zdefiniowany czas (ang. pulse) wysyła wiadomośd typu „I’m alive”. Odebranie tego typu wiadomości po drugiej stronie łącza komunikacyjnego przez detektor w czasie (ang. timeout) od ostatnio odebranej wiadomości pozwala uznad proces za poprawny. W przeciwnym wypadku detektor zaczyna podejrzewad proces . Warto podkreślid fakt, że w tym scenariuszu aktywnośd leży po stronie procesu monitorowanego, który musi okresowo wysyład wiadomości. Mechanizm odpytywania Implementacja detektora, wykorzystująca mechanizm odpytywania (ang. rolling, interrogation) jest modyfikacją poprzedniego podejścia. Polega na tym, że proces monitorujący, co pewien zdefiniowany okres czasu wysyła pytanie o status typu: „Are you alive?”. Proces monitorowany po odebraniu tego typu wiadomości odpowiada na niego, wysyłając wiadomośd typu „I’m alive”. Jeśli odpowiedź nie dotrze do procesu monitorującego (detektora awarii ) przez zadany czas , to detektor zacznie podejrzewad proces o awarię. Ten schemat monitorowania umożliwia lepszą kontrolę procesu monitorowania, gdyż aktywnośd leży w tym rozwiązaniu po stronie detektora awarii. Implementacja detektora P: mechanizm pulsu Detektor klasy P (ang. perfect failure detector) jest detektorem, który posiada następujące własności: Silna kompletnośd (SC) (patrz: Własnośd kompletności) Silna dokładnośd (SA) (patrz: Własnośd dokładności) SA P Q SC WC WA S W ESA P Q EWA S W Algorytm, wykorzystujący mechanizm pulsu (ang. heartbeat) w celu implementacji doskonałego detektora awarii zakłada: Dostępnośd niezawodnych kanałów komunikacyjnych łączących procesy (ang. perfect point-to-point links) Synchroniczny model systemu Znany jest maksymalny czas transmisji komunikatu. W porównaniu do tej wartości czasy przetwarzania lokalnego i ewentualnie rozregulowania zegara lokalnego (przesunięcia, ang. drift) są pomijalnie małe Koncepcja algorytmu Algorytm wykorzystuje zegary lokalne procesów, które co stały odcinek czasu inicjują operację wysłania wiadomości do wszystkich procesów. Długośd jest tak dobrana, by wszystkie wysłane wiadomości mogły dotrzed do detektora. Brak wiadomości od pewnego procesu w danym okresie powoduje dodanie go do zbioru , o ile już się w tym zbiorze nie znajduje, co jest określane jako wykrycie awarii przez detektor procesu . Zdarzenia cykliczne Niech: Oznacza zdarzenie cykliczne, zachodzące w procesie w związku z upływem okresu czas o długości czasu lokalnego. Przypisanie nowej wartości zmiennej implikuje odpowiednią zmianę czasu, po którym zajdzie kolejne zdarzenie . W przedstawionym dalej algorytmie używane są dodatkowo dwa oznaczenia: - cykliczne zdarzenie upływu czasu maksymalnego oczekiwania na otrzymanie pulsu - cykliczne zdarzenie upływu czasu wysłania pulsu Algorytm Algorytm używa wiadomości typu HEARTBEAT. Zbiór zawiera identyfikatory procesów, podejrzewanych przez detektor , działający w monitorze . Zbiór ten jest początkowo pusty. Zmienna określa długośd maksymalnego czas oczekiwania na otrzymanie wiadomości typu HEARTBEAT (pulsu). Zmienna określa długośd czasu pomiędzy wysłaniem dwóch kolejnych wiadomości HEARTBEAT (pulsu). type HEARTBEAT extends FRAME : HEARTBEAT : set of PROCESS_ID : set of PROCESS_ID : INTEGER : INTEGER 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. /* Co pewien czas algorytm sprawdza, które procesy należy zacząd podejrzewad. Jeżeli nie otrzymano w ostatnim czasie wiadomości typu HEARTBEAT od danego procesu (nie znajduje się on w zbiorze ) i nie jest on jeszcze podejrzewany, to dołączany on jest do zbioru podejrzewanych procesów. */ when do for all do if then end if end for end when /* Co pewien czas rozsyłane są wiadomości typu HEARTBEAT do wszystkich pozostałych procesów */ when do for all do 12. 13. 14. end for end when /* Otrzymanie wiadomości typu HEARTBEAT od procesu powoduje dodanie go do zbioru procesów poprawnych detektora */ when do 15. 16. end when Implementacja detektora P: mechanizm pulsu Ostatecznie doskonały detektor awarii P (ang. eventually perfect failure detector) posiada następujące własności: silna kompletnośd (SC) (patrz: Własnośd kompletności) ostatecznie silna dokładnośd (ESA) (patrz: Własnośd dokładności) Algorytm, wykorzystujący mechanizm pulsu (ang. heartbeat) w celu implementacji ostatecznie doskonałego detektora awarii P zakłada: dostępnośd niezawodnych kanałów komunikacyjnych częściowo synchroniczny model systemu czasy przetwarzania lokalnego i przesunięcia zegarów lokalnych (ang. drift) są pomijalnie małe w porównaniu do maksymalnego czasu transmisji komunikatu Implementacja będzie wykorzystywała technikę pulsu opartą na okresowym rozsyłaniu wiadomości przez proces monitorowany. Koncepcja algorytmu Algorytm wykorzystuje zegar lokalny procesu Proces , co pewien stały okres czasu o długości , inicjuje operację wysłania wiadomości do wszystkich procesów. Procesy, od których, w pewnym okresie czasu o długości , nie otrzymano wiadomości (pulsu), dodawane są do zbioru procesów podejrzewanych o awarię ( ) przez detektor procesu . W przypadku stwierdzenia pomyłki, długośd okresu jest zwiększana. Podstawowa różnica w stosunku do uprzednio omówionego algorytmu dla doskonałego detektora P polega na zwiększaniu w przypadku wykrycia pomyłki. Z założeo, dotyczących środowiska wynika, że ostatecznie stała ta będzie większa niż maksymalne możliwe opóźnienie transmisji. Algorytm type HEARTBEAT extends FRAME : HEARTBEAT : set of PROCESS_ID : set of PROCESS_ID : INTEGER : INTEGER 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. /* Proces detekcji wywoływany jest co pewien czas . Detektor dołącza wszystkie procesy, które nie należą do zbioru (czyli takie, od których nie otrzymano ostatnio wiadomości typu HEARTBEAT) do zbioru . Jest to równoznaczne z rozpoczęciem podejrzewania tych procesów. Jeśli natomiast proces należy zarówno do zbioru , jak i do zbioru to oznacza to, że detektor popełnił pomyłkę, która powinna byd skorygowana. W takim przypadku proces przestaje byd podejrzewany oraz zwiększany jest czas (o pewną stałą ), po którym procesy zostają uznane za podejrzane, jeśli nie nadejdzie od nich żadna wiadomośd typu HEARTBEAT */ when do for all do if then else if then end if end if end for end when /* Co pewien czas rozsyłane są wiadomości typu HEARTBEAT do wszystkich pozostałych procesów */ when do for all do 19. end for end when /* Otrzymanie wiadomości typu HEARTBEAT od procesu powoduje dodanie go do zbioru procesów poprawnych detektora */ when do 20. 21. end when Problem wyboru lidera W systemach rozproszonych bywają sytuacje, w których problemem nie jest wykrycie, które procesy uległy awarii, ale wspólne uzgodnienie (przez wszystkie poprawne procesy) wyboru jednego procesu, który wciąż jest poprawny, i któremu wszystkie inne procesy ufają (nie podejrzewają). Detektor wspomagający wybór jednego zaufanego procesu określany jest jako detektor lidera . Taki zaufany proces może działad jako koordynator, niezbędny w pewnych rozproszonych algorytmach. Stąd też problem ten nazywa się problemem wyboru lidera (ang. eventual leader election). Wprowadzimy obecnie abstrakcję detektora , inaczej detektora ostatecznego lidera (ang. eventual leader detector), wykonującego algorytm wyboru lidera. Mechanizm ten ma zapewniad, że wszystkie poprawne procesy zgodzą się ostatecznie na wybór tego samego procesu. Mechanizm wyboru ostatecznego lidera posiada następujące własności: ostateczna dokładnośd (ang. eventual accuracy)- oznacza, że istnieje pewna chwila czasu, po której wszystkie poprawne procesy ufają (nie podejrzewają) pewnego poprawnego procesu ostateczna zgodnośd (ang. eventual agreement)- oznacza, że istnieje pewna chwila czasu, po której nie ma dwóch takich poprawnych procesów, które ufałyby dwóm różnym procesom Własności te oznaczają, że chociaż w czasie działania algorytmu lider może się zmieniad w dowolny sposób, jednakże ostatecznie wszystkie procesy zaczynają ufad jednemu liderowi i wyboru swojego już nie zmieniają- wybór lidera stabilizuje się. Algorytm wyboru ostatecznego lidera Rozważad będziemy teraz rozwiązanie problemu wyboru lidera dla klasy awarii powtarzalnych (patrz: Klasy awarii procesów) przy następujących założeniach: Procesy są odtwarzalne, co oznacza dostępnośd procedur i dla każdego procesu, które umożliwiają, odpowiednio, zapamiętanie, a później odtworzenie po ewentualnej awarii, wartości wybranych parametrów Kanały komunikacyjne posiadają własności kanałów rzetelnych (patrz: Kanały rzetelne) System charakteryzuje się częściową synchronicznością Koncepcja W celu implementacji mechanizmu detektora ostatecznego lidera można wykorzystad bezpośrednio uprzednio poznaną implementację ostatecznie doskonałego detektora awarii P (patrz: implementacja detektora P). Istotnie, wystarczające do rozwiązania problemu jest wybieranie jako lidera procesu o najwyższym identyfikatorze spośród wszystkich niepodejrzewanych przez ostatecznie doskonały detektor awarii. Ostatecznie, o ile co najmniej jeden proces jest poprawny, wszystkie procesy będą ufad dokładnie jednemu, poprawnemu procesowi. Ponieważ jednak dalej będziemy rozważad awarie powtarzalne, konieczne jest wprowadzenie dodatkowego warunku, który musi zostad spełniony przez potencjalnego lidera- liczba awarii takiego procesu powinna byd najmniejsza spośród wszystkich procesów. Algorytm Przedstawiony poniżej algorytm używa wiadomości HEARTBEAT, które zawierają numer epoki w polu . Epoką określa się okres poprawnego działania procesu, który może zostad ewentualnie zakooczony awarią procesu. Po awarii następuje odtwarzanie działania procesu (ang. recovery), przy czym każde odtworzenie oznacza początek nowej epoki. Dodatkowo zdefiniowano typ TRUSTED jako rekord, zawierający pole identyfikatora procesu oraz , zawierające numer epoki procesu w chwili, gdy został wybrany jako kandydat na lidera. Podobnie jak w poprzednich algorytmach, stosowany jest mechanizm pulsu (patrz: Mechanizm pulsu): każdy proces wysyła cyklicznie wiadomości typu HEARTBEAT. Inne używane zmienne to: typu PROCESS_ID zawiera identyfikator bieżącego lidera dla procesu . Analogicznie, zmienna zawiera identyfikator poprzedniego lidera dla procesu . Elementy zbioru są parami, składającymi się z identyfikatorów możliwych kandydatów na lidera i numerów epoki. zawiera numer epoki, odzwierciedlający liczbę awarii i wznowieo pracy procesu oraz są wykorzystywane przez funkcję określa długośd czasu pomiędzy wysłaniem dwóch kolejnych wiadomości typu HEARTBEAT (pulsu). Jej wartośd początkowa jest równa stałej określa długośd okresu czasu między kolejnymi wywołaniami wyboru lidera. Jej początkowa wartośd jest równa stałej type HEARTBEAT extends FRAME is record of : INTEGER end record type TRUSTED is record of : PROCESS_ID : INTEGER end record : HEARTBEAT : PROCESS_ID : PROCESS_ID : set of TRUSTED : INTEGER : TRUSTED : TRUSTED : INTEGER : INTEGER 1. 2. 3. 4. 5. 6. 7. /* Funkcja wybiera dla danego zbioru (podanego jako argument) jako lidera proces o najmniejszej liczbie awarii, którego identyfikator jest najmniejszy */ function for do for all do if then else if then 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. end if end if end for end for return end function /* Co pewien czas procesy sprawdzają, czy bieżący lider może nim pozostad. W tym celu wywołują funkcję , która wybiera jeden proces ze zbioru . Jeżeli w wyniku wykonania tego kroku algorytmu lider się zmieni, zwiększane jest opóźnienie między kolejnymi próbami odnalezienia lidera. Jeżeli wybrano nowego lidera, proces zaczyna mu ufad. Symbol oznacza pewną stałą dobraną przez użytkownika */ when do if then if then end if end if end when /* Równolegle do powyższej procedury, co pewien czas wszystkich pozostałych procesów swój bieżący numer epoki */ when do for all proces wysyła do do end for end when /* Po otrzymaniu wiadomości typu HEARTBEAT od procesu , proces sprawdza, czy proces ten znajduje się już w zbiorze . Jeżeli tak, to następuje sprawdzenie, czy przesłana wartośd numeru epoki jest większa niż obecnie przechowywana dla -tego procesu. Jeżeli jest większa, to następuje usunięcie danego elementu ze zbioru , a następnie jego ponowne dodanie z uaktualnioną wartością numeru epoki. Jeżeli zaś warunek pierwszy jest niespełniony, tzn. jeżeli nie ma w zbiorze takiego procesu, to jest on dodawany wraz z przesłaną wartością numeru epoki do zbioru */ when do if then if end if then 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. else end if end when /* Po każdym wznowieniu procesu, wczytany jest numer epoki za pomocą procedury . Wszystkie pozostałe zmienne, wchodzące w skład stanu procesu są inicjowane wartościami początkowymi. Następnie numer ten jest zwiększany o jeden, zapisany do pamięci dyskowej za pomocą procedury oraz rozesłany do wszystkich monitorów */ when do for all do end for end when Modele przetwarzania Złożenie różnych założeo, dotyczących procesów, rodzajów kanałów komunikacyjnych, czy też klas detektorów awarii jest równoznaczne ze zdefiniowaniem specyficznych modeli przetwarzania. Istnieje oczywiście bardzo wiele możliwych kombinacji przyjmowanych założeo, a stąd wiele modeli. W literaturze rozważane są na ogół następujące modele: model z jawnymi awariami (ang. fail-stop) Procesy wykonują deterministyczne algorytmy, chyba że zaprzestaną działania w wyniku awarii Kanały są niezawodne Dostępny jest doskonały detektor awarii Rozwiązywanie problemów w tym modelu jest stosunkowo łatwe model z ukrytymi awariami (ang. fail-silent) Procesy wykonują deterministyczne algorytmy, chyba że zaprzestaną działania w wyniku awarii Kanały są niezawodne Brak dostępu do doskonałego detektora awarii model z ostatecznie jawnymi awariami (ang. fail-noisy) Procesy wykonują deterministyczne algorytmy, chyba że zaprzestaną działania w wyniku awarii Kanały są niezawodne Dostępny jest ostatecznie doskonały detektor awarii lub detektor typu model ze wznowieniami po awariach (ang. fail-recovery) Procesy wykonują deterministyczne algorytmy, chyba że zaprzestaną działania w wyniku awarii Kanały mają własności kanałów wytrwałych (patrz: Kanały wytrwałe) Po awarii działanie procesu jest wznawiane model losowy, probabilistyczny (ang. randomized) Procesom udostępniona jest losowa wyrocznia, dzięki której mogą wybierad jedną z kilku możliwych ścieżek przetwarzania- w tym przypadku algorytmy są niedeterministyczne Wykład #12: Mechanizmy rozgłaszania niezawodnego Plan wykładu: Celem wykładu jest prezentacja zagadnieo związanych z implementacją niezawodnej komunikacji w zawodnym środowisku rozproszonym. a) Podstawowe rozgłaszanie niezawodne b) Zgodne rozgłaszanie niezawodne (algorytm pasywny lub aktywny) c) Jednolite rozgłaszanie niezawodne (algorytm z potwierdzeniami od wszystkich i od większości) d) Probabilistyczne rozgłaszanie niezawodne (algorytm pasywny lub aktywny) e) Zgodne rozgłaszanie niezawodne z przyczynowym uporządkowaniem wiadomości f) Zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości Rozgłaszanie niezawodne Definicja nieformalna Nieformalnie, rozgłaszanie to mechanizm komunikacyjny, za pomocą którego proces może wysład wiadomośd do grupy procesów. Mechanizmy rozgłaszania niezawodnego gwarantują pewne własności, pomimo występowania awarii. Gwarancje te tyczą się przede wszystkim zapewnienia dostarczenia wiadomości do adresatów, identyczności zbioru wiadomości dostarczanych do wszystkich procesów poprawnych, a także kolejności dostarczanych wiadomości. Mechanizmy niezawodnego rozgłaszania mają bardzo wiele zastosowao, stąd wynika ich duże znaczenie teoretyczne i praktyczne. Przykładowymi zastosowaniami mechanizmów niezawodnego rozgłaszania są: Systemy z wieloma uczestnikami (ang. muli-participant systems) W systemach tych działa wiele procesów, współuczestnicząc w skomplikowanych zadaniach. Przykładem są wszelkiego rodzaju wirtualne środowiska z wieloma użytkownikami (na przykład gry MMRPG- massive multiplayer role-playing game). Dostępnośd abstrakcyjnych operacji niezawodnego rozgłaszania jest przydatna dla twórców tego rodzaju systemów. Zwielokrotnianie (replikacja) Często stosowanym rozwiązaniem w celu zwiększenia odporności systemu na awarie lub zwiększenia jego efektywności, jest zwielokrotniania (replikacja) elementów. Pojawia się wówczas jednocześnie problem spójności replik. Konstrukcja protokołów, zapewniających spójnośd replik jest znacząco uproszczone w wypadku możliwości skorzystania z mechanizmów niezawodnego rozgłaszania. Klasy mechanizmów rozgłaszania niezawodnego Podstawowe rozgłaszanie niezawodne (ang. best-effort broadcast) Odpowiedzialnośd za dostarczenie wiadomości spoczywa na nadawcy, o którym zakłada się, że jest poprawny. Zgodne rozgłaszanie niezawodne (ang. regular reliable broadcast) System gwarantuje identycznośd zbioru wiadomości dostarczonych przez wszystkie poprawne procesy. Pasywny algorytm zgodnego rozgłaszania niezawodnego (ang. lazy reliable broadcast) Aktywny algorytm zgodnego rozgłaszania niezawodnego (ang. eager reliable broadcast) Jednolite rozgłaszanie niezawodne (ang. uniform reliable broadcast) System, poza identycznością zbioru wiadomości dostarczonych przez wszystkie poprawne procesy, gwarantuje, że wiadomośd dostarczona przez jeden proces (byd może niepoprawny) zostanie dostarczona przez wszystkie poprawne procesy. Algorytm jednolitego rozgłaszania niezawodnego z potwierdzeniami od wszystkich (ang. all-ack uniform reliable broadcast) Algorytm jednolitego rozgłaszania niezawodnego z potwierdzeniami od większości (ang. majority-ack uniform reliable broadcast) Probabilistyczne rozgłaszanie niezawodne (ang. probabilistic reliable broadcast) Gwarancje, dotyczące dostarczenia wiadomości, są zachowane jedynie z pewnym prawdopodobieostwem. Zgodne rozgłaszanie niezawodne z przyczynowym uporządkowaniem wiadomości (ang. causal reliable broadcast) Gwarantowane jest dodatkowo, że wiadomości przyczynowo zależne będą dostarczone do odbioru zgodnie z relacją poprzedzania. Zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości (ang. total order reliable broadcast) Zapewniona jest natomiast taka sama kolejnośd dostarczania wiadomości do wszystkich poprawnych procesów. Warto zaznaczyd, że własności uporządkowania przyczynowego i globalnego są niezależne. Oznacza to, że uporządkowanie przyczynowe nie implikuje i nie jest implikowane przez uporządkowanie globalne. Nie są to oczywiście jedyne możliwe abstrakcyjne operacje rozgłaszania. Wspomnied warto jeszcze chodby o quasi-niezawodnym rozgłaszaniu. Podstawowe rozgłaszanie niezawodne Specyfikacja Najprostszym rodzajem rozgłaszania jest podstawowe rozgłaszanie niezawodne (ang. best-effort broadcast). Ten podstawowy mechanizm (abstrakcja) komunikacyjny składa odpowiedzialnośd za niezawodnośd na nadawcę. Nie zapewnia przy tym dostarczenia wiadomości do wszystkich procesów, jeżeli nadawca ulegnie awarii. Mechanizm podstawowego rozgłaszania niezawodnego ma następujące własności: Ważnośd (ang. best-effort validity) Jeżeli procesy oraz są poprawne, to każda wiadomośd rozgłaszana przez jest ostatecznie dostarczona do . Ogólnie, jest to własnośd żywotności. Zauważmy, że mimo tej własności zbiory wiadomości dostarczanych przez różne poprawne procesy mogą się różnid. Brak powielania (ang. no duplication) Jeżeli wiadomośd jest dostarczona, to jest dostarczona co najwyżej raz. Jest to ważna gwarancja: jej sens łatwo wyjaśnid za pomocą przykładu, odwołującego się do operacji bankowych. Użytkownik, składający zlecenie przelewu, chciałby mied pewnośd, że zostanie ono wykonane jedynie raz. Brak samogeneracji (ang. no creation) Oznacza, że jeżeli wiadomośd jest dostarczona do procesu , to została ona wcześniej rozgłoszona przez jakiś proces . Innymi słowy, własnośd ta gwarantuje, że kanały nie generują samorzutnie wiadomości. Dwie ostatnie z powyższych cech są czasami w literaturze określane jako integralnośd lub zwartośd (ang. integrity) i są one własnościami bezpieczeostwa. Operacje komunikacyjne Operację podstawowego rozgłaszania niezawodnego wiadomości przez proces do zbioru procesów oznaczad będziemy przez . Zdarzenie, odpowiadające tej operacji, zapisywad będziemy jako . Analogicznie, przez oznaczad będziemy operację, uaktywniającą zdarzenie wiadomośd wysłaną przez proces do procesu aplikacyjnego i przekazującą w efekcie . Algorytm Algorytm podstawowego rozgłaszania niezawodnego zakłada: dostępnośd mechanizmu kanałów niezawodnych (patrz: Wykład 11: Kanały niezawodne) deterministyczne i poprawne działanie procesów do ewentualnego załamania nieodwoływanie się do detektorów awarii, zatem przyjęty jest model przetwarzania z ukrytymi awariami (patrz: Wykład 11: Modele przetwarzania). W rozważanym algorytmie wiadomości aplikacyjne umieszczone są w pakietach typu PACKET. Pakiety te są przesyłane między monitorami. Z odebranych pakietów monitory wyodrębniają wiadomości aplikacyjne i przekazują je procesom aplikacyjnym. type PACKET extends FRAME is record of : MESSAGE end record : MESSAGE : PACKET 1. 2. 3. /* Przypomnijmy, że operacja jest mechanizm kanałów niezawodnych. Operacja ta gwarantuje zatem, że każda wiadomośd wysłana przez poprawnie działający proces, ostatecznie dotrze do adresata i umożliwi wówczas zajście zdarzenia oraz wykonanie dalej operacji */ when do for all do 4. 5. 6. // mechanizm kanałów niezawodnych end for end when /* Warto przypomnied, że w algorytmie, implementującym kanały niezawodne, monitor, otrzymując dowolną wiadomośd, dostarcza ją tylko wtedy, gdy nie była ona już wcześniej dostarczona */ when do 7. 8. 9. 10. end when Złożoność Niech topologią rozważanego przetwarzania rozproszonego jest graf pełny. Przy tym założeniu, rozgłaszanie wiadomości wymaga jednego kroku algorytmu, związanego z wysłaniem wiadomości. Ponieważ algorytm, realizujący podstawowe rozgłaszanie niezawodne, wymaga, by nadawca wysłał wiadomośd do wszystkich procesów (łącznie z samym sobą), jego złożonośd komunikacyjna , gdzie jest liczbą procesów przetwarzania rozproszonego. Złożonośd czasowa wynosi . Przykład: W przedstawionym wyżej przykładzie proces chce rozesład wiadomośd . Podstawowe rozgłaszanie niezawodne polega na wysłaniu tej wiadomości oddzielnie do każdego procesu, należącego do zbioru procesów , korzystając oczywiście z niezawodnych kanałów. Przypomnijmy, że niezawodne kanały autonomicznie ponawiają transmisję, pod warunkiem jednak, że proces nadawcy działa poprawnie. Zgodne rozgłaszanie niezawodne Specyfikacja Mechanizm zgodnego rozgłaszania niezawodnego (ang. regular reliable broadcast) zapewnia dostarczenie wiadomości nawet w przypadku, gdy nadawca ulegnie awarii, jeżeli tylko jakikolwiek proces poprawny odebrał rozgłaszaną wiadomośd. Mechanizm ten ma z definicji następujące własności: Ważnośd (ang. validity) Jeżeli proces jest poprawny, to każda wiadomośd rozgłaszana przez ten proces jest ostatecznie dostarczona do . Warto zauważyd różnicę tej własności w porównaniu z własnością ważności dla podstawowego rozgłaszania niezawodnego (patrz: Podstawowe rozgłaszanie niezawodne) Brak powielania (ang. no duplication) Oznacza, że jeżeli wiadomośd jest dostarczona, to jest dostarczona co najwyżej raz. Brak samogeneracji (ang. no creation) Oznacza, że jeżeli jakaś wiadomośd jest dostarczona do procesu , to została ona wcześniej rozgłoszona przez jakiś proces (kanały nie tworzą wiadomości samorzutnie). Zgodnośd (ang. agreement) Oznacza, że jeżeli jakaś wiadomośd została odebrana przez pewien poprawny proces , to ostatecznie wszystkie poprawne procesy odbiorą tę wiadomośd. Własnośd ta określa podstawową różnicę w stosunku do podstawowego rozgłaszania niezawodnego, gdyż zapewnia, że wiadomości mogą zostad dostarczone nawet w przypadku, gdy ich nadawca uległ awarii. Równocześnie, własnośd ta w połączeniu z własnością ważności oznacza, że wiadomości rozgłaszane przez poprawny proces ostatecznie zostaną odebrane przez wszystkie poprawne procesy. Zgodne rozgłaszanie niezawodne często określane jest jako niepodzielne lub atomowe (ang. atomic broadcast), gdyż gwarantuje, że albo wszystkie poprawne procesy odbiorą rozgłaszaną wiadomośc, albo żaden z nich. Operacje komunikacyjne Operację rozgłaszania, gwarantującą własności zgodnego rozgłaszania niezawodnego oznaczymy przez . Zdarzenie, odpowiadające tej operacji, zapisywad będziemy jako . Analogicznie, przez oznaczad będziemy operację, uaktywniającą zdarzenie przez proces do procesu aplikacyjnego i przekazującą w efekcie wiadomośd wysłaną . Algorytm pasywny Pasywny algorytm zgodnego rozgłaszania niezawodnego (ang. lazy reliable broadcast) zakłada, że dostępne są następujące mechanizmy: doskonały detektor awarii (patrz: Wykład 11: Doskonały detektor awarii) podstawowe rozgłaszanie niezawodne algorytm przeznaczony jest zatem dla modelu przetwarzania z jawnymi awariami (patrz: Wykład 11: Modele przetwarzania) Zagwarantowanie własności zgodności uzyskuje się dzięki retransmisjom wiadomości, dokonywanym w chwili wykrycia awarii nadawcy przez doskonały detektor awarii. W rozważanym algorytmie wiadomości aplikacyjne są umieszczane w pakietach typu PACKET, zawierających dodatkowo identyfikator pierwotnego (oryginalnego) nadawcy wiadomości. Algorytm korzysta również ze zmiennych m.in. - zawiera identyfikatory procesów uznawanych za poprawne przez proces zbiór , złożony z wiadomości, które już zostały odebrane przez tablica zawiera zbiory, których elementami są pary, składające się z identyfikatora pierwotnego nadawcy wiadomości i samej wiadomości aplikacyjnej. Odpowiednio -ty element tej tablicy to wiadomości przekazane przez monitor . oraz procesu są używane lokalnie w programie obsługi zdarzenia wykrycia awarii type PACKET extends FRAME is record of : PROCESS_ID : MESSAGE end record : MESSAGE : PACKET : set of PROCESS_ID : set of MESSAGE : array of set of pair of : PROCESS_ID : MESSAGE 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. /* Monitor procesu , chcącego rozesład wiadomośd , umieszcza ją w pakiecie, zawierającym dodatkowo pole , oznaczającego pierwotnego nadawcę wiadomości i rozsyła otrzymany pakiet za pomocą podstawowego rozgłaszania niezawodnego. Przypomnijmy, że oznacza zbiór monitorów wszystkich procesów, tworzących zbiór */ when do end when /* Odebranie pakietu przez monitor od monitora powoduje sprawdzenie, czy wiadomośd aplikacyjna zawarta w pakiecie nie była już wcześniej dostarczona do . Jeżeli nie, to wiadomośd ta zostaje dostarczona. Następnie wiadomośd zostaje dodana do zbioru, będącego -tym elementem tablicy . Jeżeli proces jest niepoprawny, to monitor rozsyła ponownie otrzymany pakiet za pomocą podstawowego rozgłaszania niezawodnego */ when do if then if end if end if end when then 17. 18. 19. 20. 21. 22. 23. 24. /* W przypadku wykrycia awarii procesu przez doskonały detector awarii P proces ten usuwany jest ze zbioru oraz ponownie są rozsyłane wszelkie pakiety kiedykolwiek otrzymane od tego procesu */ when do for all do end for end when Złożoność Załóżmy, że topologią przetwarzania rozproszonego jest graf pełny. Jeżeli początkowo nadawca wiadomości nie ulega awarii (przypadek optymistyczny), pasywny algorytm rozgłaszania niezawodnego kooczy się w jednym kroku po wysłaniu komunikatów. Stąd złożonośd czasowa dla przypadku optymistycznego wynosi , zaś złożonośd komunikacyjna- . W przypadku, w którym kolejno ulegają awarii wszystkie procesy (przypadek pesymistyczny), odbierające tę wiadomośd, i wiadomośd jest ostatecznie odebrana tylko przez jedyny poprawny proces, złożonośd czasowa wynosi . Ponieważ w każdym kroku komunikaty wysłane są do wszystkich procesów, a każdy z nich retransmituje każdą wiadomośd co najwyżej raz, złożonośd komunikacyjna wynosi . Algorytm aktywny Zgodne rozgłaszanie niezawodne można także zrealizowad za pomocą algorytmu pasywnego (ang. eager reliable broadcast), który ma następujące cechy: nie wymaga użycia doskonałego detektora awarii zakłada istnienie mechanizmu podstawowego rozgłaszania niezawodnego Algorytm został przeznaczony zatem dla modelu ukrytych awarii (patrz: Wykład 11: Modele przetwarzania) Podstawowa różnica w stosunku do poprzedniego algorytmu polega na retransmisji wiadomości przez każdy proces natychmiast po jej dostarczeniu Algorytm używa tylko jednego typu wiadomości- PACKET- o strukturze identycznej, jak w poprzedniej realizacji rozgłaszania niezawodnego. Również znaczenie stosowanych zmiennych nie różni się od analogicznych zmiennych w algorytmie pasywnego rozgłaszania niezawodnego. type PACKET extends FRAME is record of : PROCESS_ID : MESSAGE end record : MESSAGE : PACKET : set of MESSAGE 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. /* W porównaniu z algorytmem pasywnym, rozesłanie wiadomości aplikacyjnej różni się tylko natychmiastowym dostarczeniem jej do lokalnego procesu. Rozgłaszanie rozsyła wiadomości do wszystkich procesów łącznie z nadawcą */ when do end when /* Podczas odbioru pakietu monitor sprawdza, czy zawarta w pakiecie wiadomośd nie została już wcześniej dostarczona. Jeżeli nie, to dostarcza tę wiadomośd do procesu aplikacyjnego i zapamiętuje ten fakt, dodając wiadomośd do zbioru . Następnie, monitor rozsyła otrzymany pakiet za pomocą podstawowego rozgłaszania niezawodnego do wszystkich monitorów ze zbioru */ when do if then end if end when Przykład #1: W pokazanym powyżej przykładzie widad zasadniczą różnicę w stosunku do wcześniej pokazywanego podstawowego rozgłaszania niezawodnego. Jeżeli rozgłosił wiadomośd , to każdy otrzymujący ją proces, zarówno , jak i , natychmiast rozsyłają ją do wszystkich pozostałych procesów. Widad, że nawet gdyby proces uległ awarii przed wysłaniem wiadomości do innych procesów niż , to poprawnośd procesu zapewniłaby ostateczne dostarczenie tej wiadomości do wszystkich innych poprawnych procesów. Przykład #2: W tym przykładzie, procesy oraz ulegają awarii zanim zdążą rozesład wiadomośd do wszystkich procesów. Nie narusza to poprawności algorytmu, gdyż wiadomośd nie została odebrana przez żaden poprawny proces, a więc spełniony jest warunek zgodności. Złożoność Przyjmijmy, że topologia przetwarzania rozproszonego jest reprezentowana przez graf pełny. Jeżeli początkowy nadawca wiadomości nie ulega awarii (przypadek optymistyczny), to aktywny algorytm zgodnego rozgłaszania niezawodnego kooczy się w pojedynczym kroku, zatem ma złożonośd czasową równą , zaś złożonośd komunikacyjna wynosi . Jeżeli wszystkie procesy kolejno ulegają awarii (przypadek pesymistyczny), złożonośd czasowa wynosi . Każdy z procesów, ulegających awarii może wysład wiadomości, ale byd może tylko jedna z nich dotrze do adresata. Złożonośd komunikacyjna jest równa, podobnie jak w przypadku optymistycznym, . Jednolite rozgłaszanie niezawodne Specyfikacja Kolejną z omawianych abstrakcji komunikacyjnych rozgłaszania niezawodnego jest jednolite rozgłaszanie niezawodne (ang. uniform reliable broadcast). Główną różnicą w stosunku do mechanizmów omawianych wcześniej, jest wymóg, by zbiór wiadomości dostarczonych przez procesy niepoprawne zawsze był podzbiorem zbioru wiadomości odebranych przez procesy poprawne. Mechanizm ten ma z definicji następujące własności: Ważnośd (ang. validity) Jeżeli proces jest poprawny, to każda wiadomośd rozgłaszana przez ten proces jest ostatecznie dostarczona do . Własnośd ta jest równoważna jej odpowiednikowi w zgodnym rozgłaszaniu niezawodnym. Brak powielania (ang. no duplication) Jeżeli wiadomośd jest dostarczona, to jest dostarczona co najwyżej raz. Brak samogeneracji (ang. no creation) Jeżeli jakaś wiadomośd jest dostarczona do procesu , to została ona wcześniej rozgłoszona przez jakiś proces . Innymi słowy, kanały nie mogą samorzutnie tworzyd wiadomości. Jednolita zgodnośd (ang. uniform agrement) Jeżeli jakaś wiadomośd została odebrana przez pewien proces (poprawny, bądź niepoprawny), to ostatecznie wszystkie poprawne procesy odbiorą tę wiadomośd. Własnośd ta jest szczególnie ważna, jeżeli proces dokonuje interakcji ze światem zewnętrznym, zwłaszcza, jeżeli efekty tej interakcji są nieodwracalne (np. wydruk dokumentu, przelew bankowy itd.) Operacje komunikacyjne Operację jednolitego rozgłaszania niezawodnego wiadomości przez do zbioru procesów oznaczad będziemy przez . Zdarzenie, odpowiadające tej operacji, zapisywad będziemy jako . Analogicznie, przez oznaczad będziemy operację, uaktywniającą zdarzenie wysłaną przez proces do procesu aplikacyjnego i przekazującą w efekcie wiadomośd . Algorytm z potwierdzeniami od wszystkich Algorytm jednolitego rozgłaszania niezawodnego z potwierdzeniami od wszystkich (ang. all-ack uniform reliable broadcast) ma następujące cechy: Realizuje mechanizm jednolitego rozgłaszania niezawodnego w modelu jawnych awarii (patrz: Wykład 11: Modele przetwarzania) Wykorzystuje on podstawowe rozgłaszanie niezawodne Zakłada istnienie niezawodnych kanałów komunikacyjnych (patrz: Wykład 11: Kanały niezawodne) Dostępny jest doskonały detektor awarii (patrz: Wykład 11: Klasyfikacja detektorów) W algorytmie tym wiadomośd jest odbierana przez proces tylko wtedy, gdy proces ten zaobserwował retransmisję tej wiadomości przez wszystkie poprawne procesy. Większośd zmiennych używanych przez prezentowany niżej algorytm ma znaczenie identyczne, jak w przypadku pasywnego algorytmu zgodnego rozgłaszania niezawodnego. Dwie nowe zmienne to: , zawierający pakiety z wiadomościami, które oczekują na dostarczenie , zawierający pary: pakiet, zbiór identyfikatorów procesów Dalej omawiana funkcja używa lokalnych zmiennych , będącej zbiorem identyfikatorów procesów, typu PACKET oraz zmiennej typu PROCESS_ID. Zmienne typu PACKET używana jest lokalnie podczas próby odnalezienia pakietów, które mogą zostad dostarczone do procesu aplikacyjnego type PACKET extends FRAME is record of : PROCESS_ID : MESSAGE end record : MESSAGE : PACKET : set of PROCESS_ID : set of MESSAGE : set of PACKET : set of pair of : set of PROCESS_ID : PACKET : PROCESS_ID : PACKET 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. /* Funkcja zwraca identyfikatory wszystkich procesów, które dokonały już retransmisji pakietu */ function do for all do end for return end function /* Wysyłając wiadomośd , monitor umieszcza ją w pakiecie , który jest dodany do zbioru , po czym zostaje rozgłoszony za pomocą podstawowego rozgłaszania niezawodnego */ when do end when /* Obsługa awarii procesu odbywa się w tradycyjny sposób, jako efekt działania detektora awarii */ when do end when /* Odbierane pakiety monitor dodaje do zbioru wraz z informacją o identyfikatorze nadawcy. Nadawca pakietu może się różnid od pierwotnego nadawcy, będąc jedynie pośrednikiem w przekazaniu wiadomości. Jeżeli dostarczony pakiet nie zawiera się jeszcze w zbiorze , to jest do niego dodawany, a następnie rozsyłany za pomocą podstawowego rozgłaszania niezawodnego */ when do if then end if end when /* Wiadomośd jest dostarczana do procesu aplikacyjnego dopiero wtedy, gdy monitor otrzyma tę wiadomośd w wyniku retransmisji od wszystkich poprawnych procesów */ when do 26. 27. end when Przykład #1: W podanym przykładzie wiadomośd jest rozgłaszana przez proces ( ), który następnie ulega awarii. Dla zwiększenia czytelności, pominięto strzałki, oznaczająec fakt wysłania przez proces wiadomości do samego siebie oraz od procesów i . W nawiasach klamrowych podano zawartośd zbioru procesów. Zauważmy, że wiadomośd dotarła jedynie do monitora , który przesłał ją dalej do pozostałych procesów, ale nie dostarczył do . Po otrzymaniu wiadomości od , monitor rozsyła ją ponownie. Wiadomośd ta dociera do , w wyniku czego do zbioru dodawany jest proces . Monitor postępuje identycznie: odbierając wiadomośd od , rozsyła ją, wstrzymując jednak dostarczenie do procesu aplikacyjnego . Gdy wiadomośd dotarła do monitora od i , zbiór został powiększony o identyfikatory i . W tym momencie monitor może już dostarczyd wiadomośd do procesu aplikacyjnego , gdyż wie, że dotarła do monitorów wszystkich poprawnych procesów. Analogicznie postępują monitory i . Algorytm z potwierdzeniami od większości Rozważany algorytm zakłada: dostępnośd podstawowego rozgłaszania niezawodnego nie jest wymagany detektor awarii, zatem przyjęty jest model przetwarzania z ukrytymi awariami (patrz: Wykład 11: Modele przetwarzania). Wymagane jest jednak, by większośd procesów nie ulegała awarii Przy powyższych założeniach jednolite rozgłaszanie niezawodne można zaimplementowad za pomocą algorytmu z potwierdzeniami od większości. Różni się on od poprzednio omawianego tylko tym, że nie jest używany doskonały detektor awarii, a także warunkiem dostarczenia wiadomości sformułowanym w wierszu 24. algorytmu z potwierdzeniami od wszystkich. Pozostałe kroki są identyczne. Warunek, odróżniający algorytm od poprzednio przedstawionego, oznacza tutaj oczekiwanie na nadejście wiadomości od większości procesów, w tym od co najmniej jednego poprawnego. 1. … 2. when 3. 4. 5. end when do Złożoność Zarówno w przypadku algorytmu z potwierdzeniami od wszystkich, jak i od większości ich złożoności są identyczne. Jak zwykle, rozważając złożonośd czasową i komunikacyjną przyjmiemy, że topologia przetwarzania rozproszonego ma postad grafu pełnego. Jeżeli początkowy nadawca wiadomości nie ulega awarii (przypadek optymistyczny), to algorytm jednolitego rozgłaszania niezawodnego z potwierdzeniami od wszystkich kooczy się w ciągu kroków, po wysłaniu komunikatów przez oryginalnego nadawcę i ich retransmisję przez wszystkie pozostałych procesów, z których każdy wysyła komunikatów. Złożonośd czasowa wynosi więc , a złożonośd komunikacyjna- . W przypadku pesymistycznym, w którym kolejno ulegają awarii wszystkie procesy, złożonośd czasowa wynosi n+1, a komunikacyjna- . Probabilistyczny algorytm rozgłaszania niezawodnego Problem implozji potwierdzeń Jak widad z wcześniej przedstawionych algorytmów, implementacja niezawodnego rozgłaszania w zawodnym środowisku, w którym zarówno łącza, jak i procesy mogą ulegad awariom, może wymagad zbierania potwierdzeo od wielu procesów. Staje się to problematyczne w przypadku, gdy liczba procesów, biorących udział w przetwarzaniu rozproszonym rośnie. Zadanie zebrania potwierdzeo od dużej grupy procesów może w efekcie zajmowad poważną częśd zasobów (pamięci, czasu procesora) węzłów systemu rozproszonego. Tym samym, im więcej uczestników rozgłaszania, tym więcej potwierdzeo do zebrania- problem implozji potwierdzeo (ang. ack implosion problem). Problem implozji potwierdzeo można rozwiązad za pomocą grupowania procesów w hierarchiczne struktury, na przykład drzewa binarne. Dzięki temu obciążenie każdego procesu ulega zmniejszeniu, kosztem jednak zwiększenia czasu potrzebnego na zebranie wszystkich potwierdzeo. Niestety, w przypadku awarii któregoś z procesów, pojawia się potrzeba często czasochłonnej rekonfiguracji używanych struktur. Specyfikacja Problem implozji potwierdzeo wymusił poszukiwanie rozwiązao lepiej skalowalnych niż rozważane poprzednio. Interesującą propozycją jest podejście probabilistyczne, oparte na przykładach zaczerpniętych z rzeczywistości- takich jak szerzenie się chorób zakaźnych albo rozpowszechnianie plotek. Stąd tego typu mechanizmy (algorytmy) nazwany algorytmami epidemicznymi (ang. epidemic), czy też plotkarskimi (ang. gossiping, rumor mongering). Korzystają one z abstrakcji komunikacyjnej określanej jako probabilistyczne rozgłaszanie niezawodne (ang. probabilistic reliable broadcast). Mechanizmy probabilistycznego rozgłaszania niezawodnego charakteryzują się następującymi własnościami: Ważnośd (ang. probabilistic validity) Określone jest prawdopodobieostwo takie, że jeżeli procesy oraz są poprawne, to każda wiadomośd rozgłaszana przez proces jest ostatecznie dostarczona do z tym prawdopodobieostwem. Dopuszczalne, chod oczywiście niepożądane, są zatem sytuacje, w których wiadomośd rozgłaszana nie jest dostarczona do wszystkich poprawnych procesów, nawet jeżeli nadawca wiadomości był poprawny. Widad tutaj podobieostwo, do podstawowego rozgłaszania niezawodnego. W pewnym sensie podstawowe rozgłaszanie niezawodne również można by określid mianem probabilistycznego. W przypadku probabilistycznego rozgłaszania niezawodnego prawdopodobieostwo nie jest jednak bezpośrednio związane z możliwością awarii procesu. Brak powielania (ang. no duplication) Jeżeli wiadomośd jest dostarczona, to jest dostarczona co najwyżej raz. Brak samogeneracji (ang. no creation) Jeżeli jakaś wiadomośd jest dostarczona do procesu , to została ona wcześniej rozgłoszona przez jakiś proces . Operacje komunikacyjne Operację probabilistycznego rozgłaszania niezawodnego wiadomości przez do zbioru procesów oznaczad będziemy przez . Zdarzenie, odpowiadające tej operacji, zapisywad będziemy jako . Analogicznie, przez oznaczad będziemy operację, uaktywniającą zdarzenie wysłaną przez proces do procesu aplikacyjnego i przekazującą w efekcie wiadomośd . Idea algorytmu plotkowania Ogólna idea algorytmu, wykorzystującego mechanizm plotkowania przedstawiona jest na rysunku. Każdy proces wybiera losowo procesów, do których następnie wysyła wiadomośd. Identycznie postępuje każdy proces po odebraniu wiadomości. Im większe , tym więcej wymienianych wiadomości, ale zarazem mniejsza liczba rund potrzebna, by wiadomośd dotarła do wszystkich poprawnych procesów z danym prawdopodobieostwem. Algorytm aktywny W przeciwieostwie do dotychczas przedstawianych algorytmów, aktywny algorytm niezawodnego rozgłaszania probabilistycznego (ang. eager probabilistic reliable broadcast) nie posiada żadnych szczególnych wymagao. W istocie, każde rzeczywiste użyteczne łącze komunikacyjne powinno spełniad warunki, pozwalające uznad je za kanał rzetelny (patrz: Wykład 11: Kanały rzetelne). Algorytm składa się z co najwyżej rund, przy czym w każdej rundzie rozsyłane jest co najwyżej wiadomości, gdzie oraz są liczbami dobranymi przez użytkownika. W zapisie algorytmu będą one reprezentowane odpowiednio przez zmienne oraz . Struktura wiadomości PACKET używana przez aktywne probabilistyczne rozgłaszanie niezawodne różni się od dotychczasowych dodatkowym polem , zawierającym licznik pozostałego czasu życia pakietu. Znaczenie niektórych zmiennych jest następujące: oznacza, ilu adresatów ma zostad wylosowanych przy rozsyłaniu wiadomości. Im większa jej wartośd, tym większe obciążenie procesów i większa liczba nadmiarowo przesyłanych wiadomości- ale zarazem, tym większe prawdopodobieostwo dostarczenia wiadomości do wszystkich procesów w określonej maksymalnej liczbie rund (kroków). oznacza czas życia wiadomości wyróżniony maksymalną liczbą kolejnych jej przesłao. Zbiór używany lokalnie w procedurze , oznaczad będzie zbiór procesów, które zostały wybrane jako adresaci rozsyłanych wiadomości. Zbiór jest używany lokalnie w przedstawionej dalej funkcji type PACKET extends FRAME is record of : PROCESS_ID : INTEGER : MESSAGE end record : MESSAGE : PACKET : INTEGER : INTEGER : set of PROCESS_ID : set of MESSAGE : set of PROCESS_ID 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. /* W procedurze najpierw dokonywany jest wybór adresatów rozsyłanych wiadomości. Są oni wybierani losowo ze zbioru wszystkich procesów. Używana jest tu funkcja , która dokonuje losowego wyboru jednego elementu z podanego zbioru. Następnie pakiet jest wysyłany do wszystkich wybranych procesów z użyciem mechanizmu kanałów rzetelnych */ procedure while do if end if end while for all then do end for end procedure /* Kiedy proces aplikacyjny chce rozgłosid wiadomośd , monitor wypełnia pole wysyłanego pakietu, wstawiając tam identyfikator procesu , ustawia wartośd pola na maksymalny czas życia i wysyła pakiet za pomocą procedury */ when do end when /* Każdy monitor, odbierając wiadomośd sprawdza, czy nie została ona przedtem dostarczona. Jeżeli nie, to wiadomośd jest dostarczana. Równocześnie, jeżeli pole 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. nadesłanego pakietu jest większe od zera, to monitor dekrementuje to pole i rozsyła ten pakiet dalej za pomocą procedury */ when do if end if if then then end if end when Algorytm pasywny Wadą rozgłaszania opartego o mechanizm plotkowania jest duża liczba potencjalnie nadmiarowych wiadomości. Sposobem, pozwalającym na ominięcie tego problemu i zmniejszenie zużycia zasobów systemu jest wykorzystanie pewnego istniejącego, zawodnego mechanizmu rozgłaszania. Na początku wiadomośd jest rozsyłana za pomocą dowolnej (byd może zawodnej) operacji rozgłaszania, a następnie dodatkowo używany jest mechanizm plotkowania za pomocą zawodnych operacji komunikacyjnych łączy rzetelnych w celu retransmisji zagubionych wiadomości. Retransmisje takie mogłyby byd oczywiście wykonywane jedynie przez oryginalnego nadawcę. Aby jednak zwiększyd prawdopodobieostwo dostarczenia zagubionych wiadomości, przyjmuje się, że retransmisji mogą byd wykonywane także przez inne procesy. Rezultatem tego jest wymóg czasowego przechowywania przez każdy proces pewnej liczby odebranych wiadomości (proces, który otrzymuje wiadomośd, z pewnym prawdopodobieostwem, zapamiętuje ją w celu ewentualnej późniejszej retransmisji). Fakt zagubienia wiadomości (dopuszczalny z powodu przyjętej zawodności mechanizmu rozgłaszania) można wykryd za pomocą utrzymywanych przez każdy proces liczników wysłanych wiadomości. Liczniki te są dołączane do każdej wiadomości jako jej numer sekwencyjny. Proces podejrzewa zagubienie wiadomości jeżeli numer sekwencyjny aktualnie dostarczonej wiadomości od procesu różni się o więcej niż jeden od numeru sekwencyjnego wiadomości uprzednio otrzymanej od . W takim wypadku proces może rozgłosid prośbę o nadesłanie brakujących wiadomości za pomocą mechanizmu plotkowania. Proces, odbierający prośbę o retransmisję wiadomości spełnia ją, jeżeli wiadomośd ta znajduje się w zbiorze wiadomości przechowywanych przez ten proces. W przeciwnym wypadku używa mechanizmu plotkowania, by przesład tę prośbę do innych procesów. Pasywny algorytm probabilistycznego rozgłaszania niezawodnego (ang. lazy probabilistic broadcast) realizuje przedstawioną wyżej ideę. Wymagania pasywnego algorytmu probabilistycznego rozgłaszania niezawodnego wynikają z podziału rozgłaszania na dwie fazy. Na początku wiadomości jest rozsyłana za pomocą dowolnej (byd może zawodnej) operacji rozgłaszania, a następnie dodatkowo używany jest mechanizm plotkowania za pomocą zawodnych operacji komunikacyjnych kanałów rzetelnych w celu retransmisji zagubionych wiadomości. Ponieważ na operacje rozgłaszania nie są narzucone żadne wymagania, będziemy je oznaczad przez , a odpowiadające jej zdarzenie wysłania . Analogicznie, zdarzenie odebrania wiadomości oznaczad będziemy przez . Mechanizmowi temu może odpowiadad pewien dowolny mechanizm rozgłaszania oparty o rzetelne kanały komunikacyjne. Algorytm używa trzech typów wiadomości. Wiadomości aplikacyjne są przesyłane za pomocą wiadomości typu PACKET, które poza polem , określającym identyfikator pierwotnego (oryginalnego) nadawcy komunikatów, zawierają też numer sekwencyjny wiadomości w polu . Typ REQUEST zawiera wszystkie pola takie same jak PACKET (dziedziczy po strukturze PACKET) oraz dodatkowo posiada pole , określające maksymalny czas życia wiadomości. Wreszcie typ ANSWER służy do dostarczania brakujących wiadomości. Znaczenie niektórych wiadomości jest następujące: przechowuje ostatni numer sekwencyjny wysyłanej wiadomości. (ang. store threshold) jest parametrem, określającym prawdopodobieostwo zapamiętania otrzymanej wiadomości (w celu jej ewentualnej retransmisji). Zbiór zawiera pakiety przechowywane w celu ewentualnej retransmisji. Pakiety te powinny byd po pewnym czasie usunięte z tego zbioru, co zostało pominięte dla prostoty prezentacji. Zbiór zawiera pakiety otrzymane, których wiadomości aplikacyjne jeszcze nie zostały dostarczone do procesów aplikacyjnych. Tablica zawiera numery sekwencyjne ostatnio dostarczonych wiadomości tak, że -ty element określa numer sekwencyjny ostatnio dostarczonej wiadomości od . Zmienna , typu PACKET, jest używana lokalnie w funkcji . type PACKET extends FRAME is record of : PROCESS_ID : INTEGER : MESSAGE end record type REQUEST extends PACKET is record of : INTEGER end record type ANSWER extends PACKET : MESSAGE : PACKET : REQUEST : ANSWER : INTEGER : INTEGER : INTEGER : INTEGER : array of INTEGER : set of PROCESS_ID : set of PACKET : set of PACKET : PACKET : set of PROCESS_ID : INTEGER : INTEGER 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. /* W procedurze najpierw dokonywany jest wybór adresatów rozsyłanych wiadomości. Są oni wybierani losowo ze zbioru wszystkich procesów. Używana jest tu funkcja , która dokonuje losowego wyboru jednego elementu z podanego zbioru. Następnie pakiet jest wysyłany do wszystkich wybranych procesów z użyciem mechanizmu kanałów rzetelnych. Procedura ta jest identyczna jak w poprzednim algorytmie */ procedure while do if end if end while for all then do end for end procedure /* Procedura przegląda zbiór sprawdzając, czy może dostarczyd do kolejną wiadomośd wysłaną pierwotnie przez proces . Warunkiem dostarczenia jest, by pakiet ze zbioru , pochodzący od posiadał numer sekwencyjny o jeden większy od numeru sekwencyjnego ostatnio dostarczonej wiadomości od . Jeżeli dostarczenie jest możliwe, to odpowiednio uaktualniona jest tablica oraz zmienna . Warto zaznaczyd, że dostarczenie jednej wiadomości może pozwolid do dostarczenia kolejnej */ procedure while do end while end procedure /* Kiedy proces aplikacyjny chce rozgłosid wiadomośd , monitor zwiększa licznik wysłanych wiadomości i rozsyła następnie pakiet za pomocą zawodnej operacji rozgłaszania */ 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. when do end when /* Monitor , odbierając pakiet, po pierwsze z pewnym prawdopodobieostwem zapamiętuje go w zmiennej , umożliwiając tym samym późniejszą jego retransmisję. Następnie monitor sprawdza, czy numer sekwencyjny pakietu jest równy numerowi następnego oczekiwanego pakietu od . Jeżeli tak, to dostarcza wiadomośd do procesu aplikacyjnego . W przeciwnym wypadku, wstawia pakiet do zbioru i, używając procedury , wysyła prośbę do wszystkich procesów o przysłanie mu brakujących pakietów. Istnieje pewne prawdopodobieostwo, że żaden z procesów, do których dotrą prośby, nie posiada tego pakietu, gdyż został zagubiony w czasie rozgłaszania i nie dotarł do żadnego monitora, lub prośby o retransmisję nie dotarły do właściwych monitorów. W takim wypadku, po jakimś czasie monitor zwiększa numer sekwencyjny następnej oczekiwanej wiadomości od , akceptując utratę jednej wiadomości (dla uproszczenia prezentacji, ta funkcjonalnośd została tu pominięta). Niezdefiniowana funkcja użyta w zapisie algorytmu oznacza funkcję, zwracającą losową liczbę z określonego przedziału liczb naturalnych */ when do if then end if if then else for all end for end if end when /* Monitor , otrzymując prośbę o retransmisję pakietu, spełnia ją, jeżeli posiada poszukiwany pakiet od określonego nadawcy i o wymaganym numerze sekwencyjnym. W przeciwnym wypadku, jeżeli pole otrzymanej prośby jest większe od zera, monitor rozsyła tą prośbę dalej za pomocą procedury . Dla uproszczenia zapisu, zastosowano tu funkcję , która zwraca indeks procesu o identyfikatorze */ 45. when 46. do if then 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. else if then end if end if end when /* Po otrzymaniu odpowiedzi na wysłaną prośbę, monitor sprawdza, czy może dostarczyd odebraną wiadomośd, a jeśli tak, czy może dostarczyd któreś z wiadomości umieszczonych w zbiorze . W przeciwnym wypadku dołącza pakiet do zbioru */ when do if then else end if end when Zgodne rozgłaszanie niezawodne z przyczynowym uporządkowaniem wiadomości Specyfikacja Mówimy, że wiadomośd poprzedza przyczynowo , jeżeli zdarzenie wysłania zależy przyczynowo od zdarzenia wysłania . Innymi słowy, oznacza to, że zachodzi któryś z poniższych przypadków: obie wiadomości zostały rozgłoszone przez ten sam proces i wiadomośd została rozgłoszona przed wiadomośd została odebrana przez pewien proces , a została rozgłoszona przez po odebraniu istnieje wiadomośd taka, że dla i oraz i zachodzi jeden z dwóch powyższych warunków Relacja przyczynowego porządku między wiadomościami jest zachowana przez kolejny omawiany w ramach wykładu mechanizm niezawodnego rozgłaszania, mianowicie zgodnego rozgłaszania niezawodnego z przyczynowym uporządkowaniem wiadomości (ang. causally ordered reliable broadcast). Mechanizm ten posiada wszystkie własności zgodnego rozgłaszania niezawodnego i dodatkowo własnośd przyczynowego uporządkowania (ang. causal delivery) wiadomości: Ważnośd Brak powielania Brak samogeneracji Zgodnośd Przyczynowe uporządkowanie Jeżeli procesowi dostarczone są wiadomości oraz , przy czym zdarzenie wysłania wiadomości przyczynowo zależy od zdarzenia wysłania wiadomości , to jest odebrana przed . Własnośd ta oznacza, że przed dostarczeniem dowolnej wiadomości , proces musi dostarczyd wszystkie wiadomości, od których przyczynowo zależy. Operacje komunikacyjne Operację zgodnego rozgłaszania niezawodnego wiadomości przez do zbioru procesów , z zachowaniem przyczynowego uporządkowania wiadomości oznaczad będziemy przez . Zdarzenie, odpowiadające tej operacji, zapisywad będziemy jako . Analogicznie, przez oznaczad będziemy operację, uaktywniającą zdarzenie przez proces do procesu aplikacyjnego i przekazującą w efekcie wiadomośd wysłaną . Algorytm Algorytm, realizujący mechanizm zgodnego rozgłaszania niezawodnego z przyczynowym uporządkowaniem wiadomości (ang. no-waiting causal broadcast), cechuje się: Dostępnością mechanizmu zgodnego rozgłaszania niezawodnego Brakiem wymogu dostępności detektora awarii Na podstawie powyższej charakterystyki łatwo zauważyd, że algorytm jest odpowiedni dla modelu przetwarzania z ukrytymi awariami (patrz: Wykład 11: Modele przetwarzania). Wiadomości aplikacyjne przesyłane są w komunikatach typu PACKET. Pakiety te mają dodatkowo pole , zawierające zbiór informacji o wiadomościach poprzedzających przyczynowo wiadomośd aplikacyjną przesyłaną w tym pakiecie. Zbiór dla każdego procesu zawiera zbiór informacji o wiadomościach, które poprzedzają przyczynowo wysłaną przez proces wiadomośd aplikacyjną, natomiast zbiór zawiera wiadomości dostarczone do procesu . type PACKET extends FRAME is record of : set of pair of : MESSAGE end record : MESSAGE : PACKET : set of pair of : set of MESSAGE 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. /* Wysyłając pakiet z wiadomością aplikacyjną , monitor procesu inicjuje odpowiednio pola pakietu, dołączając do niego wiadomości, od których wiadomośd jest przyczynowo zależna. Następnie wysyłana wiadomośd aplikacyjna jest dołączana do zbioru wraz z identyfikatorem nadawcy- . Pakiet jest rozgłaszany z użyciem mechanizmu zgodnego rozgłaszania niezawodnego */ when do end when /* Wiadomośd aplikacyjna przenoszona przez pakiet jest dostarczana tylko i wyłącznie wtedy, jeżeli zostaną dostarczone wszystkie wiadomości, od których jest ona przyczynowo zależna. W tym celu monitor przegląda i ewentualnie dostarcza wiadomości zawarte w polu otrzymanego pakietu. Dla uproszczenia zapisu przyjmuje się, że zbiór jest uporządkowany i wchodzące w jego skład wiadomości są dostarczane w poprawnej kolejności. Każda dostarczona wiadomośd dołączana jest przy tym do zbioru */ when do if then for all if do then end if end for end if end when Złożoność Złożonośd komunikacyjna pakietowa i czasowa tego algorytmu jest identyczna jak stosowanego mechanizmu zgodnego rozgłaszania niezawodnego. Poważną wadą algorytmu jest jednak rosnący rozmiar zbioru . Potrzeba dołączania zbioru do wysyłanych wiadomości powoduje wzrost złożoności komunikacyjnej bitowej. W efekcie algorytm ten nie ma większego znaczenia w rzeczywistych zastosowaniach. W praktyce, zgodne rozgłaszanie niezawodne z przyczynowym uporządkowaniem wiadomości można jednak łatwo uzyskad, modyfikując stosownie przedstawione wcześniej mechanizmy komunikacji punkt- punkt, zachowujące uporządkowanie przyczynowe wiadomości. Zgodne rozgłaszanie wiadomości niezawodne z globalnym uporządkowaniem Specyfikacja Mechanizm zgodnego rozgłaszania niezawodnego z globalnym (całkowitym) uporządkowaniem wiadomości (ang. total order broadcast), nazywany też czasem rozgłaszaniem atomowym (ang. atomic broadcast), ma następujące własności: Ważnośd Brak powielania Brak samogeneracji Zgodnośd Globalne uporządkowanie wiadomości (ang. total order) Wszystkie procesy odbierają wiadomości w tym samym porządku Operacje komunikacyjne Operację zgodnego rozgłaszania niezawodnego wiadomości przez do zbioru procesów , z zachowaniem globalnego uporządkowania wiadomości oznaczad będziemy przez . Zdarzenie, odpowiadające tej operacji, zapisywad będziemy jako . Analogicznie, przez oznaczad będziemy operację, uaktywniającą zdarzenie przez proces do procesu aplikacyjnego i przekazującą w efekcie wiadomośd wysłaną . Algorytm Przedstawiony algorytm zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości zakłada: Dostępnośd niezawodnych kanałów FIFO (patrz: Wykład 11: Kanały niezawodne) Dostępnośd mechanizmu zgodnego rozgłaszania niezawodnego z zachowaniem porządku FIFO wiadomości przesyłanych między każdą parą procesów- Poprawnośd wszystkich procesów Algorytm używa dwóch typów wiadomości. Wiadomości aplikacyjne są przesyłane w pakietach typu PACKET, które zawierają dodatkowo numer sekwencyjny w polu oraz identyfikator pierwotnego nadawcy wiadomości w polu . Wiadomości typu SNUPDATE (ang. sequence number update) służą do aktualizacji numerów sekwencyjnych (znaczników czasowych) i zawierają pole numeru sekwencyjnego . Zmienne oraz są używane lokalnie podczas rozstrzygania o globalnej kolejności odebranych wiadomości. Wiadomości oraz są typu SNUPDATE. Zbiór zawiera otrzymane pakiety, w których zawarte są wiadomości aplikacyjne jeszcze nie dostarczone do procesu aplikacyjnego. Tablica zawiera numery sekwencyjne pakietów otrzymanych i jest swego rodzaju zegarem wektorowym. type PACKET extends FRAME is record of : PROCESS_ID : INTEGER : MESSAGE end record type SNUPDATE extends FRAME is record of : INTEGER end record : MESSAGE : PACKET : PACKET : SNUPDATE : SNUPDATE : array of INTEGER : set of PACKET 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. /* Wysyłając wiadomośd monitor procesu zwiększa licznik , a następnie inicjuje odpowiednio pola pakietu. Pakiet jest także dołączony do zbioru pakietów */ when do end when /* Odbierając wiadomośd od monitora , monitor ustawia wartośd -tego elementu tablicy na wartośd numeru sekwencyjnego przysłanego pakietu. Następnie dodaje go do zbioru . Jeżeli -ty wpis w tablicy jest mniejszy niż numer sekwencyjny odebranego pakietu, monitor zmienia wartośd elementu na wartośd numeru sekwencyjnego z pola odebranego pakietu, i następnie informuje o tym fakcie pozostałe monitory, rozgłaszając wiadomośd */ when do if end if end when /* Odbierając wiadomośd wartośd -tego elementu tablicy pakietu */ then typu SNUPDATE od monitora , monitor ustawia na wartośd numeru sekwencyjnego przysłanego 18. 19. 20. 21. when do end when /* Wiadomośd jest dostarczana, jeżeli posiada najmniejszy licznik (znacznik czasowy) spośród wszystkich otrzymanych wiadomości (w przypadku konfliktów rozstrzyga identyfikator procesu) oraz jeżeli ten licznik jest nie większy od wszystkich elementów tablicy */ when do 22. 23. 24. 25. end when Przykład #1: Początkowo wszystkie pozycje wszystkich tablic są wyzerowane. Monitor procesu wysyła pakiet z wiadomością i . W wyniku tego wartośd jego tablicy , a pakiet z wiadomością dołączana jest do zbioru . Analogicznie, monitor procesu wysyła pakiet z wiadomością i , przypisując , a pakiet z wiadomością dołączana jest do zbioru . Monitor po otrzymaniu pakietu z wiadomością modyfikuje tablicę , wykonując przypisanie . Ponieważ nadesłany pakiet posiada licznik sekwencyjny większy niż licznik lokalny zawarty w , więc dodatkowo wykonuje operację przypisania oraz rozsyła wiadomości SNUPDATE do pozostałych monitorów. Odpowiada to wierszom 12-16 z przedstawionego algorytmu. Pozostałe monitory, otrzymując tę wiadomośd, aktualizują odpowiednie pozycje lokalnej tablicy . Załóżmy, że pakiet od monitora dociera do oraz . Powoduje to odpowiednią modyfikację tablic . W tej chwili dla obu monitorów zachodzi warunek z 21. wiersza algorytmu- numer sekwencyjny pakietu z wiadomością jest równy wszystkim pozycjom tablicy ,a identyfikator jej nadawcy jest mniejszy od identyfikatorów nadawców wszystkich pozostałych wiadomości. Po dostarczeniu i usunięciu odpowiedniego pakietu ze zbioru , oba monitory oraz mogą następnie dostarczyd wiadomośd . Wreszcie, kiedy pakiet z wiadomością dotrze ostatecznie do , zostanie ona uznana za możliwą do dostarczenia (znowu zajdzie warunek z wiersza 21-szego algorytmu), i będzie można następnie dostarczyd również . Przykład #2: Rozważmy teraz przykład, w którym jeden proces ulegnie awarii. Załóżmy, że początkowo wszystko działa podobnie jak w poprzednim przykładzie, lecz tym razem proces , a tym samym monitor uległ awarii po otrzymaniu pakietu z wiadomością . Po pewnym czasie pakiet z wiadomością od procesu dociera do monitora . Powoduje to oczywiście odpowiednią modyfikacje tablic y . Analogicznie, gdy pakiet z wiadomością dotrze do , ten zmodyfikuje odpowiednio tablicę . Żaden proces nie jest w stanie odebrad wiadomości, gdyż oba czekają na zwiększenie drugiej pozycji tablicy (odpowiadającej procesowi ). Zwiększenie to może jednak nastąpid tylko w wyniku otrzymania pakietu od - co nigdy nie nastąpi z powodu awarii i . Widzimy tutaj, że w przypadku możliwości awarii chod jednego procesu przedstawione rozwiązanie jest niepoprawne. Złożoność Załóżmy, że topologia przetwarzania rozproszonego ma postad grafu pełnego. Jak łatwo zauważyd, w przedstawionym algorytmie rozgłoszenie wiadomości wymaga dwóch kroków (złożonośd czasowa wynosi ): w pierwszym nadawca rozgłasza wiadomośd, w drugim otrzymuje komunikaty typu SNUPDATE. W pierwszym kroku wysłanych jest komunikatów, zaś w drugim co najwyżej komunikatów. Stąd, złożonośd komunikacyjna wynosi . Wykład #13: Problem konsensusu Plan wykładu: a) b) c) d) e) Problem konsensusu- wprowadzenie Konsensus podstawowy Konsensus jednolity Konsensus probabilistyczny Konsensus a inne problemy Konsensus- wprowadzenie Nieformalnie, konsensusem nazywa się problem uzgadniania przez zbiór procesów jednej wartości spośród zbioru wartości zaproponowanych wstępnie przez te procesy. Algorytm rozwiązywania tego problemu będziemy nazywad mechanizmem konsensusu. W systemach rozproszonych mechanizm konsensusu jest oczywiście pewnym specyficznym przetwarzaniem rozproszonym. Należy zauważyd, że konsensus jest szczególnym przypadkiem problemów uzgadniania, w których zbiór procesów podejmuje decyzje powiązane pewnymi zależnościami. Innymi przykładami takich problemów są: Problem elekcji Problem zatwierdzania Aproksymowany konsensus W przypadku konsensusu, relacja między decyzjami różnych procesów jest bardzo prosta: wymaga się, by wszystkie procesy decydowały się na tę samą wartośd. W przypadku problemów elekcji jeden proces musi zdecydowad, że został wybrany, a wszystkie pozostałe, że zostały pokonane (niewybrane). W problemach zatwierdzania (ang. commit-abort) procesy decydują, czy należy zatwierdzid, czy też odrzucid transakcję- przy czym transakcja nie może byd zatwierdzona przy sprzeciwie chod jednego procesu (jest to szczególny przypadek konsensusu binarnego). W konsensusie aproksymowanym, inaczej problemie przybliżonej zgody (ang. approximate agreement), wszystkie procesy podejmują decyzję, których wartości nie mogą się różnid więcej niż o pewną stałą i muszą należed do zbioru wartości wejściowych. Problem konsensusu jest trudny do rozwiązania w systemie rozproszonym, ale jednocześnie jest on problemem bardzo ważnym. Mając do dyspozycji mechanizm konsensusu można znaleźd rozwiązanie wielu innych zagadnieo, między innymi takich jak: Zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości Jak przedstawiono na poprzednim wykładzie, zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości (patrz: Wykład 12) polega na zapewnieniu w systemie rozproszonym, dostarczenia rozgłaszanych wiadomości w takim samym porządku do wszystkich odbiorców, mimo potencjalnych awarii i nieprzewidywalnych opóźnieo komunikacyjnych. Komunikacja zsynchronizowana z obrazami grup Problem komunikacji zsynchronizowanej z obrazami grup (ang. view synchronous multicast) polega na rozgłaszaniu tej samej sekwencji wiadomości do wszystkich procesów, należących do określonego obrazu (widoku) grupy. Nieblokujące zatwierdzanie atomowe Problem nieblokującego zatwierdzania atomowego (ang. non- blocking atomic commitment) polega na zatwierdzeniu lub odrzuceniu transakcji przez grupę procesów, przy czym transakcja może byd zatwierdzona tylko w przypadku, w którym wszystkie procesy głosowały za jej zatwierdzeniem. Uzgadnianie składu grupy Problem składu grupy (ang. group membership) polega na uzgodnieniu przez zbiór procesów spójnego obrazu składu grupy, zmieniającej się w czasie. Obraz składu grupy, identyczny dla wszystkich procesów będących jej członkami, nazywa się widokiem grupy. Możliwośd rozwiązania wymienionych problemów z użyciem mechanizmu konsensusu nie oznacza, że problemy te są łatwiejsze. Konsensus można bowiem rozwiązad mając na przykład do dyspozycji mechanizm niezawodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości. Konsensus a zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości Konsensus można łatwo sprowadzid do problemu zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości (patrz: Wykład 12). Aby rozwiązad konsensus z wykorzystaniem istniejącej abstrakcji rozgłaszania, wystarczy wykonad następujące kroki: Wszystkie procesy rozsyłają proponowaną wartośd za pomocą zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości Procesy decydują się na pierwszą dostarczoną wiadomośd. Z właściwości użytego mechanizmu rozgłaszania wynika, że wiadomości są dostarczone do wszystkich procesów w tym samym porządku, zatem ta sama wiadomośd zostanie dostarczona jako pierwsza, tym samym wszystkie procesy zdecydują się na tę samą wartośd. Problem zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości można z kolei sprowadzid do konsensusu, wymagając, aby dostarczenie -tej wiadomości było decydowane w wyniku kolejnego, -tego konsensusu. W koocowej części wykładu (patrz: Algorytm) zostanie przedstawiony algorytm, implementujący zgodne rozgłaszanie niezawodne z globalnym uporządkowaniem wiadomości za pomocą zgodnego rozgłaszania niezawodnego i wybranego mechanizmu konsensusu. Konsensus w systemach w pełni asynchronicznych W 1985r. zostało udowodnione (Michael Fisher, Nancy Lynch, Michael Paterson) fundamentalne twierdzenie o nierozwiązywalności konsensusu w pełni asynchronicznym środowisku rozproszonym, o ile jest możliwe załamanie (awaria) chociaż jednego procesu. Innymi słowy, jeżeli nie ma ograniczeo na maksymalny czas przesyłania wiadomości i prędkośd procesów, to problem konsensusu nie można w ogólności rozwiązad. Twierdzenie 22 (Fisher- Lynch- Paterson) Nie istnieje algorytm (mechanizm), rozwiązujący problem konsensusu w środowisku w pełni asynchronicznym, jeżeli istnieje możliwośd załamania (awarii) chodby jednego procesu. Dowód powyższego twierdzenia opiera się na wykazaniu, że nie jest możliwe odróżnienie procesu niepoprawnego od takiego, który po prostu jest bardzo wolny lub jest połączony bardzo wolnymi łączami. Konsensus w systemach częściowo synchronicznych Twierdzenie 23 Nie istnieje algorytm, rozwiązujący problem konsensusu w środowisku (modelu) z synchronicznymi procesami i asynchronicznymi kanałami, jeżeli istnieje możliwośd załamania (awarii) chodby jednego procesu. Powyższe twierdzenie wynika z braku ograniczeo na czas przesyłania wiadomości, co powoduje, że nie można odróżnid procesu niepoprawnego od takiego, który połączony jest wyjątkowo wolnymi łączami. Twierdzenie 24 Nie istnieje algorytm, rozwiązujący problem konsensusu w środowisku (modelu) z asynchronicznymi procesami i kanałami o znanych maksymalnych opóźnieniach, jeżeli istnieje możliwośd załamania (awarii) chodby jednego procesu. Powyższe twierdzenie wynika oczywiście z braku ograniczeo na różnice prędkości między procesami, co powoduje, że nie można odróżnid procesu niepoprawnego od takiego, który jest bardzo wolny. Detektory awarii a konsensus Konsensus posiada rozwiązanie dla systemów, w których dostępne są doskonałe detektory awarii. Wystarczającym warunkiem jest dostępnośd detektora klasy S (patrz: Wykład 11: Klasyfikacja detektorów), a w niektórych rodzajach systemów rozproszonych nawet detektora ostatecznie słabego- W. Należy zwrócid uwagę, że jeżeli można rozwiązad konsensus z użyciem pewnego detektora awarii, to oznacza to, że detektora tego nie da się zaimplementowad w pełni asynchronicznym systemie rozproszonym. Problem konsensusu można rozwiązad w systemach asynchronicznych: z dostępem do doskonałego detektora awarii P z użyciem detektora awarii klasy S pod warunkiem jednak, że większośd procesów jest poprawna, tzn. dla , gdzie oznacza liczbę wszystkich procesów, a jest maksymalną liczbą procesów niepoprawnych. Konsensus podstawowy Specyfikacja Mechanizm konsensusu podstawowego charakteryzują następujące własności: Ważnośd (ang. validity) Jeżeli proces decyduje się na wartośd , to wartośd ta została wcześniej zaproponowana przez pewien proces. Innymi słowy, procesy nie mogą decydowad się na dowolną wartośd, lecz muszą zgodzid się na którąś z przedstawionych propozycji. Zakooczenie (ang. termination) Wszystkie poprawne procesy ostatecznie decydują się na jakąś wartośd. W systemie asynchronicznym, czas podejmowania decyzji jest przy tym skooczony, ale nieznany. Integralnośd (ang. integrity) Każdy proces decyduje się tylko raz. Procesy nie mogą zatem zmieniad raz podjętych decyzji. Zgodnośd (ang. agreement) Nie istnieją dwa poprawne procesy, które zdecydowały się na inne wartości. Tym samym, poprawne procesy uzgadniają wspólną wartośd. Dodatkowo, wymagane jest, by mechanizm konsensusu miał własnośd nietrywialności rozwiązania (ang. non-triviality), którą zazwyczaj pomija się, definiując konsensus z uwagi na jej oczywistośd. Własnośd ta mówi, że wartośd decyzji nie może byd ustalona z góry. Operacja propose Proponowana do uzgodnienia przez proces wartośd określana jest w wyniku wykonania operacji . Operacja ta inicjuje mechanizm konsensusu. Zdarzenie, zachodzące w procesie . Operacja decide Określenie przez proces (monitor w wyniku wykonania operacji konsensusu. Zdarzenie wartości w wyniku wykonania tej operacji zapisywane będzie jako ) decyzji, co do ostatecznie uzgodnionej wartości następuje . Wykonanie tej operacji kooczy mechanizm , zachodzące w procesie w wyniku wykonania operacji , oznacza osiągnięcie przez proces aplikacyjny konsensusu, a więc uzgodnienia z wszystkimi pozostałymi procesami. Schematycznie, miejsce mechanizmu konsensusu ilustruje poniższy rysunek. Mechanizm jest inicjowany zajściem zdarzeo w procesach aplikacyjnych . Jego efektem jest natomiast podjęcie przez każdy monitor decyzji, dotyczącej ostatecznej wybranej wartości . Podjęcie tej decyzji odpowiada wykonaniu operacji i zajściu zdarzenia , oznaczającego osiągnięcie konsensusu przez , a więc uzgodnienia wartości z wszystkimi procesami. Należy pamiętad oczywiście, że zgodnie z własnością ważności, . Algorytm rozgłoszeniowy Rozgłoszeniowy algorytm konsensusu podstawowego (ang. flooding consensus) zakłada dostępnośd: Mechanizmu podstawowego rozgłaszania niezawodnego (patrz: Wykład Podstawowe rozgłaszanie niezawodne) Doskonałego detektora awarii (patrz: Wykład 11: Klasyfikacja detektorów) 12: Z powyższych założeo wynika, że algorytm przeznaczony jest dla modelu jawnych awarii (patrz: Wykład 11: Modele przetwarzania). Koncepcja algorytmu przedstawia się następująco: Algorytm działa w rundach, zaś każda wiadomośd jest oznaczona numerem rundy. Decyzja podejmowana jest, gdy proces otrzyma wiadomości od wszystkich poprawnych procesów i nie wykrył żadnej nowej awarii, a więc ma pewnośd, że otrzymał wszystkie propozycje, które będą wzięte pod uwagę przez wszystkie pozostałe procesy. Jeżeli wykryta została awaria, to proces nie ma pewności, czy posiadany przez niego zbiór wartości-propozycji- jest taki sam, jak widziany przez wszystkie pozostałe procesy. Różnica może mied na przykład miejsce, jeżeli jakiś błędny proces zdążył przesład wiadomośd tylko do części pozostałych procesów. W takim wypadku rozpoczynana jest kolejna runda. Do podjęcia decyzji używana jest dowolna deterministyczna funkcja, znana wszystkim procesom, np. wybierana może byd najmniejsza wartośd spośród zaproponowanych. W algorytmie przesyłane są wiadomości dwóch typów. Typ MYPROP zawiera pole , które jest zbiorem wartości zaproponowanych w danej rundzie przez poszczególne procesy, a także pole , określające numer rundy. Typ DECIDED natomiast, zawiera pole , określające decyzję podjętą przez nadawcę wiadomości oraz pole , mówiące, w której rundzie podjęta została decyzja. Wiadomości typu DECIDED wysyłane są w momencie podjęcia decyzji przez proces (monitor). Znaczenie niektórych zmiennych jest następujące: zawiera wartośd, na którą chce się zdecydowad proces , początkowo równa pewnej wyróżnionej wartości pustej. to zbiór, zawierający zestaw wszystkich widzianych przez proces (monitor ) propozycji. to numer bieżącej rundy. to zbiór, początkowo obejmujący identyfikatory wszystkich procesów, oznaczający procesy, które według wiedzy dostępnej dla są poprawne. zawiera identyfikatory procesów poprawnych w obecnej rundzie. Początkowo jest on pusty. type MYPROP extends FRAME is record of : set of INTEGER : INTEGER end record type DECIDED extends FRAME is record of : INTEGER : INTEGER end record : DECIDED : MYPROP : INTEGER : array of set of INTEGER : INTEGER : set of PROCESS_ID : array of set of PROCESS_ID 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. /* Zainicjowanie rozgłoszeniowego algorytmu konsensusu podstawowego związane jest z zajściem zdarzenia w procesie aplikacyjnym . W efekcie tego zdarzenia, monitor rozpoczyna wymianę wiadomości z innymi monitorami w celu uzgodnienia wspólnej decyzji. Uzgodnienie to prowadzi do zajścia zdarzenia */ when do for all do end for end when /* W wyniku wykrycia awarii z użyciem detektora awarii P, proces poprawnych procesów widzianych przez dowolny proces when do jest usuwany ze zbioru */ end when /* W przypadku otrzymania propozycji od monitora , wartośd pola z pola otrzymanej wiadomości MYPROP dodawana jest do zbioru propozycji . Sam proces dodawany jest do zbioru procesów poprawnych w obecnej rundzie */ when do end when 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. /* W przypadku, gdy monitor otrzyma wiadomości od monitorów wszystkich poprawnych procesów i dotąd nie podjął decyzji, sprawdza, czy w obecnej rundzie zbiór poprawnych procesów nie uległ zmianie, tzn. czy zbiór identyfikatorów procesów z poprzedniej rundy jest taki sam, co w bieżącej rundzie. Jeżeli ten warunek jest spełniony, to monitor podejmuje decyzję, wykonując operację . Prowadzi to do zajścia zdarzenia w procesie . Po wykonaniu operacji , monitor rozgłasza swoją decyzję, korzystając z mechanizmu podstawowego rozgłaszania niezawodnego */ when do if then // zwraca najmniejszą liczbę ze zbioru else end if end when /* W przypadku, gdy monitor otrzyma powiadomienie o decyzji pewnego monitora, natychmiast podejmuje identyczną decyzję i rozgłasza ten fakt wszystkim pozostałym monitorom */ when do if then end if end when Przykład #1: Przykład przedstawia cztery procesy, uzgadniające wspólną decyzję za pomocą rozgłoszeniowego algorytmu konsensusu podstawowego. Wszystkie procesy proponują pewną wartośd, a odpowiadające im monitory rozsyłają ją za pomocą podstawowego rozgłaszania niezawodnego. Załóżmy, że proces ulega awarii w trakcie rozgłaszania, w wyniku czego jego propozycję otrzymuje jedynie monitor . Ponieważ monitor zebrał wiadomości od wszystkich monitorów, więc może podjąd decyzję, wybierając minimalną wartośd, na przykład , a następnie rozgłosid ją w systemie. Monitory, otrzymując wiadomośd o decyzji, podporządkowują się jej, podejmując identyczną decyzję. Należy zauważyd, że monitory i nie mogą same podjąd decyzji, gdyż nie otrzymały wiadomości od wszystkich monitorów procesów, który były uznawane za poprawne na początku tej rundy. Co więcej, po wykryciu awarii procesu znane sobie propozycje. monitory mogą rozpocząd nową rundę, rozgłaszając wszystkie Fakty wykrycia awarii procesu nie wpływa na decyzję monitora , gdyż otrzymał on już wcześniej wiadomośd od tego procesu, dodając go do zbioru . Proces usunięty jest więc wprawdzie ze zbioru , ale ponieważ zbiór zawiera się w zbiorze , zachodzi warunek konieczny tego algorytmu do podjęcia decyzji. Przykład #2: W kolejnym przykładzie dochodzi w pierwszej rundzie do dwóch awarii. Proces ulega awarii zaraz po przesłaniu swojej propozycji do monitora , natomiast ulega awarii po wysłaniu wiadomości do monitorów oraz . Żaden więc z dwóch pozostałych monitorów nie może podjąd decyzji, gdyż żaden z nich nie otrzymał wiadomości od wszystkich monitorów. Następuje zatem kolejna runda, w której ulega awarii. Tym samym, po wykryciu awarii procesu , monitor przechodzi do kolejnej rundy i podejmuje wreszcie decyzję. Złożoność Załóżmy, jak zwykle, że topologię przetwarzania reprezentuje graf pełny. Jeżeli żaden proces nie ulega awarii (przypadek optymistyczny), procesy podejmują decyzję w pierwszej rundzie. Wymaga ona wymiany wiadomości typu MYPROP przed osiągnięciem decyzji i drugie tyle wiadomości typu DECIDED. Złożonośd czasowa wynosi zatem , natomiast złożonośd komunikacyjna. W przypadku, w który kolejno ulegają awarii wszystkie procesy (przypadek pesymistyczny), algorytm wymaga kroków (rund), a więc złożonośd czasowa wynosi . W każdej dodatkowej rundzie wymienianych jest dodatkowe wiadomości, z czego wynika, że złożonośd komunikacyjna w przypadku pesymistycznym wynosi . Algorytm hierarchiczny Kolejnym rozwiązaniem problemu konsensusu jest algorytm hierarchiczny, w którym kolejno każdy proces (monitor) pełni rolę lidera rundy. Przyjęto przy tym, że hierarchia procesów jest zdefiniowana przez uporządkowanie procesów według indeksów. Lider rundy rozgłasza swoją decyzję, która jest przejmowana przez pozostałe procesy, po czym zaczyna się kolejna runda z nowym liderem. Jeżeli lider ulegnie awarii, jego rolę przejmuje kolejny proces itd. Algorytm hierarchiczny konsensusu podstawowego (ang. hierarchical consensus) zakłada dostępnośd: mechanizmu podstawowego rozgłaszania (patrz: Wykład 12: Podstawowe rozgłaszanie niezawodne) doskonałego detektora awarii (patrz: Wykład 11: Klasyfikacja detektorów) Z powyższych założeo wynika, że algorytm przeznaczony jest dla modelu jawnych awarii (patrz: Wykład 11: Modele przetwarzania). Jedynym używanym typem wiadomości jest typ DECIDED, niosący wartośd podjętej decyzji w polu oraz numer rundy, w której podjęto decyzję, w polu . Algorytm używa następujących zmiennych: Wiadomośd jest wiadomością, powiadamiającą inne procesy o podjętej decyzji przez lidera. zawiera propozycję procesu . (ang. proposer round number) zawiera identyfikator procesu, który zaproponował bieżącą wartośd zmiennej . Tablica zawiera wartośd , jeżeli proces (monitor) otrzymał powiadomienie o decyzji lidera. Tablica zainicjowana jest identyfikatorami wszystkich procesów, będących kolejnymi kandydatami na lidera. Identyfikator lidera -tej rundy jest zapisany w -tym elemencie tej tablicy. Tablica ta posiada identyczną zawartośd dla wszystkich procesów, biorących udział w algorytmie. Tablica zawiera wartośd , jeżeli monitor podjął już decyzję i rozgłosił ją wśród procesów. zawiera numer kolejnej rundy. reprezentuje zbiór procesów podejrzewanych o to, że są niepoprawne. Zmienna jest używana lokalnie w obsłudze zdarzenia odbioru wiadomości DECIDED. type DECIDED extends FRAME is record of : INTEGER : INTEGER end record : DECIDED : INTEGER : INTEGER : array of BOOLEAN : array of PROCESS_ID : array of BOOLEAN : INTEGER : set of PROCESS_ID : INTEGER 1. 2. 3. /* Monitor when end when zapisuje propozycję procesu do w zmiennej */ 4. 5. 6. 7. /* W przypadku wykrycia awarii jakiegoś procesu jest on dołączany do zbioru . Z własności silnej dokładności doskonałego detektora awarii P (patrz: Wykład 11: Własnośd dokładności) wynika, że żaden poprawny proces nigdy nie będzie podejrzewany */ when do end when /* Jeżeli monitor stwierdza, że zostaje liderem bieżącej -tej rundy (co dzieje się wtedy, gdy jego identyfikator jest równy identyfikatorowi zapisanemu w -tym elemencie tablicy ) oraz, jeżeli zmienna nie jest pusta, a także jeszcze nie podejmował decyzji, to decyduje się na wartośd zapisaną w zmiennej , zapamiętuje ten fakt i powiadamia o tym pozostałe monitory. Z własności ważności podstawowego rozgłaszania niezawodnego wynika, że każdy proces (monitor) poprawny otrzyma rozgłoszoną wiadomośd, o ile rozgłaszający proces (monitor) również jest poprawny. Jeżeli więc monitor podejmuje decyzję i jest poprawny, to wszystkie inne poprawne monitory otrzymają wiadomośd o podjętej przez niego decyzji */ when do 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. end when /* Jeżeli monitor podejrzewa lidera bieżącej rundy lub już otrzymał od niego wiadomośd, zwiększa numer rundy. Z własności dokładności doskonałego detektora awarii P wynika, że jest niemożliwe, by poprawny proces był kiedykolwiek podejrzewany. Z własności kompletności (patrz: Wykład 11: Własnośd kompletności) detektora awarii wynika natomiast, że niepoprawny proces będzie podejrzewany */ when do end when /* Jeżeli monitor otrzymuje powiadomienie o decyzji, to ignoruje ją, gdy pochodzi ona od monitora skojarzonego z procesem, znajdującym się niżej w hierarchii procesów niż lub gdy numer rundy nadesłanej wiadomości jest mniejszy niż największy numer rundy, w której monitor otrzymał decyzję. Może to bowiem oznaczad, że wiadomośd ta została wysłana przez niepoprawny monitor tuż przed jego awarią (warunek w wierszu 18). W przeciwnym wypadku, monitor zapisuje otrzymaną propozycję decyzji do zmiennej oraz zapamiętuje, że w rundzie, zapisanej w polu odebranego komunikatu, otrzymał decyzję od lidera */ when do if then end if 22. 23. 24. end when Przykład #1: W przedstawionym poniżej przykładzie liderem pierwszej rundy jest monitor . Rozgłasza on swoją decyzję, po czym proces , a tym samym monitor ulegają awarii. Liderem nowej rundy zostaje . Nowa runda zaczyna się w każdym monitorze, albo w momencie otrzymania wiadomości od , albo w momencie wykrycia jego awarii. Monitor rozgłasza wartośd, na którą chce się zdecydowad i podejmuje decyzję. Wartością tą jest albo , jeżeli otrzymał wiadomośd od przed wykryciem awarii (tak jak w przykładzie), albo . Monitory oraz po otrzymaniu tej wiadomości od rozpoczynają nową rundę, której liderem jest . Monitor rozgłasza tę wiadomośd, a więc wysyła ją również do . Ponieważ monitor podjął już decyzję, wiadomośd otrzymana od jest przez niego ignorowana- została ona pominięta na slajdzie. Po wysłaniu wiadomości monitor podejmuje decyzję- w rozważanym przykładzie . Monitor , otrzymując wiadomośd przechodzi do nowej rundy, stwierdza następnie, że jest jej liderem i podejmuje decyzję, rozsyłając ją do wszystkich monitorów. Pozostałe monitory ignorują tę wiadomośd, gdyż podjęły już decyzję. Przykład #2: Kolejny przykład zaczyna się podobnie jak poprzednio. Monitor rozgłasza proponowaną wartośd do wszystkich, jednakże, ponieważ ulega awarii, z własności podstawowego rozgłaszania niezawodnego, że wiadomośd może nie dotrzed do monitora . Po wykryciu awarii procesu , monitor decyduje o rozpoczęciu rundy, której jest liderem. Pozostałe monitory również przechodzą do nowej rundy, po otrzymaniu wiadomości od . Monitor decyduje się na , gdyż nigdy nie widział wartości , a następnie rozsyła tę wartośd do pozostałych monitorów. Odebranie tej wiadomości powoduje, że zarówno , jak i przyjmują wartośd jako nową propozycję decyzji (por. wiersz 18 algorytmu). Powoduje to przejście do rundy trzeciej, której liderem ma byd . Ponieważ jednak ulega on awarii, przechodzi do nowej rundy i podejmuje decyzję, wybierając wartośd . Złożoność W przypadku, gdy początkowy lider nie ulega awarii (przypadek optymistyczny), algorytm kooczy się po pierwszym kroku. Złożonośd czasowa wynosi zatem , a złożonośd komunikacyjna jest równa . W przypadku pesymistycznym, w którym wszystkie procesy po kolei ulegają awarii, algorytm kooczy się po co najwyżej krokach, przy czym w każdym kroku jest wysłanych wiadomości. Złożonośd czasowa wynosi więc , zaś złożonośd komunikacyjna- . Konsensus jednolity Specyfikacja Mechanizm konsensusu jednolitego posiada następujące własności: Ważnośd (ang. validity) Jeżeli proces decyduje się na wartośd , to wartośd ta została wcześniej zaproponowana przez pewien proces. Zakooczenie (ang. termination) Wszystkie poprawne procesy ostatecznie decydują się na jakąś wartośd. Integralnośd (ang. integrity) Każdy proces decyduje się tylko raz. Jednolita zgodnośd (ang. uniform agreement) Żadne dwa procesy, niekoniecznie poprawne, nie decydują się na inne wartości. Innymi słowy, jeżeli jakikolwiek proces podejmie decyzję- nawet jeżeli jest on niepoprawny- to wszystkie inne procesy muszą podjąd identyczną decyzję. Pierwsze trzy własności są identyczne jak w konsensusie podstawowym (patrz: Konsensus podstawowy), zaś różnią się własnością ostatnią. W przypadku konsensusu podstawowego własnośd zgodności dotyczyła tylko poprawnych procesów, zaś jednolita zgodnośd wymaga zgodności między wszystkimi procesami niezależnie od tego, czy są poprawne, czy nie. Operacja propose Proponowana do uzgodnienia przez proces wartośd określana jest w wyniku wykonania operacji . Operacja ta inicjuje mechanizm konsensusu jednolitego. Zdarzenie, zachodzące w procesie . Operacja decide Określenie przez proces (monitor w wyniku wykonania operacji konsensusu jednolitego. Zdarzenie wartości w wyniku wykonania tej operacji zapisywane będzie jako ) decyzji, co do ostatecznie uzgodnionej wartości następuje . Wykonanie tej operacji kooczy mechanizm , zachodzące w procesie w wyniku wykonania operacji , oznacza osiągnięcie przez proces aplikacyjny konsensusu, a więc uzgodnienia z wszystkimi pozostałymi procesami. Algorytm rozgłoszeniowy Niżej przedstawiony algorytm będzie modyfikacją rozgłoszeniowego algorytmu konsensusu podstawowego, dzięki której algorytm ten rozwiązuje problem konsensusu jednolitego. Nowy algorytm, podobnie jak poprzednio, zakłada: Dostępnośd mechanizmu podstawowego rozgłaszania niezawodnego (patrz: Wykład 12: Podstawowe rozgłaszanie niezawodne) Dostępnośd doskonałego detektora awarii (patrz: Wykład 11: Klasyfikacja detektorów) Zasadniczą różnicą między tymi algorytmami jest fakt wstrzymania się wszystkich procesów z decyzją do -tej rundy, gdzie oznacza liczbę procesów. W przeciwieostwie do algorytmu, rozwiązującego konsensus podstawowy, w prezentowanej wersji używany jest tylko jeden typ wiadomości- MYPROP. Jego struktura jest identyczna jak poprzednio. Wszystkie zmiennej używane przez wersję algorytmu rozgłoszeniowego dla jednolitego konsensusu są identyczne jak dla wersji podstawowej. Dodana jest jedynie tablica , zawierająca identyfikatory procesów, od których w danej rundzie otrzymano wiadomośd, natomiast zmienna jest zmienną logiczną, określającą, czy proces podjął już decyzję. type MYPROP extends FRAME is record of : set of INTEGER : INTEGER end record : MYPROP : BOOLEAN : set of INTEGER : INTEGER : set of PROCESS_ID : array 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. of set of PROCESS_ID /* Zainicjowanie rozgłoszeniowego algorytmu konsensusu jednolitego związane jest z zajściem zdarzenia w procesie aplikacyjnym . W efekcie tego zdarzenia, monitor rozpoczyna wymianę wiadomości z innymi monitorami w celu uzgodnienia wspólnej decyzji. Uzgodnienie to prowadzi do zajścia zdarzenia */ when do end when /* W wyniku wykrycia awarii z użyciem detektora awarii P, proces poprawnych procesów widzianych przez dowolny proces when do jest usuwany ze zbioru */ end when /* W przypadku otrzymania propozycji od monitora , wartośd pola z pola otrzymanej wiadomości MYPROP dodawana jest do zbioru propozycji . Sam proces dodawany jest do zbioru identyfikatorów procesów, od których w rundzie otrzymano wiadomośd z proponowanym zbiorem wartości */ when do end when /* W rozgłoszeniowy algorytmie konsensusu jednolitego, w porównaniu do algorytmu konsensusu podstawowego, inny jest warunek podjęcia decyzji. Mianowicie, decyzja podejmowana jest dopiero w -tej rundzie, pod warunkiem oczywiście, że monitor nie podjął jeszcze decyzji oraz otrzymano wiadomośd od wszystkich monitorów skojarzonych z niepodejrzewanymi w tej rundzie procesami. Monitor decyduje się na minimalny element ze zbioru wszystkich nadesłanych propozycji. Jeżeli natomiast , to następuje przejście do następnej rundy oraz rozesłanie zbioru wartości proponowanych w kolejnej rundzie */ when do if then else 23. 24. end if end when Złożoność Rozgłoszeniowy algorytm konsensusu jednolitego kooczy się w krokach, wymieniając wiadomości. Złożonośd czasowa wynosi więc , a złożonośd komunikacyjna wynosi i nie rozróżnia się tutaj dwóch przypadków- optymistycznych i pesymistycznych. Algorytm hierarchiczny Obecnie przedstawiony algorytm, rozwiązujący problem konsensusu jednolitego, jest modyfikacją algorytmu hierarchicznego konsensusu podstawowego. Założenia poprawności algorytmu są nadzbiorem założeo dla wersji algorytmu dla problemu konsensusu podstawowego i są następujące: dostępny jest mechanizm podstawowego rozgłaszania niezawodnego (patrz: Wykład 12: Podstawowe rozgłaszanie niezawodne) dostępny jest doskonały detektor awarii (patrz: Wykład 11: Klasyfikacja detektorów) dostępny jest mechanizm zgodnego rozgłaszania niezawodnego (patrz: Wykład 12: Zgodne rozgłaszanie niezawodne) dostępnośd mechanizmu kanałów niezawodnych (patrz: Wykład 11: Kanały niezawodne) Podobnie jak poprzednio przyjmuje się, że hierarchia procesów jest zdefiniowana przez uporządkowanie procesów wg ich indeksów. Zasadnicza różnica w algorytmach hierarchicznych konsensusu podstawowego i jednolitego związana jest z podziałem każdej rundy na dwa etapy: w pierwszym etapie lider wysyła propozycję decyzji (propozycja), a w drugim używa zgodnego rozgłaszania niezawodnego do rozesłania podjętej decyzji (potwierdzanie). Przejście do nowej rundy następuje tylko wówczas, gdy lider jest podejrzewany. Hierarchiczny algorytm konsensusu jednolitego używa trzech typów wiadomości. Typ PROPOSE przechowuje wartośd proponowanej decyzji w polu oraz numer rundy (pole ), w której tę propozycję wysłano. Typ DECIDE zawiera wartośd decyzji w polu . Typ ACK zawiera numer rundy w polu . Wyjaśnienia wymaga użycie zmiennych, które nie występowały w wersji algorytmu dla konsensusu podstawowego. Oprócz wiadomości typu ACK oraz typu PROPOSE pojawia się dodatkowo zbiór , zawierający identyfikatory procesów, od których otrzymano potwierdzenia propozycji, a także tablica , zawierająca wszystkie propozycje, gdzie -ty element oznacza propozycję, nadchodzącą w -tej rundzie. type PROPOSE extends FRAME is record of : set of INTEGER : INTEGER end record type DECIDE extends FRAME is record of : INTEGER end record type ACK extends FRAME is record of : INTEGER end record : DECIDE : ACK : PROPOSE : INTEGER : INTEGER : INTEGER : array of PROCESS_ID : set of PROCESS_ID : set of PROCESS_ID : array of INTEGER /* Monitor 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. zapisuje propozycję procesu when w zmiennej */ do end when /* W przypadku wykrycia awarii jakiegoś procesu jest on dołączany do zbioru . Z własności silnej dokładności doskonałego detektora awarii P (patrz: Wykład 11: Własnośd dokładności) wynika, że żaden poprawny proces nigdy nie będzie podejrzewany */ when do end when /* Jeżeli monitor odkrywa, że ma byd liderem rundy i nie podjął dotąd jeszcze decyzji, rozsyła swoją propozycję za pomocą podstawowego rozgłaszania niezawodnego */ when do end when /* Otrzymanie propozycji o numerze rundy powoduje zapamiętanie jej w -tym elemencie tablicy . Jeżeli numer rundy zawarty w polu odebranej wiadomości typu PROPOSE jest niemniejszy od numeru bieżącej rundy, wysyłane jest potwierdzenie do nadawcy. Warunek ten oznacza, że odebrana wiadomośd nie pochodzi od niepoprawnego procesu. Przejście do nowej rundy następuje bowiem tylko wtedy, gdy lider jest niepoprawny. Z własności doskonałego detektora awarii wynika, że lider nie byłby podejrzewany, gdyby był poprawny */ when do if end if then 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. end when /* Jeżeli lider bieżącej rundy jest podejrzewany, rozpoczynana jest nowa runda */ when do if then end if end when /* W przypadku otrzymania potwierdzenia, dołączane jest ono do zbioru when do */ end when /* Jeżeli lider otrzymał potwierdzenia od wszystkich poprawnych monitorów, rozsyła swoją decyzję za pomocą niezawodnego rozgłaszania */ when do end when /* Po otrzymaniu wiadomości typu DECIDE od lidera, każdy monitor również podejmuje identyczną decyzję */ 56. when 57. 58. 59. end when do Złożoność Algorytmy, rozwiązujące problem konsensusu jednolitego mają większą złożonośd niż rozwiązujące problem konsensusu podstawowego. Odnosi się to również do algorytmów rozgłoszeniowych. Jeżeli lider nie ulegnie awarii (przypadek optymistyczny), algorytm hierarchiczny kooczy się po krokach: kroki w pierwszej rundzie i dodatkowy na niezawodne rozgłaszanie, wymieniając przy tym wiadomości. Złożonośd czasowa w przypadku optymistycznym wynosi zatem , a złożonośd komunikacyjna- . Każda awaria lidera dodaje dwa dodatkowe kroki i wiadomości. Maksymalna liczba awarii wynosi oczywiście , a więc w przypadku pesymistycznym, złożonośd czasowa jest równa , a złożonośd komunikacyjna wynosi . Konsensus probabilistyczny Specyfikacja Poprzednio omawiane algorytm wymagały spełnienia dośd silnego założenia dostępności doskonałego detektora awarii. Mechanizm konsensusu probabilistycznego (ang. randomized consensus, probabilistic consensus), który nie ma tak silnych wymagao, charakteryzuje się następującymi własnościami: Ważnośd (ang. validity) Jeżeli proces decyduje się na jakąś wartośd, to wartośd ta została wcześniej zaproponowana przez pewien proces. Zgodnośd (ang. agreement) Żadne dwa poprawne procesy nie decydują się na inne wartości. Integralnośd (ang. integrity) Każdy proces decyduje się tylko raz. Zakooczenie probabilistyczne (ang. probabilistic termination) Wszystkie poprawne procesy, z prawdopodobieostwem równym 1, ostatecznie decydują się na jakąś wartośd. Jak łatwo zauważyd, konsensus probabilistyczny odróżnia się od poprzednich sformułowaniem warunku zakooczenia (własnośd zakooczenia probabilistycznego). Operacja propose Proponowana do uzgodnienia przez proces wartośd określana jest w wyniku wykonania operacji . Operacja ta inicjuje mechanizm konsensusu jednolitego. Zdarzenie, zachodzące w procesie . Operacja decide Określenie przez proces (monitor w wyniku wykonania operacji konsensusu probabilistycznego. Zdarzenie wartości w wyniku wykonania tej operacji zapisywane będzie jako ) decyzji, co do ostatecznie uzgodnionej wartości następuje . Wykonanie tej operacji kooczy mechanizm , zachodzące w procesie w wyniku wykonania operacji , oznacza osiągnięcie przez proces aplikacyjny konsensusu, a więc uzgodnienia z wszystkimi pozostałymi procesami. Algorytm Poniższy algorytm jest modyfikacją dobrze znanego probabilistycznego algorytmu, rozwiązującego konsensus binarny. Zakłada on: Dostępnośd mechanizmu podstawowego rozgłaszania niezawodnego Dostępnośd mechanizmu zgodnego rozgłaszania niezawodnego Poprawnośd większości procesów Zauważmy, że algorytm nie wymaga obecności detektora awarii. Każda runda podzielona jest na dwie fazy. W pierwszej fazie korzysta się z podstawowego rozgłaszania niezawodnego, a w drugiej ze zgodnego rozgłaszania niezawodnego do rozsyłania decyzji. W każdej rundzie istnieje prawdopodobieostwo większe od zera, że algorytm się zakooczy, tak więc ostatecznie prawdopodobieostwo zakooczenia wynosi 1. Algorytm używa czterech typów wiadomości. Typ INIVAL służy do przesyłania wartości proponowanych przez procesy, która to wartośd przenoszona jest w polu . Typ DECIDE posiada pole , zawierające decyzję oraz numer rundy w polu , w której decyzję tę podjęto. Pozostałe typy posiadają pole , zawierające propozycję decyzji oraz numer w polu , oznaczający numer rundy, w czasie której wysłano wiadomośd. Znaczenie niektórych zmiennych jest następujące: zawiera przybliżenie decyzji, zaś zawiera decyzję procesu , przy czym zmienne te są zainicjowane specjalnymi wyróżnionymi wartościami pustymi. Tablica zawiera wartości początkowe nadesłane przez pozostałe procesy. Tablice zbiorów oraz zawierają propozycje nadesłane przez procesy w odpowiednio, pierwszej i drugiej fazie danej rundy. type INIVAL extends FRAME is record of : INTEGER end record type DECIDE extends FRAME is record of : INTEGER : INTEGER end record type PHASE1 extends FRAME is record of : INTEGER : INTEGER end record type PHASE2 extends FRAME is record of : INTEGER : INTEGER end record : DECIDE : PHASE1 : PHASE2 : INIVAL : INTEGER : INTEGER : INTEGER : array : array : array 1. 2. 3. of INTEGER of set of INTEGER of set of INTEGER /* Proponując daną wartośd, monitor rozsyła ją za pomocą podstawowego rozgłaszania niezawodnego, zapamiętuje swoją propozycję, przypisuje ją do zmiennej , zwiększa numer rundy oraz następnie rozsyła swoją propozycję ponownie jako wiadomośd typu PHASE1 */ when do 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. end when /* Otrzymując wartośd początkową zaproponowaną przez inny monitor dodaje ją do zbioru wartości początkowych */ when do , monitor end when /* Otrzymując wiadomośd typu PHASE1, pochodzącej z -tej rundy, monitor dodaje przenoszoną przez nią wartośd do zbioru, będącego -tym elementem tablicy */ when do end when /* W przypadku, gdy monitor otrzymał od większości procesów wiadomości typu PHASE1 oraz jeszcze do tej pory nie podejmował decyzji, to sprawdza on, czy wszystkie wartości w zbiorze dla tej rundy są identyczne- równe . Jeżeli tak, przyjmuje jako właśnie . Jeżeli nie, jako przyjmuje wartośd pustą. Następnie wartośd jest rozsyłana za pomocą podstawowego rozgłaszania niezawodnego, rozpoczynając drugą fazę rundy */ when if do then else end if end when /* Otrzymując wiadomośd typu PHASE2, pochodzącej z -tej rundy, monitor dodaje przenoszoną przez nią wartośd do zbioru, będącego -tym elementem tablicy */ when do end when /* Po otrzymaniu wiadomości PHASE2 w -tej rundzie od większości procesów, monitor , o ile jeszcze nie podjął decyzji, sprawdza najpierw, czy istnieje taka wartośd , różna od wartości pustej, że wszystkie propozycje ze zbioru, będącego -tym elementem tablicy równają się . Jeżeli tak, to monitor decyduje się na tą wartośd i decyzję tę rozsyła za pomocą zgodnego rozgłaszania niezawodnego. W przeciwnym razie, to znaczy, jeżeli wartości należące do tablicy są różne, monitor wybiera jako swoją nową propozycję w zmiennej dowolną, różną od wartości pustej, propozycję ze zbioru, będącego -tym elementem tablicy . Jeżeli taka wartośd propozycji nie istnieje (wszystkie elementy tego zbioru równają się wartości pustej), to monitor losuje wartośd ze zbioru otrzymanych propozycji początkowych i rozpoczyna fazę pierwszą nowej rundy, rozsyłając wiadomośd PHASE1, zawierającą nową propozycję monitora */ 30. when do 31. if 32. 33. 34. 35. 36. else 37. if 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. then then else end if end if end when /* Po otrzymaniu wiadomości typu DECIDE, monitor podejmuje decyzję, wykonuje operację , I tym samym inicjuje zdarzenie */ when do end when Potrzeba randomizacji Można zadad pytanie, dlaczego w wierszu 40-tym występuje losowe wybranie wartości, zamiast dokonanie wyboru za pomocą ściśle określonej deterministycznej funkcji. Uzasadnienie przedstawione jest na rysunku poniżej, który obrazuje przykładowe wykonanie algorytmu. Wyobraźmy sobie, że każdy monitor, zamiast w wierszu 40-tym losowad wartośd, wybiera pierwszą wartośd różną od wartości pustej. Monitor dostaje wartośd od . Ponieważ obie wartości się różnią ( ), więc , zgodnie z wierszem 21-szym, wybierze wartośd pustą jako propozycję wartości do uzgodnienia. Identyczna sytuacja zajdzie w monitorze , natomiast monitor otrzyma propozycję wartości , i ponieważ wszystkie otrzymane wartości są identyczne, zaproponuje dalej . W drugiej fazie może z kolei zajśd sytuacja, w której otrzymałby wartośd pustą od i dlatego deterministycznie (zamiast losowo) wybrałby wartośd . Monitor natomiast otrzymałby wartośd od , i ponieważ jest ona różna od wartości pustej, przyjąłby ją jako swoją propozycję. z kolei otrzymuje od wartośd pustą, ale ponieważ sam wcześniej zaproponował wartośd różną od wartości pustej, przyjmuje ją jako podstawę do kolejnej rundy. Jak widad, w kolejnej rundzie wszystkie procesy proponują dokładnie takie same wartości jak poprzednio- a ponieważ taka sytuacja może się powtarzad, skutkuje to niebezpieczeostwem, że algorytm nigdy by się nie skooczył. Stąd właśnie wynika potrzeba randomizacji. Algorytm zgodnego rozgłaszania uporządkowaniem wiadomości niezawodnego z globalnym W poprzedniej części wykładu zostały przedstawione różne algorytmy, implementujące mechanizm konsensusu. Zostało już wcześniej wspomniane (patrz: Konsensus- wprowadzenie), że dostęp do takich mechanizmów umożliwia łatwe skonstruowanie mechanizmu (abstrakcji) zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości. Obecnie zostanie przedstawiony algorytm, zakładający dostępnośd: mechanizmu rozgłaszania niezawodnego mechanizmu konsensusu podstawowego, zapewniający dostęp do operacji rozgłaszania o własnościach zgodnego rozgłaszania niezawodnego z globalnym uporządkowaniem wiadomości. Wiadomości typu PACKET zawierają wiadomości aplikacyjne w polu oraz identyfikator pierwotnego nadawcy wiadomości w polu . Zbiór zawiera wiadomości dostarczone już do procesu aplikacyjnego, zaś zbiór otrzymane pakiety, zawierające wiadomości oczekujące na dostarczenie. Zbiór zawierad będzie efekt decyzji podjętej w wyniku konsensusu- posortowany zbiór pakietów o identycznym składzie dla każdego procesu. type PACKET extends FRAME is record of : INTEGER : MESSAGE end record : PACKET : MESSAGE : set of MESSAGE : ordered set of PACKET : ordered set of PACKET : BOOLEAN 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. /* Jeżeli proces aplikacyjny chce rozgłosid wiadomośd, monitor z nim skojarzony buduje pakiet, zawierający tę wiadomośd i rozgłasza ją z użyciem mechanizmu zgodnego rozgłaszania niezawodnego */ when do end when /* Monitor, otrzymujący pakiet dodaje go do zbioru wiadomości niedostarczonych, czekających na kolejny konsensus */ when do if end if end when then 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. /* Jeżeli zbiór wiadomości jest niepusty i monitor nie jest w trakcie uzgadniania kolejności wiadomości do odebrania, to proponuje on własny zbiór jako zbiór wiadomości do dostarczenia, na przykład w porządku, w jakim sam je otrzymał */ when do end when /* W ramach konsensusu monitory decydują się na zbiór wiadomości przeznaczonych do dostarczenia. Po uzyskaniu konsensusu każdy monitor dostarcza wiadomości z tego zbioru w uzgodnionym porządku */ when do for all do end for end when when end when /* W momencie aktywacji procesu */ when do do zmiennej przypisywana jest wartośd end when Złożoność Przedstawiony algorytm wymaga kroków i wymiany wynosi zatem , natomiast złożonośd komunikacyjna- . komunikatów. Jego złożonośd czasowa
