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