Dlaczego miałbyś używać monitora zamiast semafora?

Obecnie uczęszczam na kurs programowania równoległego na moim uniwersytecie, a ostatnio zaczęliśmy rozmawiać o koncepcji monitora. Chociaż rozumiem potrzebę wzajemnego wykluczenia, nie rozumiem, dlaczego miałbym do tego używać monitora.

Jak rozumiem, monitor gwarantuje, że dokładnie jeden proces lub żaden proces nie znajduje się w sekcji krytycznej przez cały czas. Dokładnie to możemy osiągnąć semaforem. Ponadto wdrażamy monitory (lub przynajmniej jedną możliwością ich wdrożenia) z semaforami.

Dlaczego więc miałbym implementować coś, co robi dokładnie to samo, co semafor z semaforem? Jakie świadczenia otrzymam?

Są prawie wymienne i jedno można zbudować z drugiego. Jest to nieco zależne od języka, który jest implementowany / preferowany (np. Java ma wbudowane monitory za pomocą słowa kluczowego „synchronizuj”). Jednak semafor jest uważany za „niższy poziom” niż monitor z następujących powodów i różnic:

Zarówno monitory, jak i semafory są używane do tego samego celu - synchronizacji wątków. Monitory są jednak prostsze w użyciu niż semafory, ponieważ obsługują wszystkie szczegóły dotyczące pozyskiwania i zwalniania blokady. Aplikacja korzystająca z semaforów musi zwolnić wszelkie blokady, które uzyskał wątek po zakończeniu aplikacji - musi to zrobić sama aplikacja. Jeśli aplikacja tego nie zrobi, żaden inny wątek, który potrzebuje udostępnionego zasobu, nie będzie mógł kontynuować.

Inną różnicą przy korzystaniu z semaforów jest to, że każda procedura dostępu do udostępnionego zasobu musi jawnie uzyskać blokadę przed użyciem tego zasobu. Można to łatwo zapomnieć przy kodowaniu procedur dotyczących wielowątkowości. Monitory, w przeciwieństwie do semaforów, automatycznie uzyskują niezbędne blokady. [1]

Zobacz także wysoko ocenioną odpowiedź Przepełnienie stosu Semafor kontra monitory - jaka jest różnica? z doskonałą / zapadającą w pamięć analogią do publicznych toalet i stojaków na rowery.

W końcu dyskutowaliśmy, dlaczego w dzisiejszym wykładzie miałbyś używać monitora zamiast semafora.

Zasadniczo sprowadza się to do tego: monitor i semafor są równie ekspresyjne, co oznacza, że ​​możesz znaleźć rozwiązanie problemu z monitorem, w którym pierwotnie użyto semafora i odwrotnie.

Cóż, już to wiedzieliśmy, więc dlaczego miałbyś używać monitora zamiast semafora?

Osobiste preferencje. Zwykle aplikacja komputerowa używałaby monitorów, co pozostawia mniej możliwości pomyłek, ale jako kompromis ma relatywnie rozdętą strukturę. Z drugiej strony semafory są często używane w systemach operacyjnych, ponieważ są lekką strukturą, ale pozostawiają więcej możliwości pomyłek.

Sądzę, że możemy stwierdzić, że jest to decyzja sytuacyjna, czy nie potrzebujesz / chcesz użyć monitora lub semafora. Jeśli budujesz system czasu rzeczywistego, możesz chcieć iść z semaforem, jeśli budujesz program biurowy, możesz również iść z monitorem.

Rzuć okiem np. „Mała księga sempaphores”autor: Allen B. Downey. stwierdza i rozwiązuje wiele problemów z synchronizacją. Sprawdź szczególnie nieuczciwe rozwiązania, a zobaczysz, że semafory są mechaizmem na bardzo niskim poziomie, bardzo potężnym, ale niezwykle łatwym do niewłaściwego użycia, w którym proste błędy mają straszne konsekwencje (jeszcze gorsze z powodu nieodłącznego niedeterministycznego działania współbieżnych programów). Łatwo jest np. Zapomnieć o wymuszaniu wzajemnego wykluczenia, operowaniu niewłaściwym semaforem i tak dalej. Monitory oferują paczkowane rozwiązania najczęściej używanych przypadków i niosą ze sobą większość zalet programowania obiektowego (tzn. Wiesz, że jedynym sposobem na bałagan ze zmiennymi zarządzanymi przez monitor są jego operacje). Wadą jest to, że nie można ich łatwo zainstalować w językach innych niż zorientowane obiektowo,