Pr-1st-1.1-m05-Slajd25: 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:
==Model aplikacyjnego przetwarzania rozproszonego==
==Model aplikacyjnego przetwarzania rozproszonego==


[[Image:pr-1st-1.1-m05-Slajd25a.png]]
[[Image:Pr-1st-1.1-m05-Slajd55.png]]
[[Image:pr-1st-1.1-m05-Slajd25b.png]]
[[Image:Pr-1st-1.1-m05-Slajd56.png]]
[[Image:pr-1st-1.1-m05-Slajd25c.png|Model aplikacyjnego przetwarzania rozproszonego]]
[[Image:Pr-1st-1.1-m05-Slajd57.png|Model aplikacyjnego przetwarzania rozproszonego]]


W wielu zaproponowanych dotychczas algorytmach detekcji zakleszczenia przyjmuje się, że procesy aplikacyjne <math>P_i</math> wysyłają jawnie żądanie przydziału zasobów w formie wiadomości typu REQUEST do procesów tworzących zbiór warunkujący <math>\mathcal{D}_i</math> i oczekują w stanie pasywnym na wiadomości typu GRANT potwierdzające przyznanie żądanych zasobów. Gdy do <math>P_i</math> dotrze odpowiedni zbiór wiadomości typu GRANT, proces aplikacyjny staje się aktywny i wysyła wiadomość typu CANCEL, do pozostałych procesów ze zbioru warunkującego (od których nie odebrał GRANT), w celu wycofania (unieważnienia) wcześniej wysłanego żądania. Po wykorzystaniu zasobu, proces aplikacyjny może sygnalizować jego zwolnienie przez wysłanie wiadomości typu RELEASE do procesu zarządzającego przydziałem zasobów.
W wielu zaproponowanych dotychczas algorytmach detekcji zakleszczenia przyjmuje się, że procesy aplikacyjne <math>P_i</math> wysyłają jawnie żądanie przydziału zasobów w formie wiadomości typu REQUEST do procesów tworzących zbiór warunkujący <math>\mathcal{D}_i</math> i oczekują w stanie pasywnym na wiadomości typu GRANT potwierdzające przyznanie żądanych zasobów. Gdy do <math>P_i</math> dotrze odpowiedni zbiór wiadomości typu GRANT, proces aplikacyjny staje się aktywny i wysyła wiadomość typu CANCEL, do pozostałych procesów ze zbioru warunkującego (od których nie odebrał GRANT), w celu wycofania (unieważnienia) wcześniej wysłanego żądania. Po wykorzystaniu zasobu, proces aplikacyjny może sygnalizować jego zwolnienie przez wysłanie wiadomości typu RELEASE do procesu zarządzającego przydziałem zasobów.


Przy takim modelu aplikacyjnego przetwarzania rozproszonego stan globalny może być, jak już wspomniano, reprezentowany przez graf oczekiwanych potwierdzeń WFG (ang. Wait-For-Graph), w którym wierzchołki odpowiadają procesom <math>P_i</math> a łuki <math> \left \langle P_i, P_j \right \rangle</math>reprezentują fakt, że proces <math>P_i</math> wysłał już żądanie do <math>P_j</math>, lecz ani nie otrzymał jeszcze potwierdzenia GRANT, ani też nie wysłał wiadomości typu CANCEL. W tym kontekście zbiór warunkujący <math>\mathcal{D}_i</math> jest więc zbiorem tych wszystkich procesów <math>P_j</math>, do których <math>P_i</math> wysłał żądanie REQUEST i ani nie zaniechał tego żądania (wysyłając następnie wiadomość CANCEL), ani też nie otrzymał potwierdzenia GRANT.
Przy takim modelu aplikacyjnego przetwarzania rozproszonego stan globalny może być, jak już wspomniano, reprezentowany przez graf oczekiwanych potwierdzeń WFG (ang. Wait-For-Graph), w którym wierzchołki odpowiadają procesom <math>P_i</math> a łuki <math> \left \langle P_i, P_j \right \rangle</math> reprezentują fakt, że proces <math>P_i</math> wysłał już żądanie do <math>P_j</math>, lecz ani nie otrzymał jeszcze potwierdzenia GRANT, ani też nie wysłał wiadomości typu CANCEL. W tym kontekście zbiór warunkujący <math>\mathcal{D}_i</math> jest więc zbiorem tych wszystkich procesów <math>P_j</math>, do których <math>P_i</math> wysłał żądanie REQUEST i ani nie zaniechał tego żądania (wysyłając następnie wiadomość CANCEL), ani też nie otrzymał potwierdzenia GRANT.


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

Wersja z 15:54, 7 wrz 2006

Model aplikacyjnego przetwarzania rozproszonego

Model aplikacyjnego przetwarzania rozproszonego

W wielu zaproponowanych dotychczas algorytmach detekcji zakleszczenia przyjmuje się, że procesy aplikacyjne Pi wysyłają jawnie żądanie przydziału zasobów w formie wiadomości typu REQUEST do procesów tworzących zbiór warunkujący 𝒟i i oczekują w stanie pasywnym na wiadomości typu GRANT potwierdzające przyznanie żądanych zasobów. Gdy do Pi dotrze odpowiedni zbiór wiadomości typu GRANT, proces aplikacyjny staje się aktywny i wysyła wiadomość typu CANCEL, do pozostałych procesów ze zbioru warunkującego (od których nie odebrał GRANT), w celu wycofania (unieważnienia) wcześniej wysłanego żądania. Po wykorzystaniu zasobu, proces aplikacyjny może sygnalizować jego zwolnienie przez wysłanie wiadomości typu RELEASE do procesu zarządzającego przydziałem zasobów.

Przy takim modelu aplikacyjnego przetwarzania rozproszonego stan globalny może być, jak już wspomniano, reprezentowany przez graf oczekiwanych potwierdzeń WFG (ang. Wait-For-Graph), w którym wierzchołki odpowiadają procesom Pi a łuki Pi,Pj reprezentują fakt, że proces Pi wysłał już żądanie do Pj, lecz ani nie otrzymał jeszcze potwierdzenia GRANT, ani też nie wysłał wiadomości typu CANCEL. W tym kontekście zbiór warunkujący 𝒟i jest więc zbiorem tych wszystkich procesów Pj, do których Pi wysłał żądanie REQUEST i ani nie zaniechał tego żądania (wysyłając następnie wiadomość CANCEL), ani też nie otrzymał potwierdzenia GRANT.

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