Komunikacja asynchroniczna... 23

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) Wprowadzenie b) Podstawowe definicje c) Charakterystyka środowiska przetwarzania rozproszonego d) 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) Optymalne zrównoleglenie algorytmów przetwarzania b) Ocena poprawności i efektywności algorytmów rozproszonych c) Alokacja zasobów rozproszonych d) 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 R max oraz R peak są wyrażone w TFlops ach. Rank 1 2 3 4 Site Oak ridge National Laboratory National Supercomputing Centre in Shenzhen (NSCS) China DOE/NNSA/LANL United States 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 R max R peak 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

5 Sciences/University of Tennessee United States Forschungszentrum Juelich (FZJ) Germany / 2009 Cray Inc. JUGENE - Blue Gene/P Solution / 2009 IBM Prawo Moore a na temat szybkości komputerów jest nadal prawdziwe! Przykłady środowisk Internet 294912 825.50 1002.70 2268.00 Liczba użytkowników sieci Internet *mln+ 1995 2002 2005 (?)2015 45 445,9 1080 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 różnych liczb 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 w taki sposób, że dla każdego mamy, oraz : - 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) Proces sekwencyjny b) Komunikaty, kanały komunikacyjne c) Stan kanału d) Operacje komunikacyjne e) Model formalny procesu sekwencyjnego f) Zdarzenia g) Warunek uaktywnienia h) 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 w kanale, a więc wykonanie podstawienia Jeżeli kanał nie jest pusty (predykat ma wartośd ) i pewna wiadomośd jest bezpośrednio dostępna ( ma wartośd ), to efektem wykonania tej operacji jest pobranie wiadomości z kanału, a więc wykonanie podstawienia 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:, a Jeżeli zajście zdarzenia 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 procesu i ewentualnie stan incydentnych z procesem kanałów lub. Jeżeli operacja odpowiadająca zdarzeniu została wykonana, to powiemy, że zdarzenie zaszło. Klasy zdarzeń

Zachodzi w procesie Zachodzi w procesie, w wyniku wykonania przez ten proces operacji, w wyniku wykonania przez ten proces operacji Zachodzi w procesie, gdy wykonał operację, a odczytana do zmiennej lokalnej wiadomośd pochodziła od procesu Zachodzi w procesie, gdy wykonał operację, a odczytane do zmiennej lokalnej 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 o Nadanie procesowi stan (w szczególności stan początkowy) 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 oznaczający, że w danej chwili zdarzenie jest dopuszczalne. 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 w danej chwili wyrażad będzie predykat. Predykat oznacza, że zdarzenie jest aktywne, czyli jednocześnie gotowe i dopuszczalne. Procesy zakończone, wstrzymane Powiemy, że proces jest w stanie koocowym, jeżeli zbiór zdarzeo dopuszczalnych w tym stanie jest pusty. 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 stan procesu reprezentuje zmienna logiczna, przyjmująca wartośd, 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. wszystkich zdarzeo Predykat activate Predykat zdefiniowany jest w sposób następujący: 1. Jeżeli, to 2. Jeżeli, to 3. Jeżeli i, to: Gdzie oznacza, że pasywny proces zmieni swój stan na aktywny w skooczony, chod nieprzewidywalnym czasie. Predykat ready Warunek uaktywnienia procesu formalnie wyraża predykat

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. Model jednostkowy 2. Model AND 3. Model OR 4. Podstawowy model spośród 5. Model OR-AND 6. Dysjunkcyjny model spośród 7. 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 skojarzony jest zbiór warunkujący, liczba naturalna,, oraz liczba. 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 jest zdefiniowany jako, gdzie dla każdego naturalnego,,. 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 różnych procesów ze zbioru lub wiadomości od różnych procesów ze zbioru lub lub wiadomości od różnych procesów ze zbioru. 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 ze zbiorem warunkującym określony jest predykat, gdzie. Jak łatwo zauważyd, stosownie definiując predykat wszystkie wcześniej omówione modele żądao. można oczywiście uzyskad

