SYSTEMY OPERACYJNE SYNCHRONIZACJA PROCESÓW

SYSTEMY OPERACYJNE SYNCHRONIZACJA PROCESÓW

SYNCHRONIZACJA PROCESÓW
Współbieżność Głównym problemem SO jest zarządzanie procesami i wątkami, a w szczególności: przetwarzanie wieloprogramowe – zarządzanie kilkoma procesami w systemie jednoprocesorowym; przetwarzanie wieloprocesorowe – zarządzanie licznymi procesami w środowisku wieloprocesorowym; przetwarzanie rozproszone – zarządzanie wieloma procesami na rozproszonych systemach komputerowych. Kluczem do prawidłowego zarządzania procesami w ww. problemach jest współbieżność. Zapewnienie współbieżności wymaga rozwiązania m.in.: komunikacji między procesami, współużytkowania i rywalizacji o zasoby, synchronizacji procesów i przydziału procesora. Podstawowym warunkiem przetwarzania współbieżnego jest zdolność wymuszania wzajemnych wykluczeń, czyli blokowania innych procesów, podczas działania procesu, któremu na to zezwolono.

Współbieżność – podstawowe problemy Problemy współbieżności: współużytkowanie zasobów globalnych – dwa procesy zapisują i odczytują tę samą zmienną globalną; decydujące znaczenie ma kolejność operacji; trudne zarządzanie przydzielaniem zasobów – po przydzieleniu procesowi zasobu, zostaje on zawieszony; zasób zablokowany  zakleszczenie; niepowtarzalność i niedeterministyczne wyniki programów utrudniają lokalizację błędów programowania; Współdzielenie pamięci zwiększa jednak wydajność przetwarzania i ułatwia współdziałanie, może jednak stwarzać pewne problemy, np. procedura: void echo () char_in = get_char (); char_out = char_in; put_char (char_out);

Wymagania od SO wynikające z konieczności zapewnienia współbieżności: zdolność przechowywania informacji o działaniu licznych procesów; możliwość przydzielania i odbierania zasobów (czas procesora, pamięć, pliki, urządzenia we/wy) wszystkim procesom; możliwość ochrony danych i fizycznych zasobów każdego procesu przed niezamierzonym działaniem innych procesów; wynik działania procesu nie może zależeć od stosunku prędkości, z jaką przebiega, do szybkości działania innych procesów.

Oddziaływania między procesami procesy niezależne od siebie – SO musi sterować dostępem do zasobów; procesy zależne pośrednio – nie są zależne bezpośrednio, ale łączy je wspólny dostęp do pewnych obiektów; procesy zależne od siebie bezpośrednio – wspólnie wykonują pewne działania, współpracują ze sobą; ad a): relacje: rywalizacja; wzajemny wpływ: wyniki nie zależą od działań innych procesów; problemy sterowania: wzajemne wykluczanie, blokowanie, zagłodzenie; ad b): relacje: współpraca, wspólne wykorzystywanie obiektów; wzajemny wpływ: wyniki mogą zależeć od informacji od innych procesów; możliwy wpływ na tempo procesu; problemy sterowania: wzajemne wykluczanie, blokowanie (zasoby wymienne), zagłodzenie, zachowanie spójności danych;

Oddziaływania między procesami ad c): relacje: współpraca poprzez komunikację; wzajemny wpływ: wyniki mogą zależeć od informacji od innych procesów; możliwy wpływ na tempo procesu; problemy sterowania: blokowanie (zasoby wymienne), zagłodzenia.

Współbieżność – wzajemne wykluczanie i synchronizacja.

Synchronizacja i obszary krytyczne. Jak zapewnić prawidłowy dostęp procesów do zasobów niepodzielnych, tj. zasobów, z których może korzystać tylko jeden proces? Problem synchronizacji dotyczy tylko procesów współpracujących z algorytmem pełnego wywłaszczania.

PROCESY - ZASOBY Zasoby niepodzielne: większość urządzeń zewnętrznych,
pliki zapisywalne, obszary danych, które ulegają zmianom; Zasoby podzielne: jednostki centralne, pliki tylko do czytania, obszary pamięci, gdzie znajdują się (dzielone) biblioteki, kody programów.

WYŚCIG I SEKCJA KRYTYCZNA
Sytuacje, w których dwa (lub więcej) procesy czytają i modyfikują pewne dzielone dane i rezultat końcowy zależy od tego kiedy każdy z tych procesów będzie je czytał / modyfikował, nazywamy wyścigiem lub sytuacją hazardową (race condition). Część programu, w której następuje czytanie / modyfikowanie dzielonych danych, nazywa się sekcją krytyczną (critical section). Część programu, w której są wykonywane operacje nieistotne z punktu widzenia innych procesów (nie wymagające wyłączności na współdzielonych zasobach) nazywa się sekcją lokalną.

