1. Czy powinniśmy dopisać własne funkcje systemowe do IPC?

    Tak, należy dopisać własne funkcje systemowe do serwera IPC.

  2. Jak dużo może być futeksów?

    W serwisie IPC powinna być zdefiniowana odpowiednia stała, określająca maksymalną liczbę blokad futex w systemie. W testach zakładamy, że można stworzyć co najmniej 1024 instancje blokady.

  3. Ile procesów maksymalnie może czekać na futeksie?

    Tyle, ile może być maksymalnie procesów w systemie.

  4. Czy w funkcjach futex_init i futex_destroy mogą pojawiać się wywołania systemowe skierowane do napisanej przez nas części serwera IPC (w przypadku futex_destroy nieuwarunkowane tym, czy ktoś czeka na futeksie)?

    Tak.

  5. Czy gdy tworzymy nasze wywołania systemowe, to musimy też stworzyć funkcje biblioteczne do ich obsługi i gdzieś zapisać? Jeśli tak to gdzie?

    Sensowna wydaje się biblioteka libc, a zwłaszcza miejsce, gdzie zaimplementowane są funkcje związane z SysVIPC: /usr/src/lib/libc/sysvipc

  6. Czy usypianie procesu mamy jakoś sprytnie zaimplementować sami, czy też może można mieć IPC-owskiego mutexa, na którym usypiamy proces dopiero, gdy jest taka potrzeba?

    Należy samodzielnie usypiać proces. Polecam przejrzeć fragment kodu z serwera IPC, który odpowiada za obsługę semaforów i postępować podobnie.

  7. Jak przenieść zmodyfikowane pliki z minixa na linuxa w celu spakowania rozwiązania?

    Na przykład za pomocą polecenia scp z pakietu openssh.

  8. Czy futex może zostać zwolniony przez proces, który nie wywołał na nim funkcji lock?

    Tak.

  9. Czy można korzystać z funkcji sigsuspend z signal.h?

    Nie.

  10. Ponadto w jaki sposób zmierzyć "niepotrzebne aktywne oczekiwanie", to znaczy kiedy aktywne oczekiwanie staje się niepotrzebne?

    Aktywne oczekiwanie staje się niepotrzebne, gdy można zagwarantować poprawność rozwiązania unikając aktywnego oczekiwania w danym miejscu. Oczywiście liczba miejsc, gdzie proces aktywnie oczekuje na cokolwiek, powinna być jak najmniejsza.

  11. Czy możemy założyć, że w systemie jest mniej procesów, niż limit rozmiaru endpoint_t (inta)?

    Typ endpoint_t w każdej chwili może zostać zastąpiony czymś innym (np. long long int) i wtedy blokada nadal powinna działać poprawnie. Można jednak założyć, że procesów w systemie jest mniej, niż 2^(8 * sizeof(endpoint_t)).

  12. Na moim komputerze test numbers.c wykonuje się 3 minuty, w sali 2042 10s, a komuś tam 40 minut. Ile powinno wykonywać sie ten test w komputerze w laboratorium z ustawioną akceleracją, żeby był poprawny?

    Ten test sprawdza bezpieczeństwo, a nie szybkość działania blokady. Jest poprawny, gdy zakończy się wynikiem 0. Oczywiście, gdy będzie wykonywał się zbyt długo (>3min na komputerze w laboratorium 2044 z włączoną akceleracją), to jego wykonanie zostanie przerwane.

  13. Czy funkcje biblioteczne mogą dodatkowo ustawić zmienną errno w przypadku błędu?

    Tak, ale nie jest to wymagane.

  14. Czy należy przejmować się poprawnością działania blokady w przypadku otrzymanego sygnału w trakcie wywołania funkcji bibliotecznych?

    Nie, blokada może wtedy zareagować w dowolny sposób

  15. Jakim wynikiem ma zakończyć się wywołanie futex_destroy po szczęśliwym obudzeniu wszystkich procesów?

    0, o ile futex został zniszczony poprawnie

  16. Czy będzie uznane za błąd, jeśli proces użytkownika poprzez złośliwą modyfikację zawartości struktury futex_t będzie w stanie "popsuć" futex innego procesu bądź spowodować segfault w serwerze IPC?

    Popsucie futeksa innego procesu nie będzie uznane za błąd, ale wywołanie segfaulta (czy jakiegokolwiek innego błędu kończącego proces) w serwerze IPC już tak.