Wykład #3: Proces rozproszony Plan wykładu: a) Proces rozproszony b) Wykonanie procesu, historia procesu c) Stan osiągalny d) Relacja poprzedzania zdarzeo e) Diagramy przestrzenno-czasowe f) Niedeterminizm przetwarzania g) Graf stanów osiągalnych h) Monitory i) Konwencja zapisu algorytmów Proces rozproszony Proces rozproszony będący współbieżnym wykonaniem zbioru procesów sekwencyjnych, opisuje uporządkowana czwórka 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 zbiorów stanów lokalnych procesów składowych przetwarzania rozproszonego. Stan globalny procesu rozproszonego w chwili czasu globalnego 1 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ą zbiorów zdarzeo procesów składowych 1 Czas postrzegany przez teoretycznego zewnętrznego obserwatora

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,,,,,,,, składającym się naprzemiennie ze stanów i zdarzeo takim, że dla każdego,, Przez wykonanie (realizację) procesu rozumied będziemy natomiast częściowe wykonanie rozpoczynające się stanem początkowym Stan osiągalny Powiemy, że stan procesu 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 reprezentują procesy składowe przetwarzania rozproszonego

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ą, odwzorowującą zbiór zdarzeo w zbiór uporządkowany taką, że: gdzie jest relacją porządku na zbiorze. 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 lub rzeczywistych, to zegar ten nazywany jest zegarem skalarnym. Realizacja zegarów skalarnych Funkcja implementowana jest przez zmienne naturalne,, skojarzone z procesami (monitorami ). Wartośd zmiennej reprezentuje w każdej chwili wartośd funkcji, odnoszącą się do ostatniego zdarzenia, jakie zaszło w procesie, a tym samym reprezentuje upływ czasu logicznego w tym procesie. 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 when do 2 3 4 5 6 end when 7 8 when do 9 10

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 of INTEGER : INTEGER : INTEGER 1 when do 2 3 4 5 6 end when 7 8 when do 9 10 for all do 11 12 end for 13 14 15 end when 16 17 when do 18 19 end when

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 of INTEGER : array of INTEGER : BOOLEAN 1 when do 2 3 4 5 6 end when 7 8 when do 9 if 10 then 11 12 13 14 15 else 16 17 18 end if 19 while do 20 21 for all do 22 if then 23 24 25 26 27 28 end if 29 end for 30 end while 31 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 została wysłana przez wcześniej niż, lecz proces najpierw odebrał wiadomośd. Wiadomośd typu TF (ang. two-way-flush send); operacja Wiadomośd send); operacja typu FF (ang. forward-flush 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. i Mechanizm sukcesywnej konstrukcji relacji wysyłaniu kolejnych wiadomości. poprzez stosowne uaktualnienie relacji przy Niech 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. 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 of set of PACKET : array of INTEGER : array of INTEGER : array of set of INTEGER : BOOLEAN : INTEGER 1 procedure do 2 3 if then 4 if then 5 6 7 end if 8 else /* */ 9 if then 10 11 12 end if 13 end if 14 end procedure 15 16 when do 17 18 19 20 21 22 23 end when 24 25 when do 26 27 28 29 30 31 32 end when 33 34 when do 35 36 37 38 39

40 41 42 end when 43 44 when do 45 46 47 48 49 50 51 52 end when 53 54 when do 55 56 if then 57 58 else 59 60 61 end if 62 while do 63 64 for all do 65 66 if then 67 68 69 end if 70 end for 71 end while 72 end when

Ś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 of INTEGER : INTEGER 1 when do 2 3 4 5 6 end when 7 8 when do

9 wait until 10 if then 11 12 13 end if 14 for all do 15 16 end for 17 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 : 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 1 procedure TryToDeliver( : PACKET) do 2 3 if then 4 5 else 6 7 8 end if 9 if then 10 for all do 11 if then

12 13 else 14 for do 15 for all do 16 17 end for 18 19 20 end for 21 end if 22 end for 23 for all do 24 25 end for 26 end if 27 end procedure 28 29 when do 30 31 32 33 34 35 for do 36 37 end for 38 39 end when 40 41 when do 42 43 44 45 while do 46 47 48 49 for all do 50 51 52 end for 53 end while 54 end when

Funkcje kosztu Oznaczenia zbiór wszystkich poprawnych danych wejściowych algorytmu koszt wykonywania algorytmu dla danych, gdzie i rozmiar danych wejściowych (rozmiar zadania) taki, że, gdzie, jest zadaną funkcją. W praktyce, zamiast kosztu. 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: jeżeli 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: jeżeli Mówimy, że funkcja jest co najmniej rzędu funkcji, co zapisujemy: 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) Topologia połączeo- graf w pełni połączony b) Koordynator rozgłasza komunikat początku bariery ( komunikatów) c) Wszyscy uczestnicy odbierają komunikat i odsyłają potwierdzenia ( komunikatów) d) 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) Procesy aktywne i pasywne b) Definicja zakleszczenia c) Problem detekcji wystąpienia zakleszczenia d) Detekcja zakleszczenia dla modelu OR e) Detekcja zakleszczenia dla modelu AND f) 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 : PROBE : array of BOOLEAN : set of PROCESS_ID : array of BOOLEAN : INTEGER : INTEGER : BOOLEAN 1 when do 2 if then 3 for all do 4 5 6 end for 7 end if 8 end when 9 10 when do 11 for all do 12 13 end for 14 end when 15 16 when do 17 18 if then 19 20 if then

21 22 23 else 24 25 for all do 26 27 end for 28 end if 29 end if 30 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 należy do 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

: INTEGER : BOOLEAN 1 when do 2 if then 3 4 5 6 7 for all do 8 9 end for 10 11 end if 12 end when 13 14 when do 15 if then 16 17 18 if then 19 20 21 22 23 24 for all do 25 26 end for 27 28 else 29 if then 30 31 32 33 end if 34 end if 35 end if 36 end when 37 38 when do 39 if then 40 41 42 if then 43

