Spis treœci - Patrz

Rozwiązanie poprawneKomunikat opisujący stan systeimi wystarczy rozszerzyć jedynie o liczbę pisarzy, którzyzaczęli czekać podczas czytania. Ponieważ pisarz przetrzymuje komunikat podczas pisania,więc pisarze, którzy w tym czasie zaczęli czekać, nie będą zwiększać tej liczby. Musimy w tymrozwiązaniu zrezygnować z możliwości wielokrotnego czytania podczas jednego obiegukomunikatu. Mogłoby się bowiem zdarzyć, że czytelnik otrzymując komunikat zawsze byłbyzajęty czytaniem. W rezultacie nawet jeden czytelnik mógłby zagłodzić pisarzy.Założenia te oraz połączenie procesów w logiczny pierścień, powoduje że każdy procesw końcu doczeka się na swoją kolej. (To rozwiązanie jest podobne do rozwiązania z przykładu7.2.3. Tam jednak poprawność wynikała z żywotności mechanizmów Lindy, tu natomiast zespecyficznego mechanizmu synchronizacji, jakim jest przekazywanie komunikatu. Jest to więcbardziej sprawiedliwe rozwiązanie.)Pisarz zmienia w krążącym komunikacie liczbę czekających pisarzy tylko wtedy, gdyczytelnicy czytają. Zapamiętuje ten fakt na zmiennej czekam, aby w chwili otrzymaniakomunikatu z zerową liczbą czytających czytelników wiedział, czy ma zmniejszyć liczbęczekających pisarzy.const N = ?;type komunikat = recordc: integer; {liczba czytających czytelników}p: integer; {liczba czekających pisarzy}end;var MOGĘ: array[l..N] of semaphore = (N*0);K: channel;process P(i: 1..N);var pisarz: boolean;beginwhile true do beginpisarz := ...;endend;SEKRETARZ(i).POZWOL(pisarz);P(MOGE[i]);if pisarz then pisanieelse czytanie;SEKRETARZ(i).SKONCZYLEM;wlasne_sprawy{P}{określenie rodzaju procesu}processSEKRETARZ(i: l..N);var kl: komunikat; {do przechowywania komunikatu, gdy pisarz pisze}chcę, czekam, pisarz: boolean;export procedure POZWOL(czy_pisarz: boolean);beginpisarz := czy_pisarz;chcę := trueend; {POZWÓL}export procedure SKOŃCZYŁEM;beginchcę := false;if pisarz then wloz(K, i, kl)end; {SKOŃCZYŁEM}export procedure UPRAWNIENIE(k: komunikat);271