1.5.1 Sygnaly-opis


Do
strony głównej

 Zadanie

    Zaimplementuj mechanizm komunikacji między procesami
wykorzystujący sygnał�y. Użyj w tym celu sygna�łów pozostawionych do zdefiniowania
przez użytkownika: SIGUSR1 i SIGUSR2 oraz sygna�łów pozostawionych bez
implementacji: SIGUNUSED i SIGSTKFLT. Ponieważ tradycyjna implementacja
sygnałó�w nie pozwala na przenoszenie przez nie żadnej informacji (wiadomo
tylko, że sygnał� nadszedł�), należy zmieniąć tę implementację na potrzeby
zadania. Można to oczywiŚcie zrobićą w sposób radykalny (kolejkując sygna�ły
i pozwalając by przenosi�ły każdą możliwą informację); ja jednak proponuję
tu uproszczoną wersję komunikacji, która pozwala wymieniaąć informacje
tylko przez dwa procesy między sobą to znaczy proces w czasie komunikowania
się z jednym z pozosta�ych procesów w systemie nie będzie się jednoczeŚnie
komunikowa�ł z innymi). Proponowana przeze mnie zmiana implementacji dotyczy
jedynie dodania do struktury task_struct procesu pól związanych z wykorzystywanymi
w mechanizmie komunikacji sygnał�ami tak, by był�o gdzie zapisaćą przenoszone
przez nie informacje.
 
  Na potrzeby zadania należy najpierw zmieniąć nazwy sygnałów:


SIGUSR1             
------->              
SIGBEGIN


SIGUSR2             
------->              
SIGACCEPT


SIGUNUSED      ------->               
SIGCOMM


SIGSTKFLT        ------->               
SIGEND.



     Proponowany scenariusz dzia�łania:


 SIGBEGIN - oznacza, że proces nadawca tego sygnał�u (porces inicjujący
komunikację) chce rozpocząć akt komunikacji z procesem, do którego ten
sygna�ł wysy�ła; z sygna�łem tym musi byąć związane pole nr_nadawcy by
był�o wiadomo komu odpowiedziećą.


 SIGACCEPT -wysył�any do procesu, od którego wcześŚniej otrzymaliŚmy
SIGBEGIN; oznacza naszą zgodę na komunikację.


 SIGEND - oznacza koniec komunkacji - jest wysył�any jako odpowiedź
na SIGBEGIN, gdy z jakiegoś powodu nie chemy się komunikowaąć z procesem,
od którego to SIGBEGIN przyszł�o (np.: komunikujemy się w tym czasie z
kimŚś innym); używany też, gdy chcemy zakończyą komunikację już rozpoczętą
-  bo na przykł�ad kończymy dzia�łanie po odebraniu SIGKILL (trzeba
pamiętaćą by w implementacji wysł�anie tego sygnał�u  - oczywiśŚcie
w zależnoŚści od tego, czy w ogóle z kimŚś się komunikujemy - umieŚścićą
zawsze przed wywoł�aniem funkcji do_exit()).


SIGCOMM - sygnał� do przenoszenia informacji - musi byą związane z nim
pole w task_struct typu np.: tablica znakowa, w której będzie zapisywana
treśćŚą wiadomośŚci; wysy�łany naprzemiennie przez proces, który zainicjowa�ł
komunikację oraz proces, z którym się on komunikuje aż do chwili, gdy któryśŚ
z nich wyŚśle SIGEND.



UWAGA: Ten schemat ze względu na fakt, że w Linuxie nie ma kolejkowania
sygna�łów danego typu, nie pozwala na komunikację jednego procesu z kilkoma
innymi jednocześŚnie - mogą zaginąćą na przykł�ad sygna�ły SIGCOMM, gdy
któryśŚ kolejny zdą�y nadejśćŚą zanim obs�użyliŚśmy poprzedni). OczywiŚście
można zaimplementowaćą bardziej skomplikowany (lub byąc może dużo prostszy),
ale bardziej wydajny mechanizm komunikacji wykorzystujący sygna�ły i takie
rozwiązania będą równie� mile widziane.




Autor : Piotr Leśniewski