44 if then 45 if then 46 47 48 else 49 50 51 52 53 end if 54 end if 55 end if 56 end if 57 end when 58 59 when do 60 for all do 61 62 end for 63 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 odpowiadających 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 end record : set of PROCESS_ID : set of PROCESS_ID : INTEGER : BOOLEAN : BOOLEAN : INTEGER : BOOLEAN 1 procedure do 2 3 for all do 4 5 end for 6 if then 7 8 end if 9 for all do 10 11 end for 12 end procedure 13 14 procedure do 15 16 for all do 17 18 end for : PROCESS_ID : PROCESS_ID

19 for all do 20 21 end for 22 end procedure 23 24 when do 25 NOTIFY_PROC() 26 if then 27 28 29 end if 30 end when 31 32 when do 33 34 if then 35 36 end if 37 38 end when 39 40 when do 41 if then 42 43 end if 44 45 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 end record : set of PROCESS_ID : set of PROCESS_ID : INTEGER : BOOLEAN : BOOLEAN : INTEGER : array of enum : array of enum : INTEGER : BOOLEAN 1 procedure do 2 3 for all do : PROCESS_ID : PROCESS_ID 4 5 end for 6 if then 7 8 end if

9 for all do 10 11 end for 12 end procedure 13 14 procedure do 15 16 for all do 17 18 end for 19 for all do 20 21 end for 22 end procedure 23 24 when do 25 NOTIFY_PROC() 26 if then 27 28 29 end if 30 end when 31 32 when do 33 34 if then 35 36 end if 37 38 end when 39 40 when do 41 if then 42 43 end if 44 45 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 procedure do 2 3 4 5 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 */ 6 when do 7 8 9

10 11 12 13 14 end when 15 16 when do 17 18 if then 19 20 21 22 23 if then 24 25 26 end if 27 if then 28 29 30 end if 31 end if 32 if then 33 34 35 end if 36 if then 37 38 if then 39 40 41 end if 42 if then 43 44 45 end if 46 end if 47 if then 48 /* zignoruj przetwarzaną wiadomośd typu FLOOD */ 49 end if 50 end when 51 52 when do 53

54 if then 55 56 if then 57 58 59 end if 60 if then 61 62 if then 63 if then 64 65 66 end if 67 68 69 else 70 71 72 end if 73 end if 74 end if 75 end when 76 77 when do 78 if then 79 /* zignoruj nieaktualną wiadomośd SHORT */ 80 end if 81 if then 82 /* zignoruj wiadomośd */ 83 end if 84 if then 85 /* aktualizacja wagi procesu inicjatora */ 86 if then /* jeśli warunek spełniony, to detekcja jest zakooczona */ 87 88 89 end if 90 end if 91 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 : MESSAGE : PACKET : TOKEN : ACK : BOOLEAN : BOOLEAN : INTEGER : set of PROCESS_ID : set of PROCESS_ID : INTEGER : BOOLEAN : BOOLEAN 1 procedure do 2 if then 3

4 end if 5 wait until 6 if then 7 8 end if 9 10 end procedure 11 12 when do 13 14 15 16 17 end when 18 19 when do 20 21 if then 22 23 end if 24 25 26 27 end when 28 29 when do 30 31 if then 32 33 34 35 36 else 37 38 39 end if 40 end when 41 42 when do 43 44 45 46 end when

47 48 when do 49 50 51 52 end when 53 54 when do 55 56 end when 57 58 when do 59 60 end when

Wykład #7, 8: Konstrukcja spójnego obrazu stanu globalnego Plan wykładu: a) Stan globalny b) Konfiguracja i konfiguracja spójna c) Odcięcie oraz linia odcięcia d) Predykaty globalne e) Modele stanów globalnych f) 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 jest iloczynem kartezjaoskim stanów procesów Konfiguracja - wektor stanów lokalnych wszystkich składowych procesów sekwencyjnych procesu rozproszonego taki, że dla każdego,, Łatwo zauważyd, że 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 ciąg wybranych punktów (zdarzeo pozornych) odcinków czasu, odpowiadających stanom 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ójne- i. 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 opisanemu przez linię odcięcia odpowiada konfiguracja. Twierdzenie 9 Niech będzie konfiguracją, a odpowiadającym jej odcięciem. Konfiguracja jest konfiguracją spójną, wtedy i tylko wtedy, gdy jest odcięciem spójnym. 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 w każdej chwili czasu globalnego (rzeczywistego) zdefiniowany jest przez trzy zmienne: Przykład: - 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. Zakładamy, że w globalnym stanie początkowym znacznik znajduje się w procesie, a wszystkie kolejki są początkowo puste oraz.

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 jest monitor. Na górnej części rysunku w wyniku zdarzenia, zachodzącego w w zmiennej zapamiętany zostaje stan lokalny procesu, zmiennej nadawana jest wartośd początkowa, a znaczniki zostają wysłane do monitorów i. Odebranie pierwszego znacznika przez w wyniku zdarzenia powoduje zapamiętanie stanu 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 /* zwykła wiadomośd aplikacyjna */ : MESSAGE end record type MARKER extends FRAME /* 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 */

: 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 */ 1. procedure do 2. 3. for all do 4. 5. end for 6. 7. 8. end procedure 9. /* powoduje przesłanie stanu procesu do monitora */ 10. procedure do 11. 12. 13. 14. 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 */ 15. when do 16. 17. 18. if then 19. 20. end if 21. end when 22. 23. when do 24. 25. 26. 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 */ 27. when do 28. if then

