Projekt systemy operacyjne 2 - Systemowe mechanizmy synchr

Transkrypt

1 systemy operacyjne 2 - Systemowe mechanizmy synchronizacji procesów 19 lutego 2012

2 Wielow tkowo± Mechanizmy synchronizacji Wielow tkowo± Mechanizmy synchronizacji Klasyczne przykªady programów

3 Wielow tkowo± Wprowadzenie Wielow tkowo± Mechanizmy synchronizacji Technicznie rzecz bior c w tek to niezale»ny ci g instrukcji który mo»e by wykonywany równolegle do ci gu instrukcji które go wywoªaªy. W ±rodowisku UNIX ±rodowisko w tku: znajduje si w obr bie procesu i korzysta z jego zasobów, istnieje tak dªugo jak rodzic, mo»e dzieli zasoby z innymi w tkami równolegle "zajmuj c si nimi" Dla wszystkich w tków danego procesu wspólne s : PID, GID, UID, ±rodowisko, katalog bie» cy, dost p do funkcji, rejestry, etc.

4 W tki POSIX Wprowadzenie Wielow tkowo± Mechanizmy synchronizacji Wielu producentów sprz tu stworzyªo wiele implementacji w tków co doprowadziªo do do± du»ego ÿbaªaganu" w tym segmencie programowania. Dzi ki standardowi IEEE POSIX c standard (1995) udaªo si stworzy standardowe API, które doª cza si do dystrybucji. Denicje funkcji zwi zanych z POSIX threads znajduj si w pliku nagªówkowym pthreads.h, a implementacja w jednej z bibliotek systemowych (mo»e by cze±ci libc lub znajdowa si w oddzielnej bibliotece). Warto zwróci uwag na fakt, i» pomi dzy implementacjami Phtreads na ró»nych platformach istniej pewne subtelne ró»nice których nie zawsze mo»emy by ±wiadomi.