WYŚCIG I SEKCJA KRYTYCZNA
Interpretacja przetwarzania współbieżnego dla pojedynczego CPU: proces rozpoczyna się przed zakończeniem poprzedniego. możliwy konflikt przy operacjach na danych dzielonych (np. nawet instrukcja x:=x+1 to instrukcje: mov AX,x; inc AX; mov x,AX procesora). Wniosek: każdy z procesów ma (może mieć) segment kodu nazywany sekcją krytyczną (SK). Sekcje krytyczne procesów podlegają wzajemnemu wykluczaniu się w czasie.

Problem synchronizacji dotyczy współpracujących ze sobą procesów współbieżnych. Przyczyny konieczności synchronizacji procesów: Pojedyncze operacje muszą być "zatomizowane", tzn. tylko jeden proces może na raz modyfikować współdzieloną strukturę danych – problem sekcji krytycznej. 2. Wyniki działania jednego procesu stanowią dane dla drugiego procesu, ale dopiero po obliczeniu ich przez pierwszy proces – problem producenta i konsumenta 3. Procesy korzystają z pewnej wspólnej puli zasobów, które pobierają i zwalniają wedle potrzeb; oczekiwanie na zasoby i przydzielanie ich wymaga również synchronizacji między procesami– problem 5 filozofów.

Problem producenta i konsumenta. 2 typy procesów: Producenci – wykonując procedurę Produkuj, tworzą elementy danych, które są potem wysłane do konsumentów. Konsumenci – po otrzymaniu danych, wykonują obliczenia w wewnętrznej procedurze Konsumuj. Np. program użytkowy „produkuje” zestawienie, „konsumowane” przez drukarkę. Uogólnienie do wielu producentów i wielu konsumentów. Licznik zdarzeń in – pozycje umieszczone przez producenta w buforze; out – pozycje pobrane przez konsumenta. Producent sprawdza, czy jest miejsce w buforze (Await); jeśli producent wygeneruje pozycje do bufora i out = 0, to funkcja Await go zablokuje do czasu, aż out będzie = co najmniej 1 (konsument usunął z bufora co najmniej 1 pozycję).

Problem producenta i konsumenta. Procesy producenta i konsumenta mają podobny schemat: producent: · repeat · wyprodukuj jednostkę produktu; · wstaw wyprodukowaną jednostkę do bufora; · until false konsument: · pobierz z bufora jednostkę produktu; · skonsumuj pobraną jednostkę;

Problem producenta i konsumenta cd. Bufor może być zrealizowany następująco: var bufor: array [0..n-1] of produkt; pierwszy: 0..n-1; licznik: 0..n; Na początku – zmienna pierwszy – dowolna, licznik = 0;

Problem producenta i konsumenta cd. Implementacja wstawiania i pobierania jednostek: - producent: repeat wyprodukuj jednostkę produktu; while licznik = n do; bufor [(pierwszy+licznik) mod n] := wyprodukowana jedn.; licznik := licznik + 1 until false - konsument: repeat while licznik = 0 do; pobrana jednostka := bufor [pierwszy]; pierwszy := (pierwszy + 1) mod n; licznik := licznik – 1; skonsumuj pobraną jednostkę

Problem producenta i konsumenta cd. Procesy wyglądają sensownie, ale uruchomione współbieżnie mogą działać niepoprawnie, gdyż instrukcje: licznik := licznik + 1 oraz licznik := licznik - 1 mogą po przeplocie dawać różne wyniki. Np. przy realizacji w języku maszynowym rejestr1 := licznik; oraz rejestr2 := licznik; rejestr1 := rejestr1 + 1; rejestr2 := rejestr2 - 1; licznik := rejestr licznik := rejestr2 Załóżmy, że licznik = 3 (w buforze są 3 jednostki produktu). Wkładamy i pobieramy współbieżnie po jednej jednostce do/z bufora. Stan nie powinien ulec zmianie; ale przy przeplocie jak niżej: rejestr1 := licznik; 3 rejestr2 := licznik; 3 rejestr2 := rejestr2 - 1; 2 licznik := rejestr2 2 rejestr1 := rejestr1 + 1; 4 licznik := rejestr1 4

