przerwany proces móg l zareagować na określone zdarzenie. Można je traktować jako software owe wersje przerwań sprz etowych.

Podobne dokumenty
Sygnały. 7. Sygnały (2005/2006)

przypadków wywo lanie systemowe (funkcja systemowa) lub funkcja biblioteczna zwraca wartość 1(czasamiNULL) iprzypisujezmiennej zewn etrznej,

Systemy Operacyjne Ćwiczenia

Obsługa sygnałów. Tomasz Borzyszkowski

Instrukcja do laboratorium Systemów Operacyjnych. (semestr drugi)

aodczytywać zniegoza pomoc afunkcjiread, (niebuforowane funkcje wejścia/wyjścia). e sukcesem, to zwróci liczb, erzeczywiściezapisanychbajtów.

Procesy. w systemach operacyjnych (quasi)równoleg le wykonywanie wielu być wykonywane naprzemiennie i/lub jednocześnie.

Procesy, pliki, potoki, sygnały - uzupełnienie

eć dzielona standardu POSIX

Laboratorium Procesy w systemach UNIX 3.2 Polecenia związane z procesami

Unix: programowanie procesów

Sygnał mechanizm asynchronicznego powiadamiania procesów o zdarzeniach zwykle awaryjnych.

Wprowadzenie do systemu operacyjnego Linux zarzdzanie procesami, cz. 2

pami eć operacyjna przechowuje dane do przetworzenia, tymczasowe dane pomocnicze,

Funkcje systemu Unix

Zaawansowane programowanie w C++

Systemy Operacyjne - Operacje na plikach

Systemy Operacyjne 1 Laboratorium 2 Procesy i sygnały w Linuksie (jeden tydzień) dr inż. Arkadiusz Chrobot

Unix: programowanie procesów

Sygnały i ich obsługa

POSIX: IEEE Std (Issue 6, 2004 edition)

Linux: Procesy. Systemy Operacyjne. Mateusz Hołenko. 26 marca 2013

UNIX. mgr inż. Marcin Borkowski

Środowisko procesu Unixowego

Zarządzanie procesami

Unix: programowanie procesów

Obliczenia rozproszone z wykorzystaniem MPI

Unix: programowanie procesów

Paradygmaty programowania. Paradygmaty programowania

Tablice, procesy, sygnały i nie tylko. Kurs systemu Unix 1

4.2 Sposób korzystania z l acza

Poniższe funkcje opisane są w 2 i 3 części pomocy systemowej.

Komunikacja za pomocą potoków. Tomasz Borzyszkowski

Rozdzia l 3. Laboratorium 3. danych zawierajac

Procesy. Systemy Operacyjne 2 laboratorium. Mateusz Hołenko. 9 października 2011

Podstawy administracji systemu Linux

ezykach wysokiego poziomu (Dijkstra, 1965). semaphore semaphore S; Operacje na semaforze:

Wątki, sygnały i szeregowanie w systemach UNIX, Linux

Procesy. w systemach operacyjnych (quasi)równoleg le wykonywanie wielu być wykonywane naprzemiennie i/lub jednocześnie.

Paradygmaty programowania

Systemy Operacyjne I: Procesy

Procesy. w systemach operacyjnych (quasi)równoleg le wykonywanie wielu być wykonywane naprzemiennie i/lub jednocześnie.

Uruchamianie SNNS. Po uruchomieniu. xgui & lub snns & pojawia si e okno. programu. Symulator sztucznych sieci neuronowych SNNS 1

Wykład 5 Przerwania i wywołania systemowe. Wojciech Kwedlo, Systemy Operacyjne II -1- Wydział Informatyki PB

Temat zajęć: Obsługa procesów w systemie.

procesy odrębne dzielone

Krótki kurs programowania współbieżnego

Procesy. w systemach operacyjnych (quasi)równoleg le wykonywanie wielu być wykonywane naprzemiennie i/lub jednocześnie.

Łącza nienazwane(potoki) Łącza nienazwane mogą być używane tylko pomiędzy procesami ze sobą powiązanymi.

9. Procesy, urządzenia i system plików w systemie Linux

Paradygmaty programowania. Paradygmaty programowania

Organizacja systemu plików

Funkcje. Piotr Zierhoffer. 7 października Institute of Computer Science Poznań University of Technology

Programowanie generyczne w C++

Równoleg le sortowanie przez scalanie

Laboratorium systemów operacyjnych ćwiczenie nr 3. [ilość modułów: 1] Temat zajęć: Procesy w systemie operacyjnym

z powielaniem wielu struktur danych oraz komunikacja

Po uruchomieniu programu nasza litera zostanie wyświetlona na ekranie

raceboard-s Szybki start

Dariusz Wawrzyniak 5 kwietnia 2001

