Na poziomie teoretycznym nie różnią się one semantycznie. Możesz zaimplementować muteks za pomocą semaforów lub odwrotnie (zobacz tutaj przykład). W praktyce wdrożenie jest inne i oferują nieco inne usługi.
Praktyczną różnicą (pod względem otaczających je usług systemowych) jest to, że implementacja muteksu ma na celu być lżejszym mechanizmem synchronizacji. W oracle-speak muteksy nazywane są zatrzaskami, a semafory - czekaniami .
Na najniższym poziomie używają pewnego rodzaju testu atomowego i ustawiają mechanizm. Odczytuje bieżącą wartość lokalizacji w pamięci, oblicza pewien warunek i zapisuje wartość w tej lokalizacji w pojedynczej instrukcji, której nie można przerwać . Oznacza to, że możesz zdobyć muteks i przetestować, czy ktoś jeszcze go miał.
Typowa implementacja muteksu ma proces lub wątek wykonujący instrukcję testowania i ustawiania oraz oceniający, czy coś innego ustawiło muteks. Kluczową kwestią jest tutaj brak interakcji z harmonogramem , więc nie mamy pojęcia (i nie obchodzi nas), kto ustawił blokadę. Następnie albo rezygnujemy z wycinka czasu i próbujemy go ponownie, gdy zadanie zostanie ponownie zaplanowane, albo wykonamy blokadę . Blokada spinowa to algorytm taki jak:
Count down from 5000:
i. Execute the test-and-set instruction
ii. If the mutex is clear, we have acquired it in the previous instruction
so we can exit the loop
iii. When we get to zero, give up our time slice.
Po zakończeniu wykonywania naszego chronionego kodu (znanego jako sekcja krytyczna ) po prostu ustawiamy wartość muteksu na zero lub cokolwiek innego, co oznacza „wyczyść”. Jeśli wiele zadań próbuje uzyskać muteks, następne zadanie, które zdarzy się zaplanowane po zwolnieniu muteksu, uzyska dostęp do zasobu. Zazwyczaj używasz muteksów do kontrolowania zsynchronizowanego zasobu, w którym wyłączny dostęp jest potrzebny tylko przez bardzo krótkie okresy, zwykle w celu dokonania aktualizacji wspólnej struktury danych.
Semafor jest zsynchronizowaną strukturą danych (zwykle używającą muteksu), która ma liczbę i niektóre opakowania wywołań systemowych, które oddziałują z harmonogramem na nieco większej głębokości niż biblioteki mutexów. Semafory są zwiększane i zmniejszane i używane do blokowania zadań, dopóki coś innego nie będzie gotowe. Zobacz przykład producenta / konsumenta, aby uzyskać prosty przykład tego. Semafory są inicjowane do pewnej wartości - semafor binarny jest tylko specjalnym przypadkiem, w którym semafor jest inicjowany na 1. Księgowanie na semaforze powoduje przebudzenie procesu oczekiwania.
Podstawowy algorytm semaforów wygląda następująco:
(somewhere in the program startup)
Initialise the semaphore to its start-up value.
Acquiring a semaphore
i. (synchronised) Attempt to decrement the semaphore value
ii. If the value would be less than zero, put the task on the tail of the list of tasks waiting on the semaphore and give up the time slice.
Posting a semaphore
i. (synchronised) Increment the semaphore value
ii. If the value is greater or equal to the amount requested in the post at the front of the queue, take that task off the queue and make it runnable.
iii. Repeat (ii) for all tasks until the posted value is exhausted or there are no more tasks waiting.
W przypadku semafora binarnego główną praktyczną różnicą między nimi jest charakter usług systemowych otaczających faktyczną strukturę danych.
EDYCJA: Jak słusznie zauważył Evan, blokady spinowe spowolnią maszynę z jednym procesorem. Używałbyś tylko spinlocka na pudełku wieloprocesorowym, ponieważ na jednym procesorze proces trzymający muteks nigdy go nie zresetuje, gdy uruchomione jest inne zadanie. Blokady są przydatne tylko w architekturach wieloprocesorowych.