Problem pięciu filozofów 5 filozofów dzieli okrągły stół, wokół stołu jest 5 krzeseł, na środku stołu jest miska ryżu, a przed każdym filozofem talerz; pomiędzy 2 talerzami leży 1 pałeczka. Kiedy filozof myśli, nie chce jeść. Kiedy odczuwa głód, próbuje ująć w dłonie dwie pałeczki leżące najbliżej niego (po lewej i po prawej stronie). Jednorazowo może podnieść tylko jedną pałeczkę. Kiedy głodny filozof zdobędzie 2 pałeczki, rozpoczyna jedzenie. Po posiłku, odkłada pałeczki na stół i zatapia się ponownie w rozmyślaniach.

Problem pięciu filozofów Problem: zsynchronizować poczynania filozofów, aby wykluczyć możliwość blokady i zagłodzenia. Jeżeli wszyscy filozofowie biorą po jednej pałeczce, dochodzi do blokady; jeżeli niektórzy wezmą 2 pałeczki – dojdzie do zagłodzenia innych.

Problem sekcji krytycznej Sekcja krytyczna (SK) nie może być wykonywana współbieżnie. Dodatkowy kod synchronizujący przebywanie procesów wejściowych - przed wejściem do SK każdy proces musi przejść przez sekcję wejściową, - wychodząc przechodzi przez sekcję wyjściową. Dopóki jakiś proces przebywający w SK nie opuści jej, inne procesy chcące wejść do SK są wstrzymywane w sekcji wejściowej. Przechodząc przez sekcję wyjściową, proces opuszczający SK wpuszcza jeden z procesów oczekujących (jeśli takowe są). Zakłada się, że każdy proces wchodzący do SK kiedyś ją opuści.

Problem sekcji krytycznej cd. Podstawowa własność SK – wzajemne wykluczanie: tylko jeden proces naraz może przebywać w SK. Druga własność – jeżeli jakiś proces chce wejść do SK, to nie może ona pozostawać pusta. Nie ma planowania wejścia do SK, ale zakłada się, że nie może dojść do zagłodzenia procesów – każdy proces, który chce wejść do SK, ma gwarancje, że do niej wejdzie.

Warunki stosowania technik wykluczania: Żadne dwa procesy nie mogą przebywać jednocześnie w swojej sekcji krytycznej. Nie można czynić żadnych założeń, co do szybkości wykonywania procesów oraz ich liczby. Żaden z procesów wykonujący działanie poza sekcją krytyczną nie może blokować innych procesów. Żaden proces nie może czekać w nieskończoność na wejście do swojej sekcji krytycznej.

Problem sekcji krytycznej cd. Implementacja problemu producenta i konsumenta: producent: repeat wyprodukuj jednostkę produktu; while licznik = n do; sekcja wejściowa; bufor [(pierwszy+licznik) mod n] := wyprodukowana jednostka; licznik := licznik + 1; sekcja wyjściowa until false konsument: while licznik = 0 do; pobrana jednostka := bufor [pierwszy]; pierwszy := (pierwszy + 1) mod n; licznik := licznik - 1; sekcja wyjściowa; skonsumuj pobraną jednostkę

Problem sekcji krytycznej - algorytm Dekkera Jest to implementacja sekcji krytycznej dla dwóch procesów korzystająca ze zmiennych współdzielonych przez te procesy. Algorytm ten wykorzystuje trzy zmienne: var k: array [1..2] of 0..1; czyja_kolej: 1..2; Początkowo komórki tablicy k są równe 1. Każdy z procesów kontroluje jedną komórkę tej tablicy. Gdy proces chce wejść do SK, to ustawia komórkę na 0, aż do chwili wyjścia z SK. Zmienna czyja_kolej jest początkowo równa 1. Gdy obydwa procesy chcą wejść do SK zmienna ta rozstrzyga, który powinien ustąpić drugiemu. Zakładamy, że procesy mają numery 1 i 2, i każdy proces pamięta swój numer na zmiennej lokalnej p.

Problem sekcji krytycznej - algorytm Dekkera - Sekcja wejściowa: k [p] := 0; while k [3 - p] = 0 do begin if czyja_kolej ≠ p then begin (* Ustąp drugiemu procesowi. *) k [p] := 1; while czyja_kolej ≠ p do; k [p] := 0 end - Sekcja wyjściowa: czyja_kolej := 3 - p; Rozwiązanie poprawne, lecz ma wady: - ograniczone do dwóch procesów ( alg. piekarniany); - proces oczekujący oczekuje aktywnie, tzn. czekając na jakieś zdarzenie sprawdza ciągle warunek określający, czy dane zdarzenie już zaszło.