29. 30. end if 31. 32. if then 33. 34. end if 35. 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 */ 36. when do 37. 38. if then 39. 40. end if 41. 42. 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, to wyznaczona konfiguracja, reprezentująca pewien stan globalny, jest osiągalna ze stanu, a stan globalny jest osiągalny ze stanu. Tym samym: 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 samym zapewniają spójnośd obrazu stanu globalnego., a tym 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 już nigdy nie wyśle wiadomości do, to nie ma potrzeby przesłania do znacznika. 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 aplikacyjnych wysłanych przez proces do chwili zapamiętania stanu procesu */ : set of MESSAGE /* określa zbiór wiadomości aplikacyjnych wysłanych przez proces do chwili obecnej */ : set of MESSAGE /* określa zbiór wiadomości aplikacyjnych odebranych przez proces do chwili zapamiętania stanu procesu */ : set of MESSAGE /* określa zbiór wiadomości aplikacyjnych odebranych przez proces do chwili obecnej */ /* procedura zapamiętuje stan procesu, przypisując stan lokalny do, a zawartośd zmiennych i do oraz */ 1. procedure do 2. 3. 4. 5. end procedure 6. /* procedura służy do przesłania zapisanego stanu procesu do monitora, zajmującego się konstrukcją obrazu spójnego stanu globalnego */ 7. procedure do 8. 9. 10. 11. 12. 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 */ 13. when do 14. 15. 16. 17. 18. 19. 20. end when 21. 22. when do 23. 24. 25. 26. 27. end when

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. when do 2. 3. 4. 5. for all do 6. 7. end for 8. 9. 10. 11. 12. 13. 14. end when /* otrzymując wiadomośd kontrolną monitor zapamiętuje w zmiennej moment wyznaczenia stanu lokalnego, a następnie odsyła potwierdzenie */ 15. when do 16. 17. 18. end when /* wysyłając wiadomośd monitor modyfikuje zegar wektorowy w zwykły sposób */

19. when do 20. 21. 22. 23. 24. end when 25. 26. when do 27. for all do 28. 29. end for 30. if then 31. 32. 33. end if 34. if then 35. 36. 37. 38. 39. end if 40. if then 41. 42. end if 43. 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. when do 2. 3. 4. 5. 6. 7. end when 8. 9. when do 10. 11. 12. 13. end when 14. 15. when do 16. 17. if then 18. 19. 20. end if 21. 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. procedure do 2. 3. for all do 4. 5. end for 6. 7. 8. end procedure 9. /* 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 */ 10. when do 11. 12. 13. end when 14. 15. when do 16. 17. 18. 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 */ 19. when do 20. if then 21. 22. end if 23. 24. if then 25. 26.

27. 28. end if 29. 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 */ 30. when do 31. 32. if then 33. 34. end if 35. 36. 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 */ przez monitor */ : 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 1. procedure do 2. 3. for all do 4. 5. end for 6. 7. 8. 9. 10. end procedure 11. /* 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 */ 12. when do 13.

