Algorytm Maekawa
Plan Przypomnienie - algorytm Lamporta Idea algorytmu Generowanie zbiorów arbitrażu Zakleszczenia Przykład Analiza założeń Przypadki pesymistyczne Podsumowanie
Algorytm Lamporta Rozwiązuje problem rozproszonego wykluczenia, Wolny od zakleszczeń, Wymaga wielu broadcastów, Niepraktycznie duża złożoność komunikacyjna (3n-3). Czy można to ulepszyć?
Algorytm Maekawa Nie musimy prosić o zgodę wszystkich węzłów. Wystarczy że poprosimy te, które odmówiłyby wszystkim innym.
Algorytm Maekawa Pogrupujmy węzły w zbiory w taki sposób, aby dowolne dwa zbiory miały niezerową część wspólną. Przykład w szachach - obszar bicia dowolnych dwóch wież ma część wspólną (co najmniej dwa pola).
Algorytm Maekawa a) Przecięcia zbiorów są niepuste (wymagane dla zapewnienia wzajemnego wykluczania). b) Każdy węzeł należy do własnego zbioru (w celu zmniejszenia liczby wiadomości). c) Zbiory mają taki sam rozmiar* (każdy węzeł wykonuje równą ilość pracy). d) Dowolny węzeł należy do takiej samej liczby różnych zbiorów arbitrażu* (równa odpowiedzialność w udzielaniu zgody - każdy potrzebuje zgody od takiej samej liczby węzłów).
Algorytm Maekawa Przykład: Przecięcia zbiorów są niepuste, Każdy węzeł występuje 3 razy. Dla wartości takich że, powyższe warunki będą w niewielkim stopniu odchylone.
Algorytm Maekawa N - ilość węzłów w sieci K - ilość węzłów w zbiorze arbitrażu
Algorytm Maekawa Założenia: kanały FIFO, znana ilość węzłów, bezawaryjność węzłów, bezawaryjność łączy.
Rodzaje zapytań REQUEST LOCKED RELEASE FAILED INQUIRE RELINQUISH - proszę o zgodę na CS - zgoda na CS - wyszedłem z CS - poczekaj, jest ktoś ważniejszy - zgłosił się do mnie ktoś ważniejszy - zrzekam się twojej zgody na CS
Algorytm Maekawa Węzeł chcący wejść do sekcji krytycznej wysyła wiadomość REQUEST do każdego węzła w swojej grupie arbitrażu. Dostęp do CS jest możliwy po otrzymaniu kompletu odpowiedzi LOCKED. Węzeł otrzymujący REQUEST odpowiada LOCKED jeśli nie jest zablokowany. Odpowiadając, zmienia swój stan na zablokowany.
Algorytm Maekawa Jeśli zablokowany węzeł otrzyma REQUEST, umieszcza go w swojej kolejce priorytetowej. Następnie: Jeśli REQUEST ma wyższy priorytet od blokującej wiadomości oraz od wszystkich w kolejce, wysyła INQUIRE do blokującego procesu. W przeciwnym wypadku wysyła FAILED do procesu który nadał REQUEST.
Algorytm Maekawa Otrzymuję REQUEST. Czy jestem zablokowany? nie Blokuję się z tym REQUESTem. Odpowiadam: LOCKED. tak nie REQUEST wpada do kolejki. Odpowiadam: FAILED. Czy ten REQUEST jest ważniejszy od wszystkich które obsługuję*? tak REQUEST wpada do kolejki. Wysyłam do blokującego: INQUIRE. * obsługuję : obługiwany REQUEST to ten blokujący oraz każdy znajdujący się w kolejce.
Algorytm Maekawa Aby wejść do CS, węzeł czeka na komplet LOCKED. Po wyjściu z CS, wysyła RELEASE. Węzeł otrzymujący RELEASE wysyła LOCKED do węzła którego REQUEST ma najwyższy priorytet według jego kolejki. Jeśli kolejka jest pusta, węzeł staje się niezablokowany.
Algorytm Maekawa Co z taką sytuacją? REQ REQ LOCK LOCK REQ REQ
Algorytm Maekawa Co z taką sytuacją? REQ REQ REQ LOCK FAIL FAIL LOCK REQ
Algorytm Maekawa Rozwiązywanie zakleszczeń - mechanizm INQUIRE Jeśli widzę że wydałem blokadę (wysłałem LOCKED) węzłowi o niższym priorytecie, pytam go czy jest pewien że nie ma zakleszczenia.
Algorytm Maekawa Węzeł otrzymujący INQUIRE odpowiada RELINQUISH (zrzeka się przyznanego mu LOCKED) jeśli otrzymał już chociaż jeden komunikat FAILED. Jeśli nie, węzeł zapamiętuje INQUIRE na wypadek gdyby FAILED przybył póżniej.
Algorytm Maekawa To tyle! Spójrzmy na pseudokod.
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Algorytm Maekawa
Przykład Spójrzmy na przykład dla 7 węzłów.
R,L R 1 7 2 R L 6 3 5 4
R,L R 1 R,L 7 2 R R L R L 6 3 5 4
R,L R,L R 1 R,L 7 2 R R R L L R 6 3 F queue = [7] R L 5 4
R,L R,L R 1 I 7 R,L 2 R queue = [1] R L L R R 6 3 F queue = [7] R I L 5 4
R,L R,L R 1 I 7 R,L 2 R queue = [1] R L L R R 6 3 F R I queue = [7] L L 5 4 Q...więcej strzałek? queue = [7]
1 REL 7 2 queue = [1] REL 6 REL 3 queue = [7] 5 4 queue = [7]
1 L REL 7 2 queue = [ ] REL 6 L REL 3 queue = [7] 5 4 queue = [ ]
REL 1 L 7 REL REL 6 L REL 2 REL REL 3 queue = [7] 5 4
REL 1 L 7 REL REL REL 2 REL L 6 L REL 3 queue = [ ] 5 4
Co jeśli nie ma FIFO 1 R R 2 L I 3
Co jeśli nie ma FIFO 1 R REL 2 F L 3
Modyfikacje dla non-fifo zapamiętuj znaczniki czasowe otrzymanych wiadomości FAILED, INQUIRE, LOCKED per osoba wykrywaj sytuacje (wykorzystując znaczniki czasowe) LOCKED po INQUIRE FAILED po LOCKED
Modyfikacje dla non-fifo przy otrzymaniu LOCKED po INQUIRE: jeśli wysłano już RELINQUISH: ignoruj jeśli nie wysłano RELINQUISH: ignoruj ale dodatkowo zachowaj się jakby otrzymano FAILED (wyślij RELINQUISH do wszystkich od których otrzymano INQUIRE)* przy otrzymaniu FAILED po LOCKED: ignoruj
Złożoność komunikacyjna Przy małym obciążeniu: K - 1 wiadomości REQUEST K - 1 wiadomości LOCKED K - 1 wiadomości RELEASE = 3 (K - 1)
Złożoność komunikacyjna Przy dużym obciążeniu: Nowe żądanie będzie miało niski priorytet i dostanie same FAILED. K - 1 wiadomości REQUEST K - 1 wiadomości FAILED K - 1 wiadomości LOCKED K - 1 wiadomości RELEASE = 4 (K - 1)
Złożoność komunikacyjna Najgorszy przypadek: Węzeł wysyłający REQUEST nie uczestniczył w algorytmie przez pewien czas, przez co jego żądanie ma wyższy priorytet od innych. K - 1 wiadomości REQUEST K - 1 wiadomości INQUIRE* K - 1 wiadomości RELINQUISH K - 1 wiadomości LOCKED K - 1 wiadomości RELEASE = 5 (K - 1)
Brak zakleszczeń (1) Dowód nie wprost: Załóżmy, że istnieje zakleszczenie. Jeśli tak jest, musi istnieć cykl węzłów oczekujących na siebie. Jednak nie jest to możliwe, gdyż: 1. Priorytety są unikatowe (znacznik czasowy unikalny dla węzła, id węzła też unikalny). 2. Musi istnieć węzeł o niższym priorytecie* w stosunku do sąsiadów w cyklu.
Brak zakleszczeń (2) 3. 2 sąsiednie węzły w cyklu mają co najmniej 1 wspólny węzeł w zbiorach arbitrażu (o który będą się ubiegały). 4. Jeśli węzeł o wyższym priorytecie nie uzyska LOCKED to wysyła INQIURE. 5. Węzeł o niższym priorytecie wyśle RELINQUISH jeśli wie, że nie uda mu się zablokować wszystkich węzłów z jego zbioru arbitrażu.
Brak zakleszczeń (3) 6. Węzeł wspomniany w 2. na pewno dostanie jakąś wiadomość FAILED (przegra z którymś z sąsiadów) a po otrzymaniu INQUIRE wyśle RELINQUISH i jeden z węzłów otrzyma LOCKED na który czekał. Dochodzimy do sprzeczności, tak więc twierdzenie jakoby zakleszczenie możliwe było ku sprzeczności wiedzie nas, tak więc twierdzenie zajść musi, albowiem jego niezajście sprzeczności rodzi. :D
Dowód poprawności 1. Każdy proces może udzielić jednocześnie wyłącznie jednej zgody (LOCKED). 2. Dowolne dwa procesy chcące uzyskać dostęp do CS będą musiały poprosić o zgodę wspólny węzeł (z konstrukcji zbiorów arbitrażu). Z punktu 1 i 2 mamy że dwa procesy nie mogą jednocześnie być w sekcji krytycznej.
Dowód postępu (1) 1. Wiadomość REQUEST nie opuści kolejki procesu dopóki nadawca nie otrzyma odpowiedzi LOCKED. 2. Jeśli proces posiadający LOCKED wyśle RELINQUISH, jego REQUEST wróci do kolejki. Wniosek A: z 1 i 2 mamy że dopóki proces nie wejdzie do CS, jego wiadomości REQUEST będą w kolejkach lub będą blokowały węzły. (REQUESTy nie będą zapomniane ).
Dowód postępu (2) 1. Dla dowolnej wiadomości REQUEST istnieje skończona ilość innych wiadomości REQUEST o wyższym priorytecie (z zegarów Lamporta). 2. Mechanizm INQUIRE wyklucza istnienie zakleszczeń. Wniosek B: Każdy REQUEST zostanie obsłużony w skończonym czasie.
Dowód postępu (3) A. Dopóki proces nie wejdzie do CS, jego wiadomości REQUEST będą w kolejkach lub będą blokowały węzły. B. Każdy REQUEST zostanie obsłużony w skończonym czasie. Wniosek: każdy węzeł otrzyma dostęp do CS w skończonym czasie.
Generowanie zbiorów arbitrażu Warunki dla zbiorów arbitrażu: każdy węzeł znajduje się w K zbiorach, zbiory arbitrażu mają moc K. Problem generowania zbiorów jest tożsamy z problemem istnienia skończonych przestrzeni projekcyjnych.
Generowanie zbiorów arbitrażu Przestrzeń projekcyjna: dowolne dwa punkty leżą na dokładnie jednej wspólnej prostej, dowolne dwie proste przecinają się w dokładnie jednym punkcie.
Generowanie zbiorów arbitrażu Skończona przestrzeń projekcyjna: Problem: czy istnieje przestrzeń projekcyjna dla danego N?
Generowanie zbiorów arbitrażu Euler (1782): (pomylił się)
Generowanie zbiorów arbitrażu Bruck, Ryser (1949): Gdyby istniała FPP(6), to 6 dałoby się zapisać jako sumę kwadratów, a tak nie jest.
Generowanie zbiorów arbitrażu FPP(10)? 10 = 1 + 9 Niestety, nie. C.W.H. Lam, L.Thiel, S.Swiercz (1989) - Dowód poprzez przeszukanie wyczerpujące, CRAY-1A
Generowanie zbiorów arbitrażu Jeśli N jest potęgą liczby pierwszej, to istnieje FPP(N). Nie jest znana żadna FPP której rząd nie jest potęgą liczby pierwszej. Kwestia istnienia takiej FPP pozostaje otwarta.
Generowanie zbiorów arbitrażu Istnieje metoda generowania FPP dla N będących potęgą liczby pierwszej. Jej studium pozostawiamy wnikliwości słuchaczy :) Aby stworzyć zbiory arbitrażu, konstruujemy FPP dla najbliższej wartości N nie mniejszej od ilości węzłów.
Generowanie zbiorów arbitrażu Dysponując FPP(N), gdzie N > P, degenerujemy zbiory według następującej reguły: Usuwamy zbiory Każdą wartość większą od zamieniamy na
Generowanie zbiorów arbitrażu
Zalety algorytmu Maekawa Algorytm szybszy od Lamporta Nie są wykorzystywane broadcasty
Wady algorytmu Maekawa Trudno uzyskać dynamiczne dołączanie / odłączanie węzłów* Względna złożoność implementacyjna * Maekawa się z nami tutaj nie zgadza