Problem sekcji krytycznej - algorytm piekarniany. Rozwiązanie problemu SK dla n procesów. Algorytm ten wykorzystuje następujące zmienne: var wybieranie: array [1..2] of boolean; numerek: array [1..2] of integer; Początkowo elementy tych tablic są równe odpowiednio false i 0. Procesy są ponumerowane od 1 do n. Zakładamy, że każdy proces pamięta swój numer na zmiennej lokalnej p. Procesy chcące wejść do sekcji krytycznej "pobierają numerki". W tablicy wybieranie proces zaznacza, iż jest właśnie w trakcie pobierania numeru, a pobrany numer zapamiętuje w tablicy numerek. Proces wchodzi do SK, gdy upewni się, że jest pierwszy w kolejce. Po wyjściu z SK proces "wyrzuca numerek", tzn. zapisuje w tablicy numerek wartość 0.

Problem sekcji krytycznej - algorytm piekarniany. Rozwiązanie problemu SK dla n procesów. - Sekcja wejściowa: wybieranie [p] := true; numerek [p] := max (numerek [1], numerek [2], ..., numerek [n]) + 1; wybieranie [p] := false; for j := 1 to n do begin while wybieranie [j] do; while numerek [j] ≠ 0 and (numerek [j], j) < (numerek [p], p) do; end - Sekcja wyjściowa: numerek [p] := 0; Wada – nadal aktywne oczekiwanie.

Mechanizmy synchronizacji Wzajemne wykluczanie – poprzez zablokowanie przerwań w czasie wykonywania sekcji krytycznej (niepodzielność procedur realizujących dostęp do współdzielonych zasobów). Aktywne czekanie na dostęp – sterowanie za pomocą zmiennej (klucza); w SK testowanie i ewentualne blokowanie dostępu dla innych procesów; wspomaganie sprzętowe niepodzielną instrukcją Testuj i ustaw (Test & Set) lub Porównaj i wymień (Compare & Swap).

Techniki z aktywnym oczekiwaniem (Mutual Exclusion with Busy Waiting) blokada przerwań (disabling interrupts), zmienne blokujące (lock variables), ścisłe przełączanie (strick alternation), algorytm Dekkera, algorytm Petersona, instrukcja TSL (Test & Set Lock).

2. Technika Sleep & Wakeup funkcje systemowe (sleep, wakeup), technika semaforów, licznik zdarzeń, monitory,

Techniki z aktywnym oczekiwaniem. blokada przerwań: blokowanie wszystkich przerwań po wejściu do SK i ich odblokowanie po wyjściu procesu z SK; rozwiązanie sprzętowe, zapewniające niepodzielność wykonywanego ciągu instrukcji; proste lecz ryzykowne (zapominanie odblokowania przerwań przez użytkownika); nie przydatne w systemach wieloprocesorowych (blokada dotyczy tylko jednego procesora), technika stosowana na poziomie jądra SO.

Techniki z aktywnym oczekiwaniem. b) zmienne blokujące: rozwiązanie programowe, zakłada istnienie współdzielonej zmiennej blokującej lock, wstępnie ustawianej na 0. proces przed wejściem do SK sprawdza wartość tej zmiennej – jeśli lock == 0  proces zmienia wartość lock na 1 i wchodzi do SK, jeśli lock == 1  proces czeka, aż wartość lock zmieni się na 0; rozwiązanie mało skuteczne (trzeba pamiętać o zmianie wartości lock przy wyjściu z SK, oraz niebezpieczeństwo hazardu przy dostępie do tej zmiennej).

Techniki z aktywnym oczekiwaniem. c) ścisłe przełączanie: rozwiązanie programowe do synchronizacji 2 procesów, zmienna całkowita turn pokazuje kolejność, w jakiej procesy mogą wchodzić do SK (wartość zmiennej odpowiada identyfikatorowi procesu); jeśli identyfikator procesu = zmienna  proces wchodzi do SK jeśli identyfikator procesu =/= zmienna  proces czeka w pętli sprawdzającej; proces wychodząc z SK ustawia wartość zmiennej turn na identyfikator drugiego procesu; ciągłe testowanie możliwości wejścia do SK – tzw. aktywne oczekiwanie (jest to marnowanie czasu procesora);

Techniki z aktywnym oczekiwaniem. d) algorytm Dekkera: zmienne pokazują, który proces jest w SK, które procesy chcą wejść do SK, które procesy są faworyzowane.

