Plik główny bankier

Transkrypt

Plik główny bankier
Zbigniew S. Szewczak
Podstawy Systemów
Operacyjnych
Wykład 8
Impas.
Toruń, 2003
Impas
☛Problem impasu
☛Model systemu
☛Charakterystyka impasu
☛Metody postępowania z impasem
☛Zapobieganie impasom
☛Unikanie impasu
☛Wykrywanie impasów
☛Likwidowanie impasów
☛Mieszane metody postępowania z impasem
Problem impasu
☛Kilka procesów blokuje jakiś zasób i czeka na
otrzymanie innego zasobu blokowanego przez
jakiś proces z tego zbioru
☛Efekt - może się zdarzyć, że oczekujące procesy
nigdy już nie odmienią swego stanu, ponieważ
zamawiane przez nie zasoby są przetrzymywane
przez inne procesy
☛Nastąpił impas, zakleszczenie (ang. deadlock)
Problem impasu (c.d.)
☛ Przykład 1
☛system ma trzy przewijaki taśmowe
☛procesy P1 , P2 i P3 przetrzymują po jednym przewijaku i
żądają któregoś z dwu pozostałych
☛Przykład 2
☛proces pierwszy pisze na drukarkę (D), drugi na taśmę (T)
jednocześnie proces pierwszy żąda taśmy a drugi drukarki
P1
P2
write(D);
write(T)
open(T);
open(D)
Przykład
typedef int semaphore;
sempahore resource_1;
sempahore resource_2;
void process_A(void) {
down(&resource_1);
down(&resource_2);
use_both_resources();
up(&resource_2);
up(&resource_1);
}
void process_B(void) {
down(&resource_1);
down(&resource_2);
use_both_resources();
up(&resource_2);
up(&resource_1);
}
# kod bez impasu
typedef int semaphore;
sempahore resource_1;
sempahore resource_2;
void process_A(void) {
down(&resource_1);
down(&resource_2);
use_both_resources();
up(&resource_2);
up(&resource_1);
}
void process_B(void) {
down(&resource_2);
down(&resource_1);
use_both_resources();
up(&resource_1);
up(&resource_2);
}
# kod z impasem
Model systemu
☛Rodzaje (typy) zasobów R1, R2, . . ., Rm
cykle procesora, obszar pamięci, urządzenia we/wy
☛Każdy typ zasobu Ri ma Wi egzemplarzy
☛Każdy proces wykorzystuje zasób w
następującym porządku
☛zamówienie (ang. request)
☛użycie (ang. use)
☛zwolnienie (ang. release)
Model systemu (c.d.)
☛Zasoby można zamawiać i zwalniać za pomocą
funkcji systemowych (urządzenia, pliki, pamięć)
lub semaforowych operacji czekaj i sygnalizuj
☛Def. Zbiór procesów jest w stanie impasu, gdy
każdy proces z tego zbioru czeka na zdarzenie,
które może być spowodowane tylko przez inny
proces z tego samego zbioru
☛zasoby fizyczne: drukarki, taśmy, pamięć, cykle procesora
☛zasoby logiczne: pliki, semafory, monitory
Charakterystka impasów
☛Do impasów może dochodzić wtedy, kiedy w
systemie zachodzą jednocześnie cztery warunki
☛wzajemne wykluczanie (ang. mutual exclusion)
☛przetrzymywanie i oczekiwanie (ang. hold and wait)
☛brak wywłaszczeń (ang. no preemption)
☛czekanie cykliczne (ang. circular wait)
Charakterystyka impasów (c.d.)
☛Wzajemne wykluczanie zajdzie wtedy gdy
przynajmniej jeden zasób jest niepodzielny;
zasobu w danym czasie może używać tylko
jeden proces
☛Przetrzymywanie i oczekiwanie zajdzie wtedy
jeśli istnieje proces, któremu przydzielono co
najmniej jeden zasób i który oczekuje na
przydział dodatkowego zasobu,
przetrzymywanego przez inny proces
Charakterystyka impasów (c.d.)
☛Brak wywłaszczeń zajdzie wtedy gdy zasób
może zostać zwolniony jedynie z inicjatywy
przetrzymującego go procesu (np. po
zakończeniu)
☛Czekanie cykliczne zajdzie wtedy jeśli istnieje
zbiór czekających procesów { P0, P1 …, Pn },
takich że proces P0 czeka na zasób trzymany
przez proces P1, proces P1 czeka na zasób
trzymany przez proces P2, …, proces Pn–1 czeka
na zasób trzymany przez proces Pn, oraz proces
Pn czeka na zasób trzymany przez proces P0
Graf przydziału zasobów
☛Graf przydziału zasobów (ang. system resourceallocation graph) to zbiór wierzchołków V i
krawędzi E
☛V jest podzielony na dwa rodzaje węzłów
☛P = {P1, P2, …, Pn}, zbiór wszystkich procesów systemu
☛R = {R1, R2, …, Rm}, zbiór wszystkich typów zasobów w
systemie
☛krawędź
krawędź
☛krawędź
krawędź
zamówienia (ang. request edge) –
skierowana Pi → Rj
przydziału (ang. assignment edge) –
skierowana Rj → Pi
Graf przydziału zasobów (c.d.)
☛Proces
☛Typ zasobu o czterech egzemplarzach
☛Pi żąda egzemplarza zasobu Rj
Pi
Pi → Rj
R
☛Pi trzyma egzemplarz zasobu Rj
Rj → Pi
j
Pi
Rj
Graf przydziału zasobów (c.d.)
☛Można wykazać, że jeśli graf przydziału zasobów
nie zawiera cykli to nie ma impasu
☛Jeśli zasób każdego typu ma tylko jeden
egzemplarz to istnienie cyklu w grafie jest
warunkiem koniecznym i dostatecznym do
wystąpienia impasu
☛Jeśli istnieje po kilka egzemplarzy każdego typu
to istnienie cyklu w grafie jest jedynie
warunkiem koniecznym do wystąpienia impasu
Graf przydziału zasobów (c.d.)
Graf przydziału zasobów z
impasem (2 cykle minimalne)
Graf przydziału zasobów z
cyklem i bez impasu
Podstawowe wnioski
☛Jeśli graf przydziału zasobów nie zawiera cyklu
to system nie jest w stanie impasu
☛Jeśli graf przydziału zasobów ma cykl to
☛impas - jeśli jest to jedyny egzemplarz zasobu
☛zagrożenie impasem systemu - jeśli istnieje kilka
egzemplarzy zasobu
Metody postępowania z
impasami
☛Stosowanie protokołu gwarantującego, że
system nigdy nie wejdzie w stan impasu
☛Pozwala się systemowi na impas, po czym
podejmuje się działania w celu jego usunięcia
☛Zlekceważenie problemu i założenie, że stan
impasu nigdy się nie pojawi w systemie
☛większość systemów operacyjnych w tym system UNIX
Metody postępowania z
impasami (c.d.)
☛Zapobieganie impasom (ang. deadlock
prevention) - zbiór metod zapewniających, że co
najmniej jeden z warunków koniecznych do
wystąpienia impasu nie będzie spełniony
☛Unikanie impasu (ang. deadlock avoidance) zapewnienie aby system zawczasu dysponował
dodatkowymi informacjami o zasobach
wykorzystywanych przez proces
Zapobieganie impasom
☛Zapewnić, aby nie mógł wystąpić przynajmniej
jeden z czterech warunków koniecznych:
☛Wzajemne wykluczanie - dotyczy jedynie
zasobów niepodzielnych (np. drukarek); nie
można zaprzeczyć temu warunkowi bowiem
niektóre zasoby są z natury niepodzielne
Zapobieganie impasom (c.d.)
☛Przetrzymywanie i oczekiwanie - aby zapewnić,
że warunek ten nigdy nie wystąpi w systemie
trzeba zagwarantować, że gdy proces zamawia
zasób to nie powinien trzymać innych zasobów
☛każdy proces zamawia i otrzymuje wszystkie swoje zasoby
przed rozpoczęciem działania (np. najpierw wywołania
systemowe dotyczące zasobów, potem pozostałe)
☛proces może zamówić zasób o ile nie ma żadnych zasobów
☛zanim proces zamówi zasób musi wpierw wszystkie oddać
☛wady: słabe wykorzystanie zasobów, możliwość głodzenia
Zapobieganie impasom (c.d.)
☛Brak wywłaszczeń - trzeba zapewnić, że zasoby
nie ulegają wywłaszczeniu jedynie z inicjatywy
przetrzymującego je procesu
☛jeśli proces żąda zasobu i nie może go otrzymać to traci
wszystkie swoje zasoby i czeka na nie
☛jeśli proces zamawia jakieś zasoby to się sprawdza czy są
one dostępne
☛jeśli są dostępne to się je przydziela
☛jeśli są trzymane przez proces, który sam czeka na jakiś
zasób to się mu zasoby odbiera i przydziela zamawiającemu
☛w przeciwnym razie proces czeka i może utracić zasoby
Zapobieganie impasom (c.d.)
☛Czekanie cykliczne - sposobem aby warunek ten
nigdy nie wystąpił w systemie jest
przyporządkowanie wszystkim zasobom danego
typu kolejnych liczb i żądanie, aby
☛każdy proces zamawiał zasoby we wzrastającym porządku
numeracji
☛alternatywnie można wymagać aby proces zamawiający zasób
miał zawsze zwolnione zasoby o numeracji wyższej od
zamawianego
☛Porządek używania zasobów: np. taśmy - 3,
drukarki - 4
Unikanie impasu
☛Wymaga dodatkowej informacji o tym jak
będzie następowało zamawianie zasobów
☛W najprostszym i najbardziej użytecznym
modelu zakłada się, że system zadeklaruje
maksymalną liczbę zasobów każdego typu, którą
mógłby potrzebować
☛Algorytm unikania impasu (ang. deadlockavoidance) sprawdza dynamicznie stan
przydziału zasobów aby zapewnić, że nigdy nie
dojdzie do spełnienia warunku czekania
cyklicznego
Unikanie impasu (c.d.)
☛Stan przydziału zasobów (ang. resourceallocation state) jest określony przez liczbę
dostępnych (ang. available) i przydzielonych
(ang. allocated) zasobów oraz przez
maksymalne zapotrzebowanie procesów
Stan bezpieczny
☛Kiedy proces żąda wolnego zasobu system musi
zadecydować czy przydzielenie zasobu
pozostawi system w stanie bezpiecznym
☛System jest w stanie bezpiecznym (ang. safe)
jeśli istnieje taki porządek przydzielania zasobów
każdemu procesowi, który pozwala na uniknięcie
impasu
☛System jest w stanie bezpiecznym jeśli istnieje
bezpieczny ciąg procesów
☛System jest w stanie zagrożenia (ang. unsafe)
jeśli nie jest w stanie bezpiecznym
Stan bezpieczny (c.d.)
☛Ciąg procesów <P1, P2, …, Pn> jest bezpieczny
jeśli dla każdego procesu Pi , jego potencjalne
zapotrzebowanie na zasoby może być
zaspokojone przez bieżąco dostępne zasoby +
zasoby użytkowane przez wszystkie procesy Pj ,
przy czym j<i
☛jeśli Pi żąda zasobów, które nie są natychmiast dostępne,
to Pi może poczekać aż skończą się wszystkie procesy Pj
☛jeśli Pj skończą, Pi może otrzymać wszystkie potrzebne
zasoby, dokończyć pracę, zwolnić zasoby i zakończyć
☛jeśli Pi zakończy, Pi+1 może otrzymać niezbędne zasoby
itd.
Podstawowe fakty
☛Jeśli system jest w stanie bezpiecznym to nie
ma impasu
☛Jeśli system jest w stanie zagrożenia istnieje
możliwość impasu
☛Unikanie impasu to zapewnienie, że system
nigdy nie wejdzie w stan zagrożenia
Obszary stanów: bezpiecznego,
zagrożenia i impasu
impas
Stan zagrożenia
Stan bezpieczny
Przykład: stan bezpieczny i stan
zagrożenia
☛Procesy P, Q, R - 12 przewijaków taśm
☛P - (10,5) ; Q - (4,2); R - (9,2) : pierwsza
współrzędna oznacza maksymalne
zapotrzebowanie, druga bieżące wymagania
☛(Q, P, R) - ciąg bezpieczny
☛P - (10,5) ; Q - (4,2); R - (9,3)
☛(Q, P, R) - stan zagrożenia bo gdy Q skończy to są wolne
tylko 4 przewijaki taśm a P wymaga 5 zaś R może
zażądać 6
☛proces R musi czekać aż skończy P lub Q i odda zasoby
Algorytm grafu przydziału
zasobów - 1 egzemplarz zasobu
☛Krawędź deklaracji (ang. claim edge) Pi → Rj
oznacza, że proces Pi może zażądać zasobu Rj
w przyszłości; oznaczamy ją linią przerywaną
☛Krawędź deklaracji zmienia się w krawędź
zamówień (linia ciągła) w chwili gdy proces Pi
zamawia zasób Rj
☛Kiedy proces Pi zwalnia zasób Rj krawędź
zamówień jest zmieniana z powrotem na
krawędź deklaracji
☛Wszystkie krawędzie deklaracji muszą być znane
a priori zanim proces rozpocznie
Algorytm grafu przydziału
zasobów - (c.d.)
☛Proces Pi żąda zasobu Rk
☛Żądanie może być zrealizowane gdy zamiana
krawędzi zamówienia Pi → Rk na krawędź
przydziału Rk → Pi nie spowoduje utworzenia
cyklu w grafie
☛Liczba operacji wykrywania cykli w grafie jest
kwadratem całkowitej liczby procesów w
systemie
Algorytm przydziału zasobów wiele egzemplarzy zasobu
☛Algorytm bankiera (ang. banker’s algorithm)
☛Każdy proces gdy wchodzi do systemu musi
zadeklarować maksymalną liczbę używanych
egzemplarzy każdego typu zasobu, liczba ta nie
może przekroczyć ogólnej liczby zasobów
☛Jeśli proces zażąda zasobu może się okazać, że
musi poczekać
☛Jeśli proces uzyska potrzebne do działania
zasoby to musi je zwrócić w skończonym czasie
Struktury danych w algorytmie
bankiera
☛n - liczba procesów w systemie; m - liczba
typów zasobów
☛Dostępne (ang. Available) : wektor długości m.
Jeśli Available[j] = k, to jest k egzemplarzy
zasobu typu Rj dostępnych w systemie
☛Maksymalne (Max) : macierz n x m. Jeśli
Max[i,j] = k, to proces Pi może zażądać co
najwyżej k egzemplarzy zasobu typu Rj.
Struktury danych w algorytmie
bankiera (c.d.)
☛Przydzielone (ang. Allocation) : macierz n x m.
Jeśli Allocated[i,j] = k to proces Pi ma
przydzielonych k egzemplarzy zasobu o typie Rj.
☛Potrzebne (ang. Need): macierz n x m. Jeśli
Need[i,j] = k, to proces Pi może jeszcze
potrzebować k dodatkowych egzemplarzy
zasobu typu Rj aby zakończyć
Need[i,j] = Max[i,j] – Allocation[i,j].
Algorytm bezpieczeństwa
1. Niech Work i Finish będą wektorami długości m i n,
odpowiednio. Przypiszmy
Work := Available
Finish [i] = false for i = 1,2,3, …, n.
2. Znajdujemy i takie, że zarówno
(a) Finish [i] = false
(b) Needi ≤ Work
w przeciwnym razie wykonujemy krok 4
3. Work := Work + Allocationi
Finish[i] := true
goto 2.
4. Jeśli Finish [i] = true dla i<n+1, to stan bezpieczny
Algorytm zamawiania zasobów
przez proces Pi
Requesti = wektor żądań Pi. Jeśli Requesti [j] = k
to Pi chce k egzemplarzy zasobu typu Rj.
1. Jeśli Requesti ≤ Needi goto 2. W przeciwnym razie błąd
2. Jeśli Requesti ≤ Available, goto 3. W przeciwnym razie Pi
czeka
3. System próbuje zaalokować zasoby Pi modyfikując stan
Available := Available - Requesti ;
Allocationi := Allocationi + Requesti ;
Needi := Needi – Requesti
• Jeśli stan safe ⇒ alokuj zasoby do Pi .
• Jeśli stan unsafe ⇒ Pi musi czekać na realizację i poprzedni
stan przydziału zasobów jest odtwarzany
Przykładowa ilustracja
algorytmu bankiera
☛5 procesów: P0 do P4; 3 zasoby typu A (10 egz.),
B (5 egz.), i C (7 egz.)
☛Stan migawkowy w chwili T0:
P0
P1
P2
P3
P4
Allocation
ABC
010
200
302
211
002
Max Available
ABC ABC
753 332
322
902
222
433
Przykładowa ilustracja
algorytmu bankiera (c.d.)
☛Zawartość macierzy Need = Max - Allocated
P0
P1
P2
P3
P4
Need
ABC
743
122
600
011
431
Przykładowa ilustracja
algorytmu bankiera (c.d.)
☛
☛
☛
☛
☛
☛
☛
Available :=[3,3,2];
Work :=[3,3,2]; Finish =[0,0,0,0,0]; Need2=[1,2,2]; Alloc2=[2,0,0];
Work :=[5,3,2]; Finish =[0,1,0,0,0]; Need4=[0,1,1]; Alloc4=[2,1,1];
Work :=[7,4,3]; Finish =[0,1,0,1,0]; Need5=[4,3,1]; Alloc5=[0,0,2];
Work :=[7,4,5]; Finish =[0,1,0,1,1]; Need3=[6,0,0]; Alloc3=[3,0,2];
Work :=[10,4,7]; Finish =[0,1,1,1,1]; Need1=[7,4,3]; Alloc1=[0,1,0];
Work :=[10,5,7]; Finish =[1,1,1,1,1];
☛Wn. System jest w stanie safe bo ciąg < P1, P3, P4,
P2, P0> spełnia kryterium bezpieczeństwa
Przykładowa ilustracja (c.d.) :
P1 żąda (1,0,2) (c.d.)
☛Sprawdź czy Request[1] ≤ Available, tzn. czy
(1,0,2) ≤ (3,3,2) ⇒ true.
P0
P1
P2
P3
P4
Allocation
ABC
010
302
301
211
002
Need Available
ABC ABC
743
230
020
600
011
431
Przykładowa ilustracja (c.d.) :
P1 żąda (1,0,2) (c.d.)
☛
☛
☛
☛
☛
☛
☛
☛
☛
Request1=[1,0,2] ≤ Need1 = [7,4,3];
Request1 ≤ Available = [3,3,2];
Available := [3,3,2] - [1,0,2] = [2,3,0];
Work :=[2,3,0]; Finish =[0,0,0,0,0]; Need2=[0,2,0]; Alloc2=[3,0,2];
Work :=[5,3,2]; Finish =[0,1,0,0,0]; Need4=[0,1,1]; Alloc4=[2,1,1];
Work :=[7,4,3]; Finish =[0,1,0,1,0]; Need5=[4,3,1]; Alloc5=[0,0,2];
Work :=[7,4,5]; Finish =[0,1,0,1,1]; Need1=[7,4,3]; Alloc1=[0,1,0];
Work :=[7,5,5]; Finish =[1,1,0,1,1]; Need3=[6,0,0]; Alloc3=[3,0,2];
Work :=[10,5,7]; Finish =[1,1,1,1,1];
☛Wn. System jest w stanie safe bo ciąg < P1, P3, P4,
P0, P2> spełnia kryterium bezpieczeństwa
Przykładowa ilustracja (c.d.) :
P1 żąda (1,0,2) (c.d.)
☛Sprawdzamy, że w obecnym stanie systemu
☛zamówienie na (3,3,0) przez P4 nie może zostać wykonane z
powodu niedostępności zasobu
☛ Available := [2,3,0]; Request4=[3,3,0]
☛zamówienie na (0,2,0) przez P0 nie może zostać spełnione
bowiem system wejdzie w stan zagrożenia
☛
☛
☛
☛
☛
☛
☛
Request1=[0,2,0] ≤ Need1 = [7,4,3];
Request1 ≤ Available = [3,3,2];
Available := [3,3,2] - [0,2,0] = [2,1,0];
Work :=[2,1,0]; Finish =[0,0,0,0,0]; Need4=[0,1,1]; Alloc2=[2,1,1];
Work :=[4,2,1]; Finish =[0,0,0,1,0]; Need2=[0,2,0]; Alloc2=[3,0,2];
Work :=[7,2,3]; Finish =[0,1,0,1,0]; Need3=[6,0,0]; Alloc3=[3,0,1];
Work :=[10,2,4]; Finish =[0,1,0,1,1]; Need1=[7,4,3]; Need5=[4,3,1];
Wykrywanie impasu
☛W systemie, w którym nie stosuje się algorytmu
zapobiegania impasom ani ich unikania może
wystąpić impas
☛Należy umożliwić systemowi wejście w impas
☛Algorytm wykrywania impasu
☛Algorytm likwidowania impasu
Typy zasobów reprezentowane
pojedyńczo
☛Tworzymy graf oczekiwania (ang. wait-for
graph)
☛węzły grafu są procesami
☛Pi → Pj gdy Pi czeka na Pj.
☛Okresowo wykonujemy algorytm szukający
cyklu w grafie oczekiwania
☛Rząd algorytmu wykrywania cykli w grafie
oczekiwania wynosi n2, przy czym n jest liczbą
wierzchołków grafu
Typy zasobów reprezentowane
wielokrotnie
☛Available: wektor długości m oznacza liczbę
dostępnych zasobów każdego typu
☛Allocation: macierz n x m definiuje liczbę
zasobów każdego typu aktualnie zaalokowanych
do każdego z procesów
☛Request: macierz n x m określa bieżące
zamówienie każdego procesu. Jeśli Request [i,j]
= k, to proces Pi zamawia dodatkowo k
egzemplarzy zasobu typu Rj.
Algorytm wykrywania
1. Niech Work i Finish wektory długości m i n,
odpowiednio. Przypiszmy:
(a) Work : =Available
(b) For i = 1,2, …, n, if Allocationi ≠ 0, then
Finish[i] := false;otherwise, Finish[i] := true.
2. Znajdujemy indeks i taki, że jednocześnie:
(a) Finish[i] = false
(b) Requesti ≤ Work
Gdy nie istnieje takie i, goto 4.
Algorytm wykrywania (c.d.)
3. Work := Work + Allocationi
Finish [i ] := true
goto 2.
4. Jeśli Finish[i] = false, dla pewnego i, 1 ≤ i ≤ n,
to system jest w stanie impasu. Co wiecęj, jeśli
Finish [i ] = false, to Pi jest w impasie
☛Rząd liczby operacji tego algorytmu, potrzebny
do wykrycia czy system jest w stanie impasu
wynosi m x n 2
Algorytm wykrywania (c.d.) przykład
☛5 procesów P0 do P4; 3 typy zasobów
A (7 egz.), B (2 egz.), and C (6 egz.)
☛Migawka systemu w chwili T0:
P0
P1
P2
P3
P4
Allocation
ABC
010
200
303
211
002
Request
ABC
000
202
000
100
002
Available
ABC
000
Algorytm wykrywania (c.d.) przykład
☛
☛
☛
☛
☛
☛
☛
Available :=[0,0,0];
Work :=[0,0,0]; Finish =[0,0,0,0,0]; Req1=[0,0,0]; Alloc1=[0,1,0];
Work :=[0,1,0]; Finish =[1,0,0,0,0]; Req3=[0,0,0]; Alloc3=[3,0,3];
Work :=[3,1,3]; Finish =[1,0,1,0,0]; Req4=[1,0,0]; Alloc4=[2,1,1];
Work :=[5,2,4]; Finish =[1,0,1,1,0]; Req5=[0,0,2]; Alloc5=[0,0,2];
Work :=[5,2,6]; Finish =[1,0,1,1,1]; Req2=[2,0,2]; Alloc2=[2,0,0];
Work :=[7,2,6]; Finish =[1,1,1,1,1];
☛Ciąg <P0, P2, P3, P4, P1> da w Finish [i ] = true dla
wszystkich i
☛Algorytm nie jest w stanie impasu
Algorytm wykrywania (c.d.) przykład (c.d.)
☛P2 zamawia dodatkowo egzemplarz typu C.
P0
P1
P2
P3
P4
Request
ABC
000
201
001
100
002
Algorytm wykrywania (c.d.) przykład (c.d.)
☛ Work :=[0,0,0]; Finish =[0,0,0,0,0]; Req1=[0,0,0]; Alloc1=[0,1,0];
☛ Work :=[0,1,0]; Finish =[1,0,0,0,0];
☛ Req2=[2,0,2]; Req3=[0,0,1]; Req4=[1,0,0]; Req5=[0,0,2];
☛Stan systemu?
☛nawet jeśli odbierzemy zasoby przetrzymywane przez
proces P0, to dostępnych zasobów nie wystarczy, aby
spełnić zamówienia innych procesów
☛istnieje zatem zakleszczenie i dotyczy procesów P1, P2, P3,
oraz P4
Użytkowanie algorytmu
wykrywania impasu
☛Kiedy i jak często należy wywoływać algorytm
impasu? Odpowiedź zależy od tego
☛jak często może wystąpić impas
☛ile procesów popadnie w impas w przypadku jego
wystąpienia
☛Jeśli algorytm impasu jest wywoływany losowo
to może występować wiele cykli w grafie
zasobów i w efekcie identyfikacja procesu, który
spowodował impas może być utrudniona
Likwidowanie impasu zaniechanie (abort)
☛Zaniechanie wszystkich zakleszczonych
procesów
☛Usuwanie procesów pojedyńczo, aż do
wyeliminowania cyklu impasu
☛Na kolejność zaniechania ma wpływ
☛priorytet procesu
☛długość czasu wykonania i czas pozostały do zakończenia
☛zasoby i typy potrzebne do zakończenia
☛ilość procesów do przerwania
☛interakcyjność lub wsadowość
Likwidowanie impasu wywłaszczanie
☛Wybór ofiary - minimalizowanie kosztów
☛Wycofanie (ang. rollback) - wycofanie procesu
do bezpiecznego stanu, od którego można go
będzie wznowić
☛Głodzenie - ten sam proces może być zawsze
ofiarą, podobnie jak i ten sam proces może być
ciągle wycofywany. Trzeba zadbać aby proces
mógł być delegowany do roli ofiary tylko
skończoną liczbę razy
Likwidowanie impasu podejście mieszane
☛Podstawowe strategie
☛zapobieganie (ang. prevention)
☛unikanie (ang. avoidance)
☛wykrywanie (ang. detection)
☛Strategie stosowane osobno nie nadają się do
rozwiązywania problemów z przydzielaniem
zasobów
☛Podział wszystkich zasobów na hierachicznie
uporządkowane klasy
☛W obrębie klas dobieramy najodpowiedniejsze
techniki pokonywania impasu
Likwidowanie impasu podejście mieszane (c.d.)
☛System składa się z klas zasobów
☛zasoby wewnętrzne (bloki kontrolne)
☛pamięć główna
☛zasoby zadania (urządzenia, pliki)
☛wymienny obszar pamięci pomocniczej
☛Strategie postępowania z impasami w obrębie
każdej z klas
☛porządkowanie zasobów
☛wywłaszczanie
☛unikanie impasu
☛wstępny przydział
Podsumowanie (1)
☛Impas następuje wtedy, gdy dwa lub więcej
procesów czeka w nieskończoność na zdarzenie,
które może być spowodowane tylko przez jeden
z tych czekających procesów
☛Sposoby likwidowania impasu
☛przestrzeganie protokołu unikania impasu
☛pozwalać na impas i likwidować go
☛ignorować impas (np. UNIX)
Podsumowanie (2)
☛Do impasu dochodzi wtedy i tylko wtedy, gdy
jednocześnie zachodzą warunki
☛wzajemne wykluczanie
☛przetrzymywanie i oczekiwanie
☛brak wywłaszczeń
☛oczekiwanie cykliczne
☛Możemy uniknąć impasu jeśli wiemy o przyszłym
wykorzystaniu zasobów przez procesy
☛algorytm bankiera

Podobne dokumenty