SYSTEMY OPERACYJNE I laboratorium 3 (Informatyka stacjonarne 2 rok, semestr zimowy)

Wykład 2. Budowa komputera. W teorii i w praktyce

pozycja klucza - offset klucza w rekordzie flaga pliku tymczasowego czas utworzenia bież acy rozmiar - liczba bajtów w pliku

SYSTEM DIAGNOSTYCZNY OPARTY NA LOGICE DOMNIEMAŃ. Ewa Madalińska. na podstawie prac:

Zastosowanie Robotów. Ćwiczenie 6. Mariusz Janusz-Bielecki. laboratorium

Ćwiczenie nr 520: Metody interpolacyjne planowania ruchu manipulatorów

Stypendia USOS Stan na semestr zimowy 2013/14

jeszcze dygresja o macierzach...

procesami w systemie Unix

procesami w systemie Unix

Charakterystyka systemów plików

procesami w systemie Unix

Ghost in the machine

Wieloprogramowy system komputerowy

Wirtualne sieci prywatne

Organizacja systemu plików

Statystyka w analizie i planowaniu eksperymentu

Functionalization. Funkcje w C. Marcin Makowski. 30 listopada Zak lad Chemii Teoretycznej UJ

Paradygmaty programowania

Statystyka w analizie i planowaniu eksperymentu

Zarządzanie procesami (omawiane zagadnienia)

PowerShell. Sławomir Wawrzyniak

PODRĘCZNIK UŻYTKOWNIKA

Adapter USB do CB32. MDH-SYSTEM ul. Bajkowa 5, Lublin tel./fax lub kom e mail: info@mdh-system.pl

Elementy cyfrowe i układy logiczne

Działanie systemu operacyjnego

SYSTEMY OPERACYJNE: STRUKTURY I FUNKCJE (opracowano na podstawie skryptu PP: Królikowski Z., Sajkowski M. 1992: Użytkowanie systemu operacyjnego UNIX)

W przeciwnym wypadku wykonaj instrukcję z bloku drugiego. Ćwiczenie 1 utworzyć program dzielący przez siebie dwie liczby

Język skryptowy: Laboratorium 1. Wprowadzenie do języka Python

Pliki, potoki, sygnały

us lugi katalogowe? Czym różni si e serwer katalogowy od serwera bazy danych:

Wieloprogramowy system komputerowy

Zastosowanie Robotów. Ćwiczenie 4. Mariusz Janusz-Bielecki. laboratorium

Wyk lad 9 Podpierścienie, elementy odwracalne, dzielniki zera

Metody obsługi zdarzeń

UXP1A Unix Programowanie i Architektura

Grupy i cia la, liczby zespolone

Architektura Systemów Komputerowych. Sterowanie programem skoki Przerwania

Instrukcja do laboratorium Systemów Operacyjnych (semestr drugi)

Arkusz zawiera informacje prawnie chronione do momentu rozpocz cia egzaminu.

Transkrypt:

c Wies law P laczek 9 3 Sygna ly 3.1 Opis sygna lów Najprostsz ametod akomunikacjimi edzyprocesowej w systenie UNIX s sygna ly. Umożliwiaj aoneasynchroniczne przerwanie dzia lania procesu przez inny proces lub j adro aby przerwany proces móg l zareagować na określone zdarzenie. Można je traktować jako software owe wersje przerwań sprz etowych. Sygna ly mog apochodzićzróżnychźróde l: Od sprz etu np.gdyjakiśprocespróbujeuzyskaćdost ep do adresów spoza w lasnej przestrzeni adresowej lub kiedy zostanie w nim wykonane dzielenie przez zero. Od j adr s atosygn lypowiadamiaj ace proces o dost epności urz adzeń wejściawyjścia na które proces czeka l np. o dost epności terminala. Od innych procesów procespotomnypowiadamiaswegoprzodkaotymżesi e zakończy l. Od użytkowników użytkownicy mog agenerowaćsygn lyzakończeniaprzerwania lub stopu za pomoc aklawiatury(sekwencjeklawiszygeneruj ace sygna ly można sprawdzić komend stty -a). Sygna ly maj aprzypisanenazwyzaczynaj ace si eodsekwencjisig is aodpowiednioponumerowane szczegó lowy opis dla danego systemu można znaleźć w man 7 signal. Nazwy sygna lów udost epnianych w systemie przechowywane s awtablicysys siglist[] która jest indeksowana ich numerami. Aby z niej skorzystać należy użyć deklaracji: extern const char * const sys_siglist[]; List eważniejszychsygna lówprzedstawiatablica2. Proces który otrzyma l sygna l może zareagować na trzy sposoby: 1. Wykonać operacj e domyśln a. Dla wi ekszości sygna lów domyśln areakcj ajest zakończenie dzia lania procesu po uprzednim powiadomieniu o tym procesu macierzystego. Czasem generowany jest plik zrzutu (ang. core) tzn. obraz pami eci zajmowanej przez proces. 2. Zignorować sygna l. Proces może to zrobić w reakcji na wszystkie sygna ly z wyj atkiem dwóch: SIGSTOP (zatrzymanie procesu) i SIGKILL (bezwarunkowe zakończenie procesu). Dzi eki niemożności ignorowania tych dwóch sygna lów system operacyjny jest zawsze w stanie usun ać niepoż adane procesy. 3. Przechwycić sygna l. Przychwycenie sygna lu oznacza wykonanie przez proces specjalnej procedury obs lugi po jej wykonaniu proces może powrócić do swego zasadniczego dzia lania (o ile jest to w laściwe w danej sytuacji). Podobnie jak ignorować przechwytywać można wszystkie sygna ly z wyj atkiem: SIGSTOP i SIGKILL. Proces potomny dziedziczy po swoim przodku mechanizmy reagowania na wybrane sygna ly. Jeżeli jednak potomek uruchomi nowy program przy pomocy funkcji exec to przywrócone zostaj adomyślneproceduryobs lugisygna lów.

