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