Techniki z aktywnym oczekiwaniem. algorytm Petersona: rozwiązanie programowe pozbawione wad, stosowane szczególnie w systemach rozproszonych, procesy korzystają z 2 procedur: wchodzę i wychodzę (do SK), przed wejściem do SK proces wywołuje procedurę enter_region z własnym numerem jako parametrem, pokazując innym procesom, że współdzielony zasób jest zajęty, po wyjściu z SK proces wywołuje procedurę leave_region z własnym numerem jako parametrem, pokazując, że zasób jest wolny,

Techniki z aktywnym oczekiwaniem. f) instrukcja TSL (Test & Set Lock): rozwiązanie sprzętowo programowe, wygodne zwłaszcza w komputerach wieloprocesorowych, zawartość określonego słowa pamięci jest czytana i wpisywana do rejestru roboczego, natomiast do tego słowa pamięci jest wpisywana niezerowa wartość (najczęściej 1), operacje pisania i czytania są niepodzielne, nie mogą być przerwane - gwarantuje to system przez blokadę przerwań. żaden inny proces nie może wykonać operacji na tym słowie pamięci dopóki ta instrukcja nie zostanie zakończona, procesor, który wykonuje instrukcję TSL, blokuje szynę danych dopóki nie wykona tej instrukcji, instrukcję TSL wykonuje się w parze z współdzieloną zmienną flag; każdy proces, wykorzystując instrukcję TSL, sprawdza wartość tej zmiennej.

Przykład procedury wchodzę z instrukcją TSL: 1. Skopiowanie wartości zmiennej flag do rejestru roboczego i ustawienie flag na 1. Porównanie starej (skopiowanej) wartości zmiennej flag z zerem. Jeśli nie było to 0, to proces nie może wejść do sekcji krytycznej i następuje powrót na początek sekcji procedury. Test jest wykonywany aż zmienna flag będzie równa 0 i proces będzie miał przydzielony procesor. Procedura wychodzę ustawia wartość zmiennej flag na zero.

Wady technik z aktywnym oczekiwaniem. przyznawanie czasu procesora nawet takim procesom, które nie mogą wejść do SK marnowanie czasu procesora, możliwość wystąpienia zakleszczeń (problem odwróconego priorytetu).  technika Sleep & Wakeup

TECHNIKA SLEEP I WAKEUP
2. Technika Sleep & Wakeup a) Funkcje systemowe sleep – odwołanie do systemu, powodujące zablokowanie (uśpienie) procesu wywołującego tę funkcję aż do czasu, gdy inny proces go nie obudzi (sygnał budzenia); wakeup – odwołanie do systemu służące do budzenia określonego procesu.

b) Technika semaforów Semafor - jest to specjalna zmienna całkowita (służąca do przechowywania liczby budzeń). Z semaforem związane są 3 operacje: inicjowanie semafora (nadawanie mu wartości początkowej); operacja down - opuszczenie semafora, P(s), wait(s); operację tę można wykonać, jeżeli wartość semafora ma wartość dodatnią, wtedy następuje zmniejszenie jego wartości o jeden; operacja up - podniesienie semafora, V(s), signal(s).

SEMAFORY Niech s będzie semaforem.
1. V(s): s=s+1; zwiększenie o 1 następuje w jednej niepodzielnej operacji (trzy czynności tj. pobranie, dodanie i zapamiętanie nowej wartości nie mogą być przerwane; ponadto s nie jest dostępne dla innych procesów podczas tych czynności). 2. P(s): s=s-1 o ile to możliwe; jeżeli s==0 to niemożliwe jest zmniejszenie s o 1 i pozostanie w dziedzinie wartości nieujemnych. W takim przypadku dany proces wykonujący operację P musi czekać, aż zmniejszenie s będzie możliwe tzn. if s>0 then s=s-1 else (wait(s)), tzn. proces musi czekać, aż inny proces wykona operację V(s). Interpretacja semafora: s - to liczba wolnych zasobów (np. SK). Semafory, które są zainicjowane jako 1 i wykorzystywane przez dwa lub więcej procesów w celu zapewnienia, że tylko jeden z nich może wejść do sekcji krytycznej, są nazywane semaforami binarnymi.