c Wies law P laczek 10 Sygna l Opis Domyślna akcja SIGABRT Wysy lany przez funkcj e abort SIGALRM Min l czas ustawiony przez funkcj e alarm Zakończenie SIGBUS B l ad sprz etowy (szyny) SIGCHLD Zakończenie procesu potomnego Ignorowanie SIGCONT Uruchomienie po wstrzymaniu Ignorowanie SIGHUP Zakończenie procesu steruj acego terminalem Zakończenie SIGFPE Wyj atek arytmetyczny SIGILL Nielegalna instrukcja SIGINT Przerwanie z klawiatury [Ctrl-C] Zakończenie SIGKILL Bezwarunkowe zakończenie procesu (nie może być Zakończenie zignorowany ani przechwycony) SIGQUIT Sekwencja wyjścia z klawiatury [Ctrl-\] SIGPIPE Proces pisze do potoku z którego nikt nie czyta Zakończenie SIGSEGV Naruszenie ograniczeń pami eci SIGSTOP bez zakończenia (nie może być zignorowany ani przechwycony) SIGTERM Ż adanie zakończenia Zakończenie SIGTSTP Sekwencja zatrzymania z klawiatury [Ctrl-Z] SIGTTIN Proces w tle czyta z terminala steruj acego SIGTTOU Proces w tle pisze na terminal steruj acy SIGUSR1 Sygna l użytkownika nr 1 Zakończenie SIGUSR2 Sygna l użytkownika nr 2 Zakończenie 3.2 Wysy lanie sygna lów Tablica 2: Lista ważniejszych sygna lów. Do wysy lania sygnalów do procesów i ich grup s luży funkcja systemowa kill. Parametr pid <sys/types.h> <signal.h> Prototyp int kill(pid t pid int sig); wartość 0 1 Tak określa proces lub grup eprocesówdoktórychzostaniewys lanysygnal jegoznaczenie objaśnia poniższa tabelka. Wartość pid Jakie procesy odbieraj sygna l > 0 Proces o PID = pid = 0 Procesy należ ace do samej grupy co proces wysy laj acy sygna l < -1 Procesy należ ace do grupy o PGID = -pid Parametr sig oznacza numer wysy lanego sygna lu (można uzywać nazw symbolicznych).

