POSIX pozwala rekursywnym muteksom. Oznacza to, że ten sam wątek może dwa razy zablokować ten sam muteks i nie zablokuje się. Oczywiście musi również odblokować go dwa razy, w przeciwnym razie żaden inny wątek nie może uzyskać muteksu. Nie wszystkie systemy obsługujące pthreads również obsługują rekurencyjne muteksy, ale jeśli chcą być zgodne z POSIX, muszą to zrobić .
Inne interfejsy API (bardziej zaawansowane interfejsy API) również zwykle oferują muteksy, często nazywane Blokadami. Niektóre systemy / języki (np. Cocoa Objective-C) oferują zarówno rekurencyjne, jak i nierekurencyjne muteksy. Niektóre języki oferują tylko jeden lub drugi. Np. W Javie muteksy są zawsze rekurencyjne (ten sam wątek może dwukrotnie „synchronizować” na tym samym obiekcie). W zależności od tego, jakie inne funkcje wątku oferują, brak rekurencyjnych muteksów może nie stanowić problemu, ponieważ można je łatwo napisać samodzielnie (sam już zaimplementowałem rekurencyjne muteksy na podstawie prostszych operacji mutex / warunek).
Czego tak naprawdę nie rozumiem: Do czego służą nierekurencyjne muteksy? Dlaczego miałbym chcieć zablokować wątek, jeśli dwukrotnie blokuje ten sam muteks? Nawet języki wysokiego poziomu, które mogłyby tego uniknąć (np. Sprawdzanie, czy to się zakleszczy i zgłaszanie wyjątku, jeśli tak się dzieje) zwykle tego nie robią. Zamiast tego pozwolą na impas w wątku.
Czy dotyczy to tylko przypadków, w których przypadkowo blokuję go dwukrotnie i odblokowuję tylko raz, a w przypadku rekurencyjnego muteksu trudniej byłoby znaleźć problem, więc zamiast tego mam natychmiastową impas, aby zobaczyć, gdzie pojawia się nieprawidłowa blokada? Ale czy nie mogę zrobić tego samego, gdy licznik zamków jest zwracany podczas odblokowywania iw sytuacji, gdy jestem pewien, że zwolniłem ostatnią blokadę, a licznik nie jest równy zero, mogę zgłosić wyjątek lub zarejestrować problem? Czy jest jakiś inny, bardziej użyteczny przypadek użycia nierekurencyjnych muteksów, których nie widzę? A może to tylko wydajność, ponieważ nierekurencyjny muteks może być nieco szybszy niż rekursywny? Jednak przetestowałem to i różnica nie jest tak duża.