5 Semafory Wprowadzenie Wielow tkowo± Mechanizmy synchronizacji Semafory s strukturami danych wspólnie u»ytkowanymi przez kilka procesów. Najcz strze zastosowanie w synchronzowaniu dziaªania kilku procesów korzystaj cych ze wspólnego zasobu, którego wspóªu»ytkowanie nie zostaªo przewidziane. Typy semaforów: binarne { steruj ce dost pem do jednego zasobu (0 - zasób zaj ty, 1 - zasób wolny); licz ce { steruj ce dostepem do wielu zasobów. Z implementacyjnego punktu widzenia semafor jest unieujemn liczb caªkowit przechowywan w j drze systemu. Dost p do semafora jest udzielany za po±rednictwem kilku wywoªa«systemowych.

6 Mechanizmy synchronizacji POSIX Wielow tkowo± Mechanizmy synchronizacji Rodzaje zmiennych synchronizuj cych: zamek umo»liwiaj ca implementacj wzajemnego wykluczania, zmienna warunkowa umo»liwia usypianie i budzenie w tków. Zmienne synchronizuj ce musz by wspóªdzielone przez synchronizowane w tki. Zanim zmienna zostanie wykorzystana do synchronizacji musi zosta zainicjalizowana.

7 Zmienne synchronizuj ce Wielow tkowo± Mechanizmy synchronizacji Zamek (MUTual EXclusion lock - MUTEX) umo»liwia implementacj wzajemnego wykluczania. Operacje: lock - zaj cie (zaryglowanie) zamka (pthread mutex lock), unlock - zwolnienie (odryglowanie) zamka (pthread mutex unlock), trylock - nieblokuj ca próba zaj cia zamka (pthread mutex trylock). Zmienna warunkowa umo»liwia usypianie i budzenie w tków. Operacje: wait u±pienie w tku (pthread cond wait), signal obudzenie jednego z u±pionych w tków (pthread cond signal), broadcast obudzenie wszystkich u±pionych w tków (pthread cond broadcast).

8 Literatura Wprowadzenie Wielow tkowo± Mechanizmy synchronizacji 1 MAN

9 "ksi»kowe" Wprowadzenie Klasyczne przykªady programów Problem producenta i konsumenta problem ograniczonego buforowania w komunikacji mi dzyprocesowej. Problem pi ciu lozofów problem jednoczesnego dost pu do dwóch zasobów (ryzyko gªodzenia i zakleszczenia). Problem ±pi cych fryzjerów problem synchronizacji w interakcji klient-serwer przy ograniczonym kolejkowaniu. Problem czytelników i pisarzy problem synchronizacji dost pu do zasobu w trybie wspóªdzielonym i wyª cznym.

10 Problem pi ciu lozofów Klasyczne przykªady programów Przy okr gªym stole siedzi pi ciu lozofów, którzy na przemian my±l i jedz makaron ze wspólnej miski. eby co± zje±, lozof musi zdoby dwa widelce, z których ka»dy wspóªdzieli ze swoim s siadem. Widelec dost pny jest w trybie wyª cznym mo»e by u»ywany w danej chwili przez jednego lozofa. Nale»y zsynchronizowa lozofów tak, aby ka»dy mógª si w ko«cu naje± przy zachowaniu reguª dost pu do widelców oraz przy mo»liwie du»ej przepustowo±ci w spo»ywaniu posiªków.

11 Problem ±pi cych fryzjerów Klasyczne przykªady programów W salonie fryzjerskim jest poczekalnia z p miejscami oraz n foteli, obsªugiwanych przez fryzjerów. Do salonu przychodzi klient, budzi fryzjera, po czym fryzjer znajduje wolny fotel i obsªuguje klienta. Je±li nie ma wolnego fotela, klient zajmuje jedno z wolnych miejsc w poczekalni. Je±li nie ma miejsca w poczekalni, klient odchodzi. Problem polega na zsynchronizowaniu fryzjerów oraz klientów w taki sposób, aby jeden fryzjer w danej chwili obsªugiwaª jednego klienta i w tym samym czasie klient byª obsªugiwany przez jednego fryzjera.

12 Problem czytelników i pisarzy Klasyczne przykªady programów Dwa rodzaje u»ytkowników czytelnicy i pisarze korzystaj ze wspólnego zasobu czytelni. Czytelnicy korzystaj z czytelni w trybie wspóªdzielonym, tzn. w czytelni mo»e przebywa w tym samym czasie wielu czytelników. Pisarze korzystaj z czytelni w trybie wyª cznym, tzn. w czasie, gdy w czytelni przebywa pisarz, nie mo»e z niej korzysta inny u»ytkownik (ani czytelnik, ani inny pisarz). Synchronizacja polega na blokowaniu u»ytkowników przy wej±ciu do czytelni, gdy wymaga tego tryb dost pu.

13 Problem producenta i konsumenta Klasyczne przykªady programów Producent produkuje jednostki okre±lonego produktu i umieszcza je w buforze o ograniczonym rozmiarze. Konsument pobiera jednostki produktu z bufora i konsumuje je. Z punktu widzenia producenta problem synchronizacji polega na tym,»e nie mo»e on umie±ci kolejnej jednostki, je±li bufor jest peªny. Z punktu widzenia konsumenta problem synchronizacji polega na tym,»e nie powinien on mi dost pu do bufora, je±li nie ma tam»adnego elementu do pobrania.

14 Warunki zaliczenia projektu Programujemy pod Unixem!!

15 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'.

16 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne).

17 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer

18 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer Piszemy w C lub C++

19 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer Piszemy w C lub C++ Praca wªasna!

20 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer Piszemy w C lub C++ Praca wªasna! Tylko 1 program

21 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer Piszemy w C lub C++ Praca wªasna! Tylko 1 program Nie tworzymy skomplikowanej graki

22 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer Piszemy w C lub C++ Praca wªasna! Tylko 1 program Nie tworzymy skomplikowanej graki Nie tworzymy niepotrzebnie skomplikowanego kodu

23 Warunki zaliczenia projektu Programujemy pod Unixem!! Nie u»ywamy 'fork'. Program musi by tak skonstruowany by wida byªo wielow tkowo± (w tki maj by u»yteczne). Nie mog by problemy 'ksi»kowe', mog by : gry, symulatory, aplikacje klient-serwer Piszemy w C lub C++ Praca wªasna! Tylko 1 program Nie tworzymy skomplikowanej graki Nie tworzymy niepotrzebnie skomplikowanego kodu Nie u»ywamy 'printf'! ncurces

24 Biblioteka "ncurces" Wprowadzenie ncurses (ang. new curses) to kontynuacja biblioteki curses. Dostarcza ona funkcji do obsªugi terminala tekstowego niezale»nie od jego typu (korzysta z terminfo lub termcap), z optymalizacj (ekran nie jest odrysowywany w caªo±ci). W ncurses ekran skªada si z nakªadaj cych si na siebie wirtualnych okien, których korzeniem jest okno stdscr, którego nie mo»na przesuwa ani zmienia jego rozmiaru (zawsze ma rozmiar terminala). Ta biblioteka jest dost pna na licencji GNU GPL wraz z peªnym kodem ¹ródªowym.

25 Kompilowanie z bibliotek ncurses ncurces #include <ncurses.h> gcc <program file> -lncurses

26 Sprawozdanie Wprowadzenie wersja wydrukowana JEDNA KARTKA A4 + mail/no±nik z programem opis tre±ci zadania (np. 'gra w formuª 1') opis zaªo»e«(np. 'ka»dy wózek jest oddzielnym w tkiem ') zasady gry/symulacji/itd. tzw. zrzut ekranu z programu - max 2 ilustracje tre± programu (kod) z komentarzami Termin: Ostatnie zaj cia