c Wies law P laczek 11 Jeżeli sig = 0tofunkcjakill nie wysy la sygna lu ale wykonuje test b l edów np. sprawdza czy proces istnieje jeżeli nie to errno = ESRCH. Z poziomu pow loki sygna ly można wysy lać za pomoc polecenia: kill -sig pid Znaczenie parametrów sig i pid jest takie jak powyżej przy czym zamiast numeru sygna lu można użyć jego nazwy symbolicznej (można nawet pomin ać cz lon SIG). List enazw wszystkich sygna lów można uzyskać poleceniem: kill -l anazw ekonkretnegosygn luo numerze sig poleceniem: kill -l sig. Sygna l SIGALRM można wys lać pos luguj ac si efunkcj asystemow alarm. Funkcja ta generuje sygna l kiedy minie ustalona liczba sekund przekazana przez parametr sec. Jeżeli sec = 0toczasomierzzostaniewyzerowany. <unistd.h> Prototyp unsigned alarm(unsigned sec); wartość Liczba pozosta lych sekund Nie 3.3 Obs luga sygna lów <signal.h> Prototyp void (*signal(int sig void (*handler)(int)))(int); wartość Poprzednia dyspozycja sygna lu SIG ERR ( 1) Tak Do modyfikowania sposobu w jaki proces zareaguje na sygna l można użyć funkcji signal. Prototyp tej funkcji na pierwszy rzut oka wywo luje cz esto niema l akonsternacj e. Latwiej go zrozumieć pos luguj ac si e pomocnicz adefinicj atypusighandler t b ed acego wkaźnikiem do funkcji: typedef void (*sighandler_t)(int); sighandler_t signal(int sig sighandler_t handler); Pierwszym parametrem funkcji signal jest numer sygna lu który ma być obs lużony za wyj atkiem SIGKILL i SIGSTOP. Drugimparametremnatomiastjestwskaźnikdofunkcji która ma być wywo lana w chwili przybycia sygna lu. Funkcja ta może być określona sta lymi SIG DFL SIG IGN lub zdefiniowana przez użytkownika; SIG DFL oznacza domyśln obs lug esygn lunatomiastsig IGN ignorowanie sygna lu. Funkcja do obs lugi sygna lu ma jeden parametr typu int do którego zostanie automatycznie wstawiony numer sygna lu. Aby spowodować oczekiwanie procesu na pojawienie si esygn lumożnapos lużyćsi e funkcj abiblioteczn pause. Funkcjatazawieszaprocesdoczasuodebraniasygna luktóry nie zosta l zignorowany. Funkcja pause wraca tylko w przypadku przechwycenia sygna lu ipowrotufunkcjiobs lugisygna lu;zwracawtedywartość-1 iustawiazmienn errno na EINTR.

c Wies law P laczek 12 <unistd.h> Prototyp int pause(void); wartość 1 jeśli sygna l nie powo- Nie zwraca nic Tak duje zakończenia procesu Przyk ladowe wywo lania funkcji signal powoduj ace ingorowanie sygna lu SIGQUIT oraz w l aczenie w lasnej obs lugi sygna lu SIGINT przy pomocy funkcji my sighandler mog awygl a- dać nast epuj aco: void my_sighandler(int); if (signal(sigquitsig_ign) == SIG_ERR){ perror("funkcja signal ma problem z SIGQUIT"); exit(exit_failure); } if (signal(sigintmy_sighandler) == SIG_ERR){ perror("funkcja signal ma problem z SIGINT"); exit(exit_failure); } Oczywiście funkcja my sighandler musi zostać zdefiniowana przez użytkownika zgodnie z jego życzeniem obs lugi sygna lu SIGINT. Funkcja signal wyst epuje we wszystkich wersjach systemu UNIX ale niestety nie jest niezawodna (może nie obs lużyć poprawnie wielu sygna lów które nast epuj awkrótkimczasie po sobie). Dlatego w standardzie POSIX wprowadzono dodatkow afunkcj edoobs lugi sygna lów o nazwie sigaction któraspe lniawymoginiezawodności.równieżdowysy lania sygna lów wprowadzono bardziej wyrafinowany odpowiednik funkcji kill onazwiesigqueue. Obie te funkcje umożliwiaj azaawansowaneiszczegó lowezarz adzanie sygna lami ale s znacznie bardziej skomplikowane niż signal i kill. Ichopisymożnaznaleźćwpodr eczniku systemowym man.

c Wies law P laczek 13 ĆWICZENIE 3: Wysy lanie i Obs luga Sygna lów Napisać program do obs lugi sygna lów z możliwościami: (1) wykonania operacji domyślnej (2) ignorowania oraz (3) przechwycenia i w lasnej obs lugi sygna lu. Numer sygna lu oraz opcj eobs luginajlepiejprzekazywaćzapomoc aargumentówwywo laniaprogramu sprawdzać ich liczb eiwypisywaćodpowiednikomunikatwprzypadkub l ednego uruchomienia. (a) Uruchomić program i wysy lać do niego sygna ly przy pomocy sekwencji klawiszy oraz przy pomocy polecenia kill. (b) Uruchomić powyższy program poprzez funkcj e exec wprocesiepotomnyminnego procesu i wysy lać do niego sygna ly poprzez funkcj esystemow kill zprocesumacierzystego (numer sygna lu oraz opcj eobs luginajlepiejprzekazywaćprzezargumenty wywo lania programu).! Uwaga: Przed wys laniem sygna lu sprawdzić czy proces istnieje (patrz podrozdzia l 3.2). (c) Uruchomić kilka procesów potomnych i wysy lać sygna ly do ca lej grupy procesów po uprzednim sprawdzeniu jej istnienia (jak wyżej).! Uwaga: Proces macierzysty też należy do tej grupy wi ec trzeba go odpowiednio uodpornić na sygna l np. przez ustawienie jego ignorowania.