Monitor (programowanie współbieżne)

Monitor – obiekt, który może być bezpiecznie używany przez kilka wątków. Metody monitora chronione są przez muteksy, przez co w dowolnym momencie czasowym z dowolnej metody może korzystać tylko jeden wątek naraz. Upraszcza to budowę obiektów, zwalniając programistę z konieczności implementacji skomplikowanych wykluczeń.

Monitory umożliwiają także wątkom czasowe zwolnienie wyłącznego dostępu podczas oczekiwania na spełnienie jakiegoś warunku. W tym czasie inny wątek może bezpiecznie wykonać swoje zadanie, a gdy warunek zostanie spełniony, poprzedni wątek z powrotem przejmie wyłączną kontrolę i dokończy pracę. Dwa wątki mogą także sygnalizować sobie, że warunek został spełniony.

Monitory zostały wynalezione przez C.A.R. Hoare’a oraz Pera Brinch Hansena i zostały po raz pierwszy zaimplementowane w języku Concurrent Pascal.

Wzajemne wykluczanie

Klasa obsługująca konto bankowe:

monitor class Konto {
  private int stan := 0
  invariant stan >= 0

  public method boolean pobierz(int kwota)
  {
    if kwota < 0 then error "Kwota nie może być ujemna"
    else if stan < kwota then return false
    else { stan := stan - kwota ; return true }
  }

  public method wplac(int kwota) {
    if kwota < 0 then error "Kwota nie może być ujemna"
    else stan := stan + kwota
  }
}

O wątku wykonującym metodę monitora mówimy, że zajmuje on monitor. Monitory projektowane są w taki sposób, aby w dowolnej chwili co najwyżej jeden wątek mógł je zajmować. Zapewnia to właściwość wzajemnego wykluczania.

Gdy wątek próbuje wywołać metodę monitora, musi zaczekać, dopóki inny wątek nie skończy swojej pracy na obiekcie. Zauważmy, że gdyby w podanym przykładzie zezwolić dwóm wątkom na jednoczesne wykonywanie pobierz(), aby pobrać kwotę 1000 zł, właściciel konta mógłby zyskać pieniądze bez żadnego powodu. Każdy z wątków pobrałby najpierw aktualny stan konta, zmniejszył go o 1000 zł, a następnie zapisał z powrotem do pola kwota, nie wiedząc, że dokładnie w tym samym czasie drugi zrobił identyczną operację. Ostatecznie pomimo pobrania łącznie 2000 złotych na koncie stwierdzilibyśmy ubytek połowy tej sumy.

W najprostszej implementacji wzajemne wykluczanie musi być zapewnione przez kompilator, co sprowadza się zazwyczaj do dodania do każdego obiektu monitora semafora, który początkowo jest podniesiony. Program opuszcza go automatycznie, gdy jakiś wątek próbuje wywołać metodę i podnosi z powrotem, gdy z metody wychodzi.

Oczekiwanie na warunki

W wielu sytuacjach wzajemne wykluczanie nie wystarcza. Wątki próbujące wykonać pewną operację mogą wymagać zaczekania na spełnienie określonego warunku $P,$ aby móc kontynuować. Zwykłe aktywne czekanie przy pomocy pętli nie wystarcza:

while not (P) do pomiń

Wątek w dalszym ciągu zajmuje monitor, przez co nikt inny nie ma szans na zmianę jego stanu i spełnienie warunku. Rozwiązaniem są zmienne warunkowe. Zmienna warunkowa $c$ jest kolejką wątków przypisaną do monitora, które oczekują na jakiś skojarzony z nią przez programistę warunek $P_{c}.$ Uznaje się, że wątki znajdujące się w kolejce nie zajmują monitora, dzięki czemu inny wątek może wykonać na nim operację, dzięki której $P_{c}$ stanie się prawdziwe. W większości implementacji ma on dodatkowo możliwość powiadomienia wątków z kolejki, że warunek został spełniony i mogą one wznowić swoje wykonywanie.

Zmienne warunkowe muszą udostępniać dwie podstawowe operacje:

• czekaj na c (ang. wait) – wywoływana przez wątek, który chce zaczekać na spełnienie warunku $P_{c}.$ W trakcie oczekiwania nie zajmuje on monitora i nazywany jest wątkiem oczekującym.
• powiadom c (ang. signal lub notify) – wywoływana przez wątek, aby powiadomić czekające wątki, że $P_{c}$ został spełniony. Nazywamy go wątkiem powiadamiającym.

Zmienne warunkowe z blokowaniem

Oryginalne prace C.A.R. Hoare’a oraz Pera Brinch Hansena proponowały zmienne warunkowe z blokowaniem. Monitory pracujące w ten sposób są często nazywane monitorami Hoare’a.