SEMAFORY Operacja up zwiększa wartość semafora; jeśli jeden lub więcej procesów było uśpionych przy semaforze, to jeden z nich jest wybierany i uzyskuje pozwolenie na wykonanie operacji down tzn. opuszczenie semafora i wejście do sekcji krytycznej. Operacje up i down muszą być implementowane jako niepodzielne funkcje systemowe z możliwością blokady przerwań podczas testowania semafora i jego aktualizacji (na pojedynczym CPU). Jeżeli jeden z procesów wykonuje operację na semaforze, to (z wyjątkiem wstrzymania procesu, gdy semafor jest opuszczony) żaden inny proces nie wykonuje w tym samym czasie operacji na danym semaforze. Aby zapewnić taką niepodzielność, potrzebne jest specjalne wsparcie systemowe lub sprzętowe. W większości systemów wieloprocesorowych wykorzystuje się w tym celu instrukcję TSL (Test & Set Lock).

SEMAFORY Semafory i przerwania – jak wykorzystać semafory przy obsłudze przerwań? sprzęt zapamiętuje na stosie licznik, sprzęt ładuje nowy licznik z wektora przerwań, procedura asemblerowa zachowuje wartości rejestrów, procedura asemblerowa tworzy nowy stos, procedura C znaczy proces serwera jako gotowy, planista wybiera proces do wykonania, procedura C zwraca sterowanie do procedury asemblerowej, procedura asemblerowa wznawia wykonanie bieżącego procesu, 

SEMAFORY z każdym urządzeniem we-wy wiąże się semafor, którego początkowa wartość wynosi zero, po zainicjowaniu operacji we-wy dla danego urządzenia proces wykonuje DOWN na semaforze i przechodzi w stan uśpienia, po nadejściu przerwania proces obsługujący to przerwanie wykonuje UP na semaforze, proces, który zgłosił żądanie we-wy staje się gotowy do wykonania.

SEMAFORY Przykład zakleszczenia:
Wyobraźmy sobie, że mamy dwa semafory: S i Q, każdy związany z jedną sekcją krytyczną. Mamy też dwa procesy: P1 i P2 - każdy z nich chce wejść równocześnie do obydwu sekcji krytycznych. Jeżeli są one zaimplementowane następująco: P1: P(S); P(Q); Sekcje krytyczne V(Q); V(S); P2: P(Q); P(S); Sekcje krytyczne V(S); V(Q); to może się zdarzyć, że: Proces P1 opuszcza semafor S, po czym proces P2 opuszcza semafor Q. Wówczas proces P1 czeka w nieskończoność na podniesienie semafora Q, a proces P2 na podniesienie semafora S. Sytuację taką nazywamy właśnie zakleszczeniem; rozwiązaniem jest opuszczanie semaforów w obu procesach w tej samej kolejności.

SEMAFORY Problem sekcji krytycznej daje się rozwiązać za pomocą semaforów dość prosto - wystarczy dla każdej SK utworzyć oddzielny semafor, nadać mu początkową wartość 1 i w sekcji wejściowej SK wykonywać operację opuszczania semafora „p” a w sekcji wyjściowej – podnoszenia semafora „v”. Zastosowanie semaforów nie ogranicza się do rozwiązania problemu SK. Inne zastosowanie – problem producenta i konsumenta.

Problem producenta i konsumenta (semafory):
Struktura danych: var bufor: array [0..n-1] of produkt; pierwszy: 0..n-1; licznik: 0..n; Semafor tworzy sekcję krytyczną z operacjami wkładania i wyjmowania produktu z bufora. Aby wyeliminować aktywne oczekiwanie – dodatkowe dwa semafory: (pełne) = liczba jednostek produktu w buforze; (puste) = liczba pustych miejsc w buforze. Wartości początkowe: s=1; pełne = 0; puste = n

repeat wyprodukuj jednostkę produktu; P(puste); P(S); bufor [(pierwszy+licznik) mod n] := wyprodukowana jednostka licznik := licznik + 1; V(S); V(pełne) until false

repeat wyprodukuj jednostkę produktu; P(pełne); P(S); pobrana jednostka := bufor [pierwszy]; pierwszy := pierwszy+1) mod n; +licznikmod n] := licznik := licznik - 1; V(S); V(puste) skonsumuj pobraną jednostkę until false

Semafory pełne i puste nie tworzą sekcji krytycznej, ale synchronizują pobieranie i wstawianie elementów do bufora. Dodatkowa zaleta: - przy kilku producentach i konsumentach to rozwiązanie umożliwia korzystanie przez nich ze wspólnego bufora.

Problem pięciu filozofów - semafory Jedno z rozwiązań: - ograniczenie liczby jedzących filozofów do 4. W jadalni są 4 talerze; każda pałeczka to semafor: wzięcie pałeczki to opuszczenie semafora, odłożenie pałeczki – podniesienie semafora. Talerzom też odpowiada semafor o początkowej wartości 4. Analogicznie wzięcie talerza – opuszczenie semafora,odłożenie – podniesienie semafora.

