Zadanie

Wstęp

Sygnały majš dwie wady, które utrudniajš ich wykorzystanie przy komunikacji procesów:

• Nie wiadomo kto wysłał sygnał
• Nie wiadomo ile razy sygnał został wysłany

Przy istniejšcych sygnałach (używanych przez system) nie jest to zbytnio kłopotliwe, ponieważ sš one wykorzystywane akurat w takich sytuacjach, gdzie taka wiedza jest zbyteczna. Można by jednak wzbogacić w ten sposób sygnał użytkownika.

Zadanie

Zmodyfikować obsługę jednego z sygnałów użytkownika (np. SIGUSR1) w następujšcy sposób:

- proces p1, który wysyła sygnał SIGUSR1 do procesu p2 sprawdza, czy p2 już taki sygnał odebrał:

• jeżeli proces p2 odebrał uprzednio sygnał i nie zdšżył go obsłużyć, proces p1 zawiesza się.
• w przeciwnym przypadku proces p1 normalnie wysyła sygnał

- kiedy proces p2 kończy obsługę sygnału SIGUSR1, sprawdza czy sš procesy czekajšce na wysłanie do niego sygnału. Jeżeli sš, pozawala jednemu na wysłanie sygnału.

Szkic rozwišzania

Należy zmodyfikować następujšce funkcje:

generate w pliku exit.c: Jeżeli sygnał wysyłany to SIGUSR1, funkcja powinna sprawdzić, czy odpowiedni bit p->signal jest ustawiony. Jeżeli jest, należałoby zatroszczyć się o zawieszenie procesu current

jednš z funkcji obsługujšcych otrzymywanie sygnałów w "sprzętowym" signal.c, np. handle_signal: Należy wprowadzić odwieszanie procesów po obsłudze sygnału

Rzeczy, na które należy zwrócić uwagę:

• Czy proces jest zawieszany TASK_INTERRUPTIBLE, czy też TASK_UNINTERRUPTIBLE? W pierwszym przypadku wysłanie sygnału może się, przy pewnej implementacji, nie udać(proces wysyła sygnał, ale musi czekać, i wówczas jest budzony przez inny sygnał).
• Czy jest jedna kolejka, na której zawieszajš się procesy chcšce wysłać sygnał do jakiegokolwiek procesu, czy też każdy proces ma "swojš" kolejkę
• Jeżeli budzimy wszystkie procesy czekajšce, należy rozwišzać problem z dziedziny programowania współbieżnego: co by było gdyby dwa procesy najpierw sprawdziły, że mogš wysłać sygnał, a potem razem go wysłały (można rozwišzać blokujšc przerwania)
• Sygnał SIGUSR1, wbrew nazwie, nie jest tak zupełnie sygnałem użytkownika. Może z niego korzystać system (np. wštki)

Wersja trudniejsza

Jak już mamy jednoznacznš odpowiedniosć między wysłaniem sygnału a jego odebraniem, możemy umożliwić identyfikację procesu wysyłajšcego sygnał, wprowadzajšc np. nowš funkcję systemowš: int sys_whosent(struct task_struct *p), która zwraca pid procesu, który przysłał sygnał, lub błšd, kiedy nie ma ustawionego bitu w polu signal. Funkcja taka mogłaby być wywoływana przez handlera sygnału.

Testy

Testy raczej sprawdzałyby działanie nowego mechanizmu niż sprawdzały jak bardzo jest efektywny. Możnaby np. uruchomić proces, który blokuje sygnał SIGUSR1, a następnie sprawdzić, czy procesy wysyłajšce do niego sygnał istotnie się zawieszajš.