14. 15. end when 16. 17. when do 18. if then 19. 20. end if 21. 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 */ 22. when do 23. 24. if then 25. 26. end if 27. 28. 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 */ 29. when do 30. 31. 32. for all do 33. if then 34. 35. end if 36. end for 37. if then 38. 39. 40. 41. end if 42. 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 */ 43. when do 44. 45.

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) Problem zakooczenia- przykłady b) Definicje zakooczenia c) Zakooczenie dynamiczne i statyczne d) Detekcja zakooczenia dla synchronicznego modelu przetwarzania e) Detekcja zakooczenia dla dyfuzyjnego modelu przetwarzania f) Algorytm z licznikami wiadomości g) Jednofazowy algorytm detekcji zakooczenia h) Wektorowy algorytm detekcji zakooczenia i) Detekcja zakooczenia statycznego j) 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 non- FIFO (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, przyjmujący wartośd, gdy dla jest 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 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 procesie */ : MESSAGE : PACKET : TOKEN : BOOLEAN /* określa obecnośd znacznika w : enum : BOOLEAN /* Procedura wywoływana jest przez monitor ( ) podczas inicjacji kolejnej rundy */ 1. procedure do 2. 3. 4. 5. 6. end procedure 7. /* 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 */ 8. when do 9. wait until 10. 11. end when /* Monitor zmienia kolor na jeżeli obserwowany przez niego proces aplikacyjny wysyła wiadomośd aplikacyjną do procesu o wyższym indeksie */ 12. when do 13. if then 14.

15. end if 16. 17. 18. end when 19. 20. when do 21. 22. 23. 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 */ 24. when do 25. 26. wait until 27. if then 28. if then 29. 30. 31. else 32. 33. end if 34. else 35. 36. if then 37. 38. end if 39. 40. 41. 42. end if 43. end when Model przetwarzania dyfuzyjnego Przetwarzanie dyfuzyjne (ang. diffusing computation) jest specyficznym przetwarzaniem rozproszonym, w którym wyróżnia się:

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 /* 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 */ 1. when do

2. 3. 4. 5. 6. end when /* Zdarzenie wysłania wiadomości typu SIGNAL może zajśd dla monitora tylko wtedy, gdy spełniony jest warunek. 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ą */ 7. when do 8. if then 9. 10. 11. else 12. for do 13. 14. 15. end for 16. end if 17. 18. end when /* Monitor, odbierając sygnał, dekrementuje zmienną (gdyż zmienna ta oznacza ilośd niepotwierdzonych wysłanych wiadomości). Jeżeli momencie, w którym skojarzony proces aplikacyjny decyduje o wykryciu zakooczenia przetwarzania */ 19. when do 20. 21. if then stanie się pasywny, monitor 22. wait until 23. 24. 25. end if 26. end when /* Zdarzenie wysłania wiadomości aplikacyjnej może zajśd dla monitora dla tylko wtedy, gdy */ 27. when do 28. 29., to w

30. 31. 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 */ 32. when do 33. if then 34. 35. else 36. 37. end if 38. 39. 40. 41. end when Twierdzenie 16 Jeżeli przetwarzanie dyfuzyjne uległo zakooczeniu, to fakt ten stwierdzi algorytm Dijkstry- Scholtena. 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

end record : INTEGER : MESSAGE : PACKET : TOKEN : BOOLEAN : PROCESS_ID : set of CHANNEL_ID : enum /* określa kolor monitora */ : BOOLEAN /* Zaczynając detekcję, proces wysyła znacznik do swojego następnika w cyklu, przypisując polu tego znacznika wartośd 0 */ 1. when do 2. 3. 4. end when /* Otrzymanie wiadomości aplikacyjnej przez monitor powoduje, poza uaktywnieniem procesu i dostarczeniem wiadomości, zmianę koloru procesu na */ 5. when do 6. 7. 8. 9. 10. 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 */ 11. when do 12. 13. wait until 14. if then 15. 16. else 17. 18. end if 19. 20. 21. 22. end when

/* 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 */ 23. when do 24. 25. if then 26. 27. 28. else 29. if then 30. 31. else 32. 33. end if 34. 35. 36. 37. end if 38. end when /* Zdarzenie wysłania wiadomości aplikacyjnej może zajśd dla monitora dla tylko wtedy, gdy */ 39. when do 40. 41. 42. 43. 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 wysłana została odebrana. Tym samym wszystkie kanały są w chwili stan zakooczenia. oznacza, że każda wiadomośd puste, a więc osiągnięty został 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 i odpowiednio sumy zebranych przez znacznik liczników, a więc: pamiętając, że:

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 liczniki wyznaczone w pierwszej fazie, a przez i liczniki oznaczone w drugiej fazie. 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 2, - z lematu 5, zaś - z lematu 3. Relacje * i * zachodzą jednocześnie tylko wówczas, gdy: Tym samym w chwili,, a to z kolei oznacza, że wszystkie kanały są puste, a więc wystąpiło zakooczenie przetwarzania.

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. monitor - numer sekwencyjny cyklu detekcji zakooczenia, zainicjowanego przez - 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 /* 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 */ 1. when do 2. 3. 4. 5. 6. 7. 8. end when /* Przesyłając wiadomośd aplikacyjną monitor inkrementuje zmienną oraz przypisuje jej numer cyklu detekcji zakooczenia */ 9. when do 10. 11. 12. 13. 14. 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 */ 15. when do 16. 17. 18. 19. 20. 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. when do 22. 23. if then 24. if then 25. 26. 27. else 28. 29. 30. 31. 32. 33. 34. end if 35. else 36. 37. 38. 39. 40. 41. end if 42. 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 of INTEGER : BOOLEAN : BOOLEAN /* Inicjator detekcji rozpoczyna detekcję, wysyłając znacznik typu TOKEN z wektorem oraz ustawiając wartośd zmiennej na */ 1. when do 2. for all do 3. 4. end for 5. 6. 7. 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 */ 8. when do 9. 10. if then

11. if then 12. 13. 14. 15. else 16. 17. for all do 18. 19. end for 20. 21. end if 22. end if 23. end when /* Każdy monitor nalicza indywidualnie wiadomości aplikacyjne wysłane przez, zwiększając licznik na pozycji odpowiadającej procesowi przeznaczenia */ 24. when do 25. 26. 27. 28. 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 */ 29. when do 30. 31. 32. 33. if then 34. if then 35. 36. 37. else 38. 39. 40. for all do 41. 42. end for 43. 44. end if 45. end if 46. end when

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 /* 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 */ 1. when do 2. repeat 3. 4. 5. for all do 6. 7. 8. end for 9. until 10. 11. 12. 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 */ 13. when do 14. wait until 15. 16.

17. 18. end when /* Wysyłając wiadomośd inkrementowany jest licznik, który z kolei jest zmniejszany w wyniku otrzymania potwierdzenia wiadomości */ 19. when do 20. 21. end when 22. 23. when do 24. 25. 26. 27. end when 28. 29. when do 30. 31. 32. 33. end when /* W momencie aktywacji procesu zmiennej przypisywana jest wartośd */ 34. when do 35. 36. end when Dowód poprawności algorytmu Przyjmijmy, że: - czas globalny wysłania odpowiedzi przez monitor w -tym cyklu detekcji - czas globalny rozpoczęcia -tego cyklu detekcji - czas globalny zakooczenia -tego cyklu detekcji Zachodzi oczywiście następujący związek: Twierdzenie 18 - jest wartością zmiennej (predykatu) w chwili - inicjator jest dodatkowym procesem, niezwiązanym z procesami aplikacyjnymi 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: (proces -ty jest pasywny w chwili ) Warunek C2: (nie ma żadnych procesów, od których wiadomości jeszcze nie dotarły do Warunek C3: (dostępne wiadomości nie wystarczają do uaktywnienia procesu Dowód warunku C1: Z konstrukcji algorytmu wynika, że zakooczy się on w chwili tylko wówczas, gdy każdy proces był pasywny w czasie między, a. Skoro jednak Dowód warunku C2:, więc możemy zatem wnosid, że dla każdego,. 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. z

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ą liczników, w której element oznacza liczbę wiadomości wysłanych przez do. Analogicznie, zmienna jest tablicą 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

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 */ 1. when do 2. repeat 3. 4. for all do 5. for all do 6. 7. end for 8. 9. end for 10. for all do 11. 12. for all do 13. 14. end for 15. 16. end for 17. until 18. 19. 20. 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 */ 21. when do 22. 23. 24. 25. 26. 27. end when /* Przy wysyłaniu (odbieraniu) wiadomości aplikacyjnych do monitor inkrementuje - ty wpis w tablicy ( ) */

28. when do 29. 30. 31. 32. end when /* Wysyłając wiadomośd inkrementowany jest licznik, który z kolei jest zmniejszany w wyniku otrzymania potwierdzenia wiadomości */ 33. when do 34. 35. 36. 37. end when /* W momencie aktywacji procesu zmiennej przypisywana jest wartośd */ 38. when do 39. 40. 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 otrzymujemy, że:. W efekcie. 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 predykat w przedziale dla każdego z nich zachodzi: Warunek C6: oraz pod warunkiem, że. Ponieważ każdy proces był pasywny 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) Pojęcia podstawowe (awaria, błąd, wada) b) Klasy awarii procesów c) Kanały komunikacyjne d) 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 wiadomości.. Innymi słowy, kanał nie tworzy samorzutnie Operacje komunikacyjne Operację wysłania wiadomości przez proces do procesu, gwarantującą własności kanału rzetelnego oznaczad będziemy przez będziemy jako., 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 razy do. jest dostarczona nieskooczoną liczbę 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 do procesu, gwarantującą własności kanału wytrwałego oznaczad będziemy będziemy jako., 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, gwarantującą własności kanału niezawodnego oznaczad będziemy będziemy jako. Analogicznie, przez i przekazującą wiadomośd mechanizmu komunikacyjnego (innej warstwy komunikacyjnej)., a odpowiadające jej zdarzenie zapisywad oznaczad będziemy operację uaktywniającą zdarzenie do procesu aplikacyjnego lub innego 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 /* Po stronie nadawcy implementacja mechanizmu kanałów niezawodnych jest identyczna, co jej odpowiednik dla mechanizmu kanałów wytrwałych */ 1. when do 2. // patrz: Kanały wytrwałe 3. 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 */ 4. when do 5. 6. if then 7. 8. 9. end if 10. end when

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 redukuje się do, to mówi się, że oraz są równoważne, co zapisuje się jako Wreszcie, jeżeli redukuje się do, ale nie można zredukowad do, to mówi się, że jest ściśle słabszy niż. 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, natomiast detektor myli się przez jednostki czasu na jednostek czasu, stąd ). 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 jest lepszy od ze względu na parametry (, zaś ) oraz (, 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 WA ESA EWA SC P S P S WC Q W Q 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: otrzymanie pulsu - cykliczne zdarzenie upływu czasu maksymalnego oczekiwania na - 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 wiadomości typu HEARTBEAT (pulsu). Zmienna dwóch kolejnych wiadomości HEARTBEAT (pulsu). type HEARTBEAT extends FRAME określa długośd maksymalnego czas oczekiwania na otrzymanie określa długośd czasu pomiędzy wysłaniem : HEARTBEAT : set of PROCESS_ID : set of PROCESS_ID : INTEGER : INTEGER /* 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. */ 1. when do 2. for all do 3. if then 4. 5. end if 6. end for 7. 8. end when /* Co pewien czas rozsyłane są wiadomości typu HEARTBEAT do wszystkich pozostałych procesów */ 9. when do 10. for all do 11.

12. end for 13. end when /* Otrzymanie wiadomości typu HEARTBEAT od procesu powoduje dodanie go do zbioru procesów poprawnych detektora */ 14. 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

/* 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 */ 1. when do 2. for all do 3. if then 4. 5. else 6. if then 7. 8. 9. end if 10. end if 11. end for 12. 13. end when /* Co pewien czas rozsyłane są wiadomości typu HEARTBEAT do wszystkich pozostałych procesów */ 14. when do 15. for all do 16. 17. end for 18. end when /* Otrzymanie wiadomości typu HEARTBEAT od procesu powoduje dodanie go do zbioru procesów poprawnych detektora */ 19. 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. procesu zawiera numer epoki, odzwierciedlający liczbę awarii i wznowieo pracy 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 /* Funkcja wybiera dla danego zbioru (podanego jako argument) jako lidera proces o najmniejszej liczbie awarii, którego identyfikator jest najmniejszy */ 1. function 2. for do 3. for all do 4. if then 5. 6. else 7. if 8. then

9. end if 10. end if 11. end for 12. end for 13. return 14. 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 */ 15. when do 16. if then 17. 18. 19. if then 20. 21. end if 22. end if 23. 24. end when /* Równolegle do powyższej procedury, co pewien czas proces wysyła do wszystkich pozostałych procesów swój bieżący numer epoki */ 25. when do 26. 27. for all do 28. 29. end for 30. 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 */ 31. when do 32. if then 33. if then 34. 35. 36. end if

37. else 38. 39. end if 40. 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 */ 41. when do 42. 43. 44. 45. 46. for all do 47. 48. end for 49. 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. Algorytm Algorytm podstawowego rozgłaszania niezawodnego zakłada: i przekazującą w efekcie 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 /* 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 */ 1. when do 2. 3. for all do oraz wykonanie dalej operacji

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 wcześniej rozgłoszona przez jakiś proces, to została ona (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 i przekazującą w efekcie wiadomośd wysłaną przez proces do procesu aplikacyjnego. 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 są używane lokalnie w programie obsługi zdarzenia wykrycia awarii procesu 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 /* 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 */ 1. when do 2. 3. 4. 5. 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 */ 6. when do 7. 8. if then 9. 10. 11. 12. if then 13. 14. end if 15. end if 16. end when

/* W przypadku wykrycia awarii procesu przez doskonały detector awarii P proces ten usuwany jest ze zbioru otrzymane od tego procesu */ 17. when do 18. 19. for all do 20. 21. 22. 23. end for 24. end when oraz ponownie są rozsyłane wszelkie pakiety kiedykolwiek 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

/* 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ą */ 1. when do 2. 3. 4. 5. 6. 7. 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 */ 8. when do 9. 10. if then 11. 12. 13. 14. end if 15. 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 rozgłoszona przez jakiś proces wiadomości., to została ona wcześniej. Innymi słowy, kanały nie mogą samorzutnie tworzyd 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 /* Funkcja zwraca identyfikatory wszystkich procesów, które dokonały już retransmisji pakietu */ 1. function do 2. 3. for all do 4. 5. end for 6. return 7. 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 */ 8. when do 9. 10. 11. 12. 13. end when /* Obsługa awarii procesu odbywa się w tradycyjny sposób, jako efekt działania detektora awarii */ 14. when do 15. 16. 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 */ 17. when do 18. 19. if then 20. 21. 22. end if 23. 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 */ 24. when do 25.

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 rozgłoszona przez jakiś proces., to została ona wcześniej 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). jej przesłao. oznacza czas życia wiadomości wyróżniony maksymalną liczbą kolejnych 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 /* 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 */ 1. procedure 2. 3. while do 4. 5. if then 6. 7. end if 8. end while 9. for all do 10. 11. end for 12. 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 */ 13. when do 14. 15. 16. 17. 18. 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

nadesłanego pakietu jest większe od zera, to monitor dekrementuje to pole i rozsyła ten pakiet dalej za pomocą procedury */ 19. when do 20. 21. if then 22. 23. 24. end if 25. if then 26. 27. 28. 29. 30. end if 31. 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 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.. W

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 /* 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 */ 1. procedure 2. 3. while do 4. 5. if then 6. 7. end if 8. end while 9. for all do 10. 11. end for 12. 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 */ 13. procedure 14. while do 15. 16. 17. 18. end while 19. 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. when do 21. 22. 23. 24. 25. 26. 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 */ 27. when do 28. 29. if then 30. 31. end if 32. if then 33. 34. 35. else 36. 37. for all 38. 39. 40. 41. 42. end for 43. end if 44. 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 do 46. if then 47. 48. 49. 50. else 51. if then 52. 53. 54. 55. 56. end if 57. end if 58. 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 */ 59. when do 60. 61. if then 62. 63. 64. 65. else 66. 67. end if 68. 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 i przekazującą w efekcie wiadomośd wysłaną przez proces do procesu aplikacyjnego. 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 /* 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 */ 1. when do 2. 3. 4. 5. 6. 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 */ 7. when do 8. 9. if then 10. for all do 11. if then 12. 13. 14. 15. end if 16. end for 17. 18. 19. 20. end if 21. 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 niezawodne z globalnym uporządkowaniem wiadomości 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 i przekazującą w efekcie wiadomośd wysłaną przez proces do procesu aplikacyjnego. 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

end record : INTEGER : MESSAGE type SNUPDATE extends FRAME is record of : INTEGER end record : MESSAGE : PACKET : PACKET : SNUPDATE : SNUPDATE : array of INTEGER : set of PACKET /* 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 */ 1. when do 2. 3. 4. 5. 6. 7. 8. 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 */ 9. when do 10. 11. 12. if then 13. 14. 15. 16. end if 17. end when /* Odbierając wiadomośd typu SNUPDATE od monitora, monitor ustawia wartośd -tego elementu tablicy pakietu */ na wartośd numeru sekwencyjnego przysłanego

18. when do 19. 20. 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 */ 21. when 22. 23. 24. 25. end when Przykład #1: do

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) Problem konsensusu- wprowadzenie b) Konsensus podstawowy c) Konsensus jednolity d) Konsensus probabilistyczny e) 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. w wyniku wykonania tej operacji zapisywane będzie jako Operacja decide Określenie przez proces (monitor ) decyzji, co do ostatecznie uzgodnionej wartości następuje w wyniku wykonania operacji konsensusu.. Wykonanie tej operacji kooczy mechanizm Zdarzenie, zachodzące w procesie w wyniku wykonania operacji wartości, 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 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). 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. (monitor to zbiór, zawierający zestaw wszystkich widzianych przez proces ) 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