W zmiennych warunkowych z blokowaniem wątek powiadamiający jest blokowany do czasu, aż powiadomiony wątek oczekujący nie opuści monitora lub nie zatrzyma się w ponownym oczekiwaniu na warunek.

Zakładamy, że występują dwie główne kolejki wątków:

• e jest kolejką wejściową.
• s jest kolejką wątków powiadamiających.

Ponadto każda zmienna warunkowa $C$ posiada własną kolejkę $C.q$ wątków oczekujących na spełnienie warunku. Zazwyczaj gwarantuje się uczciwość obu kolejek (tzn. wchodzący do nich wątek nie będzie wybierany w nieskończoność, co głodziłoby pozostałe).

Poniżej przedstawione są implementacje poszczególnych operacji monitora. Zakładamy, że są one wykonywane atomowo:

wejście do monitora: wejdź do metody jeśli monitor jest zajęty dodaj obecny wątek do $e$ w przeciwnym wypadku zajmij monitor

opuszczenie monitora: przełącz opuść metodę

czekaj na $C{:}$ dodaj obecny wątek do $C.q$ przełącz zablokuj obecny wątek

powiadom $C{:}$ jeśli jest wątek czekający w $C.q$ wybierz i usuń z kolejki dowolny wątek $t$ dodaj obecny wątek do $s$ odblokuj $t$ zablokuj obecny wątek

Komenda przełącz wybiera z kolejki następny wątek, który zajmie monitor, a jeśli jest ona pusta, odblokowuje go:

przełącz: jeśli jest wątek w kolejce $s$ wybierz ten wątek, usuń go z kolejki i odblokuj jeśli jest wątek w kolejce $e$ wybierz ten wątek, usuń go z kolejki i odblokuj w przeciwnym wypadku zwolnij monitor

W powyższej implementacji każdy wątek powiadamiający natychmiast się zatrzymuje, lecz ma gwarantowany priorytet przy przełączaniu. Alternatywne podejście zakłada brak kolejki $s$ i oczekiwanie w $e$ po wysłaniu powiadomienia.

Czasami stosuje się także dodatkową operację powiadom i zakończ, aby nie blokować niepotrzebnie wątku, który nie ma w monitorze już nic do zrobienia i pozostaje mu tylko wyjść. Łączy ona powiadamianie oraz wyjście z metody monitora.

Zmienne warunkowe bez blokowania

W zmiennych warunkowych bez blokowania operacja powiadom nie powoduje opuszczenia monitora. Zamiast tego wątek oczekujący jest przenoszony do kolejki $e,$ aby zaczekać, aż wątek powiadamiający zakończy swoje zadanie. Kolejka $s$ jest niepotrzebna. Czasami dodaje się dodatkową operację powiadom wszystkie, która przenosi wszystkie oczekujące wątki do $e.$

Poniżej przedstawione są implementacje poszczególnych operacji monitora. Zakładamy, że są one wykonywane atomowo:

wejście do monitora: wejdź do metody jeśli monitor jest zajęty dodaj obecny wątek do $e$ w przeciwnym wypadku zajmij monitor

opuszczenie monitora: przełącz opuść metodę

czekaj na $C{:}$ dodaj obecny wątek do $C.q$ przełącz zablokuj obecny wątek

powiadom $C{:}$ jeśli jest wątek czekający w $C.q$ wybierz i usuń z kolejki dowolny wątek $t$ dodaj $t$ do kolejki $e$

powiadom wszystkie $C{:}$ przenieś wszystkie wątki z $C.q$ do kolejki $e$

przełącz: jeśli jest wątek w kolejce $e$ wybierz ten wątek, usuń go z kolejki i odblokuj w przeciwnym wypadku zwolnij monitor

Jako modyfikację proponuje się utworzenie kolejki $w,$ do której przenoszone są wątki w ramach operacji powiadom i powiadom wszystkie i która ma zagwarantowane pierwszeństwo przed $e$.

Monitory z niejawnym warunkiem

W języku Java każdy obiekt może stać się monitorem, przy czym metody, których dotyczy wykluczanie, muszą być oznaczone modyfikatorem synchronized. Zamiast udostępniać jawne zmienne warunkowe, każdy monitor wyposażony jest w pojedynczą kolejkę obok kolejki wejściowej. Wszystkie operacje dotyczą tej jednej kolejki, co pozwala skojarzyć z monitorem co najwyżej jeden warunek. Aby zastosować więcej zmiennych warunkowych, należy ręcznie dodać do klasy obiekt Lock i przy jego pomocy utworzyć odpowiednią liczbę zmiennych. Programista musi wtedy samodzielnie zajmować się wywołaniem odpowiednich operacji przy wchodzeniu i opuszczaniu monitora.

Identyczne podejście zostało zaimplementowane także w innych językach, jak np. C#.