Pr-1st-1.1-m05-Slajd41: Różnice pomiędzy wersjami

Z Studia Informatyczne
Przejdź do nawigacjiPrzejdź do wyszukiwania
Szopen (dyskusja | edycje)
Nie podano opisu zmian
 
Szopen (dyskusja | edycje)
Nie podano opisu zmian
Linia 1: Linia 1:
==Alg. Bracha, Toueg’a (1)==
==Algorytm Bracha, Toueg’a (1)==


[[Image:pr-1st-1.1-m05-Slajd41.png|Alg. Bracha, Toueg’a (1)]]
[[Image:Pr-1st-1.1-m05-Slajd41.png|Algorytm Bracha, Toueg’a (1)]]


Bracha i Toueg przedstawili algorytm detekcji zakleszczenia rozproszonego dla modelu żądań ''k spośród r'' przyjmując na początek, że komunikacja jest natychmiastowa. Dla tego przypadku w każdym obrazie spójnym przetwarzania rozproszonego wszystkie kanały są puste. Obraz spójny wyrażono następnie w formie grafu oczekiwanych potwierdzeń  
Bracha i Toueg przedstawili algorytm detekcji zakleszczenia rozproszonego dla modelu żądań ''k spośród r'' przyjmując na początek, że komunikacja jest natychmiastowa. Dla tego przypadku w każdym obrazie spójnym przetwarzania rozproszonego wszystkie kanały są puste. Obraz spójny wyrażono następnie w formie grafu oczekiwanych potwierdzeń  
Linia 25: Linia 25:
Wykorzystywane są cztery typy komunikatów będących sygnałami. Są to typy: NOTIFY, DONE, CONFIRM i ACK.
Wykorzystywane są cztery typy komunikatów będących sygnałami. Są to typy: NOTIFY, DONE, CONFIRM i ACK.


[[pr-1st-1.1-m05-Slajd40 | << Poprzedni slajd]] | [[pr-1st-1.1-m05-toc|Spis treści ]] | [[pr-1st-1.1-m05-Slajd42 | Następny slajd >>]]
[[Pr-1st-1.1-m05-Slajd40 | << Poprzedni slajd]] | [[Pr-1st-1.1-m05-toc|Spis treści ]] | [[Pr-1st-1.1-m05-Slajd42 | Następny slajd >>]]

Wersja z 15:55, 7 wrz 2006

Algorytm Bracha, Toueg’a (1)

Algorytm Bracha, Toueg’a (1)

Bracha i Toueg przedstawili algorytm detekcji zakleszczenia rozproszonego dla modelu żądań k spośród r przyjmując na początek, że komunikacja jest natychmiastowa. Dla tego przypadku w każdym obrazie spójnym przetwarzania rozproszonego wszystkie kanały są puste. Obraz spójny wyrażono następnie w formie grafu oczekiwanych potwierdzeń WFG=𝒫,𝒜, w którym wierzchołki odpowiadają procesom Pi a łuki Pi,Pj, oznaczone przez Ai,j reprezentują fakt, że proces Pi wysłał już żądanie REQUEST do Pj, lecz nie otrzymał jeszcze potwierdzenia GRANT, ani też nie wysłał unieważnienia CANCEL. W tym kontekście, zbiór 𝒪𝒰𝒯i={Pj:Pi,Pj𝒜} jest więc zbiorem warunkującym 𝒟i procesu Pi.

Niech ponadto 𝒩i będzie zbiorem procesów Pj, od których Pi odebrał wiadomość REQUEST, lecz ani nie wysłał jeszcze w odpowiedzi potwierdzenia GRANT, ani też nie otrzymał od Pj unieważnienia CANCEL. Zauważmy teraz, że w środowisku z komunikacją natychmiastową, każda wiadomość REQUEST, GRANT czy CANCEL jest od razu odebrana, a więc 𝒩i={Pj:Pi,Pj𝒜}, a ponadto Pi𝒪𝒰𝒯j wtedy i tylko wtedy, gdy Pj𝒩i.

Przedstawimy teraz algorytm detekcji zakleszczenia dla danego grafu oczekiwanych potwierdzeń WFG=𝒫,𝒜. Algorytm rozpoczyna inicjator Qα, którego proces aplikacyjny jest pasywny, a więc potencjalnie zakleszczony. Dla uproszczenia prezentacji założymy, że w danym czasie wykonywany jest co najwyżej jeden proces detekcji i taki właśnie pojedynczy proces będziemy dalej rozważać. Algorytm detekcji składa się z dwóch faz: powiadamiania i potwierdzania. W fazie powiadamiania (ang. notify) wszystkie monitory są informowane o rozpoczęciu detekcji, natomiast w fazie potwierdzania (ang. confirm) monitor każdego procesu aktywnego, lub potencjalnie aktywnego, symuluje wysłanie potwierdzenia typu GRANT.

Przyjęto przy tym, że faza potwierdzania jest zagnieżdżona w fazie powiadamiania. W efekcie, faza powiadamiania kończy się dopiero po zakończeniu fazy potwierdzania.

Wykorzystywane są cztery typy komunikatów będących sygnałami. Są to typy: NOTIFY, DONE, CONFIRM i ACK.

<< Poprzedni slajd | Spis treści | Następny slajd >>