end record : INTEGER 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 /* 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 */ 1. when do 2. 3. 4. for all do 5. 6. 7. end for 8. 9. 10. 11. end when /* W wyniku wykrycia awarii z użyciem detektora awarii P, proces jest usuwany ze zbioru poprawnych procesów widzianych przez dowolny proces */ 12. when do 13. 14. 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 */ 15. when do 16. 17. 18. end when

/* 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 */ 19. when do 20. if then 21. // zwraca najmniejszą liczbę ze zbioru 22. 23. 24. 25. 26. else 27. 28. 29. 30. 31. end if 32. 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 */ 33. when do 34. if then 35. 36. 37. 38. 39. 40. end if 41. 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 /* Monitor zapisuje propozycję procesu w zmiennej */ 1. when do 2. 3. 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 */ 4. when do 5. 6. 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 */ 7. when do 8. 9. 10. 11. 12. 13. 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 */ 14. when do 15. 16. 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 */ 17. when do 18. if then 19. 20. 21. 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. w wyniku wykonania tej operacji zapisywane będzie jako Operacja decide Określenie przez proces (monitor ) decyzji, co do ostatecznie uzgodnionej wartości następuje w wyniku wykonania operacji konsensusu jednolitego.. Wykonanie tej operacji kooczy mechanizm Zdarzenie, zachodzące w procesie w wyniku wykonania operacji wartości, 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 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 */ 1. when do 2. 3. 4. 5. 6. end when /* W wyniku wykrycia awarii z użyciem detektora awarii P, proces jest usuwany ze zbioru poprawnych procesów widzianych przez dowolny proces */ 7. when do 8. 9. 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 zbiorem wartości */ 10. when do 11. 12. otrzymano wiadomośd z proponowanym 13. 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 */ 14. when do 15. if then 16. 17. 18. else 19. 20. 21. 22.