Problem pięciu filozofów cd. var paleczki: array [0..4] of semaphore; talerze: semaphore; procedure filozof(i: 0..4); begin repeat myśl; P(talerz); P(paleczki[i]); P(paleczki[(i + 1) mod 5]); jedz; V(paleczki[i]); V(paleczki[(i + 1) mod 5]); V(talerz); until false end;

wymaga aktywnego czekania (obciążenie procesora)
SEMAFORY Wady semaforów: wymaga aktywnego czekania (obciążenie procesora) semafor jest wysokopoziomową abstrakcją opartą na niskopoziomowych mechanizmach elementarnych, zapewniających niepodzielność i mechanizmy wstrzymywania; wstrzymywanie i wznawianie wymaga przełączania kontekstu i zmian w kolejkach modułu szeregowania i kolejek wątków wstrzymanych; - operacje na semaforze są powolne.

c) Liczniki zdarzeń Liczniki zdarzeń są to zmienne, na których określa się 3 operacje: 1. Read(E) – odczyt licznika zdarzeń; 2. Advanced(E) – zwiększenie licznika zdarzeń E o 1; 3. Await(E,v) – proces czeka, aż licznik zdarzeń przyjmie wartość v lub więcej. Przykład: Problem producenta i konsumenta

d) Kolejki komunikatów Podstawowe operacje wykonywane na kolejce to wkładanie i wyjmowanie komunikatów (analogia: skrzynki na listy). Komunikaty uporządkowane wg FIFO  mechanizm wstrzymywania procesów przy próbie pobrania komunikatu przy pustej kolejce, lub wysłania do kolejki zapełnionej (są też implementacje nieblokujące – zamiast wstrzymywania procesu – komunikat). Mając semafory  można zaimplementować kolejki; kolejka pustych komunikatów  zachowuje się jak semafor.

e) Monitory Monitory to konstrukcje zdefiniowane w języku wysokiego poziomu – jest to zbiór operacji określonych przez programistę. Typ monitor zawiera deklarację zmiennych, które określają stan obiektu tego typu, oraz treści procedur lub funkcji, realizujących działania na tym obiekcie. Konstrukcja monitora gwarantuje, że w jego wnętrzu może być aktywny w jednym czasie tylko jeden proces, pozostałe procesy oczekują w kolejce FIFO. Jeśli jakiś proces chce wejść do zajętego monitora, to jest wstawiany na koniec kolejki procesów. Po opuszczeniu monitora przez proces, wchodzi pierwszy z procesów oczekujących. W związku z tym programista nie musi kodować barier synchronizacyjnych w sposób jawny.

d) Monitory cd. Monitory stanowią wygodniejsze rozwiązanie problemu SK niż semafory, ze względu na strukturę (np. przy semaforach można zapomnieć go podnieść przy wyjściu z SK, pomylić operacje „p” i „v”; w przypadku monitorów instrukcje synchronizujące realizuje język programowania. Konstrukcja monitora nie jest wystarczająca do modelowania wszystkich schematów synchronizacji – w tym celu wprowadza się konstrukcję typu warunek (condition); są to dodatkowe kolejki (FIFO) procesów używane tylko wewnątrz monitorów.

d) Monitory cd. Jedynymi operacjami, które mogą dotyczyć warunku są: czekaj (x) i sygnalizuj (x). Operacja czekaj powoduje wstrzymanie procesu i wstawienie go na koniec kolejki (oznacza, że proces ją wywołujący zostaje zawieszony aż do chwili, gdy inny proces wykona operację sygnalizuj). Operacja sygnalizuj wznawia pierwszy proces z kolejki (o ile kolejka nie jest pusta). W implementacji monitorów konieczne jest posłużenie się wstawkami assemblerowymi i instrukcją TSL lub semaforami.

Problem producenta i konsumenta (monitory) Monitor udostępnia dwie operacje: wstaw i pobierz. Struktura danych - jak przy semaforach. Dwie kolejki procesów: pełne – oczekujący na produkty, oraz puste- oczekujący na puste miejsca w buforze. monitor producent_konsument; var bufor: array [0..n-1] of produkt; pierwszy: 0..n-1; licznik: 0..n; pełne, puste: condition;

Producent i konsument (monitory) cd. procedure wstaw(p: produkt); begin if licznik = n then wait(puste); bufor [(pierwszy+licznik) mod n] := p; licznik := licznik + 1; signal(pełne) end; function pobierz: produkt; if licznik = 0 then wait(pełne); pobierz := bufor [pierwszy]; pierwszy := (pierwszy + 1) mod n; licznik := licznik - 1; signal(puste)

Producent i konsument (monitory) cd. begin pierwszy := 0; licznik := 0 end;

Sprzętowe mechanizmy synchronizacji. Przedstawione mechanizmy synchronizacji w technice Sleep & Wake up eliminują wadę aktywnego oczekiwania. Ich implementacja wymaga jednak wsparcia sprzętowego. Przy komputerach jednoprocesorowych – może to być blokowanie przerwań; powoduje ono niepodzielność wykonywania ciągu instrukcji. Przy komputerach wieloprocesorowych – blokowanie przerwań jest niewystarczające, bo procesy mogą działać równolegle nawet przy zablokowanych przerwaniach.

Sprzętowe mechanizmy synchronizacji. Stosuje się wówczas inne wsparcie sprzętowe (funkcja Test & Set). function TestAndSet(var x:boolean): boolean; begin TestAndSet := x; x := true end; Zmienna x uzyskuje wartość true, a wynikiem funkcji jest poprzednia wartość zmiennej x. Funkcja jest wykonywana w sposób niepodzielny!

Sprzętowe mechanizmy synchronizacji. Zastosowanie do problemu SK: Sekcja wejściowa: while TestAndSet (S) do; Sekcja wyjściowa: S := false; Powyższa aplikacja stosowana jest nie tyle do ochrony SK co do ochrony niepodzielności operacji na semaforach. Inne rozwiązania: funkcja exchange (zamień)- powoduje zamianę zawartości 2 komórek pamięci (operacja niepodzielna).

Problem czytelników i pisarzy. Dwie grupy procesów starające się o dostęp do SK (tzw. biblioteka). Specyfika tej SK polega na tym, że może w niej przebywać równocześnie wielu czytelników (jedna grupa procesów), ale gdy jest proces z grupy pisarzy, to żaden inny proces nie może przebywać w SK. Jak zorganizować dostęp, aby nie doprowadzić do zagłodzenia? Rozwiązanie – wpuszczać na zmianę grupa czytelników, pisarz, grupa czytelników, pisarz, itd.

Problem czytelników i pisarzy – monitory. 2 kolejki procesów oczekujących na wejście do SK: czytelnicy, pisarze. Zmienna licznik = liczbie czytelników w SK, lub –1, gdy jest w niej pisarz. Monitor udostępnia 4 procedury We i WY dla czytelników i pisarzy: monitor czytelnicy_i_pisarze; var licznik: integer; czytelnicy, pisarze: condition;

Problem czytelników i pisarzy monitory cd. procedure wejście_czytelnika; begin if (licznik = -1) or not empty(pisarze) then wait(czytelnicy); licznik := licznik + 1; signal(czytelnicy) end; procedure wyjście_czytelnika; licznik := licznik - 1; if (licznik = 0) then signal(pisarze)

Problem czytelników i pisarzy. procedure wejście_pisarza; begin if (licznik ≠ 0) then wait(pisarze); licznik := - 1; end; procedure wyjście_ pisarza; licznik := 0; if empty (czytelnicy) then signal(pisarze) else signal(czytelnicy); licznik :=0;

Zadania Co by było, gdyby w problemie producenta-konsumenta pętle oczekujące, aż bufor nie będzie pusty/pełny umieścić również w sekcji krytycznej? Zaprojektuj implementację kolejek komunikatów z użyciem semaforów. Rozwiąż problem sekcji krytycznej za pomocą instrukcji exchange. Rozwiąż problem producenta-konsumenta używając do synchronizacji procesów kolejek komunikatów. Rozwiąż problem czytelników i pisarzy używając do synchronizacji procesów semaforów. Wymyśl inne od przedstawionego rozwiązanie problemu pięciu filozofów. Upewnij się, że nie może w nim wystąpić ani blokada, ani zagłodzenie. 

SYSTEMY OPERACYJNE SYNCHRONIZACJA PROCESÓW

Podobne prezentacje

Prezentacja na temat: "SYSTEMY OPERACYJNE SYNCHRONIZACJA PROCESÓW"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres

Wejść

Zaloguj się poprzez sieć społeczną:

SYSTEMY OPERACYJNE SYNCHRONIZACJA PROCESÓW

Podobne prezentacje

Prezentacja na temat: "SYSTEMY OPERACYJNE SYNCHRONIZACJA PROCESÓW"— Zapis prezentacji:

Podobne prezentacje

О projekcie

Zwrotny adres