23. end if 24. 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 zapisuje propozycję procesu w zmiennej */ 25. when do 26. 27. 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 */ 28. when do 29. 30. 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 */ 31. when do 32. 33. 34. 35. 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 */ 36. when do 37. 38. if then 39. 40. 41. end if

42. end when /* Jeżeli lider bieżącej rundy jest podejrzewany, rozpoczynana jest nowa runda */ 43. when do 44. if then 45. 46. end if 47. 48. end when /* W przypadku otrzymania potwierdzenia, dołączane jest ono do zbioru */ 49. when do 50. 51. end when /* Jeżeli lider otrzymał potwierdzenia od wszystkich poprawnych monitorów, rozsyła swoją decyzję za pomocą niezawodnego rozgłaszania */ 52. when do 53. 54. 55. end when /* Po otrzymaniu wiadomości typu DECIDE od lidera, każdy monitor również podejmuje identyczną decyzję */ 56. when do 57. 58. 59. end when 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. w wyniku wykonania tej operacji zapisywane będzie jako Operacja decide Określenie przez proces (monitor ) decyzji, co do ostatecznie uzgodnionej wartości następuje w wyniku wykonania operacji konsensusu probabilistycznego.. Wykonanie tej operacji kooczy mechanizm Zdarzenie, zachodzące w procesie w wyniku wykonania operacji wartości, 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 of INTEGER : array of set of INTEGER : array 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 */ 1. when do 2. 3.

4. 5. 6. 7. 8. 9. 10. end when /* Otrzymując wartośd początkową zaproponowaną przez inny monitor, monitor dodaje ją do zbioru wartości początkowych */ 11. when do 12. 13. 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 */ 14. when do 15. 16. 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 */ 17. when do 18. if then 19. 20. else 21. 22. end if 23. 24. 25. 26. 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 */ 27. when do 28. 29. 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 then 32. 33. 34. 35. 36. else 37. if then 38. 39. else 40. 41. end if 42. 43. 44. 45. 46. end if 47. end when /* Po otrzymaniu wiadomości typu DECIDE, monitor podejmuje decyzję, wykonuje operację, I tym samym inicjuje zdarzenie */ 48. when do 49. 50. 51. 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.