Blokada rekurencyjna (Mutex) vs Blokada nierekurencyjna (Mutex)

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.

Różnica między rekursywnym i nierekurencyjnym muteksem ma związek z własnością. W przypadku rekurencyjnego muteksu jądro musi śledzić wątek, który faktycznie uzyskał muteks za pierwszym razem, aby mógł wykryć różnicę między rekurencją a innym wątkiem, który powinien zamiast tego zablokować. Jak wskazano w innej odpowiedzi, pojawia się pytanie o dodatkowe koszty związane z pamięcią do przechowywania tego kontekstu, a także o cykle wymagane do jego utrzymania.

W grę wchodzą jednak także inne względy.

Ponieważ rekurencyjny muteks ma poczucie własności, wątek, który chwyta muteks, musi być tym samym wątkiem, który uwalnia mutex. W przypadku nierekurencyjnych muteksów nie ma poczucia własności i każdy wątek może zwykle uwolnić muteks bez względu na to, który wątek pierwotnie wziął muteks. W wielu przypadkach ten rodzaj „muteksu” jest w rzeczywistości bardziej działaniem semaforowym, w którym niekoniecznie używasz muteksu jako urządzenia wykluczającego, ale używasz go jako urządzenia synchronizującego lub sygnalizującego między dwoma lub więcej wątkami.

Inną właściwością, która ma poczucie własności w muteksie, jest możliwość wspierania dziedziczenia priorytetowego. Ponieważ jądro może śledzić wątek będący właścicielem muteksu, a także tożsamość wszystkich programów blokujących, w systemie z priorytetowym wątkiem możliwe jest zwiększenie priorytetu wątku, który obecnie jest właścicielem muteksu, do priorytetu wątku o najwyższym priorytecie który obecnie blokuje muteks. Dziedziczenie zapobiega problemowi inwersji priorytetów, który może wystąpić w takich przypadkach. (Pamiętaj, że nie wszystkie systemy obsługują dziedziczenie priorytetowe w takich muteksach, ale jest to kolejna funkcja, która staje się możliwa dzięki pojęciu własności).

Jeśli odwołujesz się do klasycznego jądra VxWorks RTOS, definiują one trzy mechanizmy:

• mutex - obsługuje rekurencję i opcjonalnie dziedziczenie priorytetowe. Ten mechanizm jest powszechnie stosowany do spójnej ochrony krytycznych części danych.
• semafor binarny - bez rekurencji, bez dziedziczenia, zwykłe wykluczenie, biorca i dawca nie musi być tym samym wątkiem, dostępna wersja transmisji. Ten mechanizm może być używany do ochrony krytycznych sekcji, ale jest również szczególnie przydatny do spójnej sygnalizacji lub synchronizacji między wątkami.
• liczenie semaforów - brak rekurencji lub dziedziczenia, działa jak spójny licznik zasobów od dowolnej pożądanej początkowej liczby, blokuje tylko wątki, w których liczba netto względem zasobu wynosi zero.

Ponownie, różni się to nieco w zależności od platformy - szczególnie jak nazywają te rzeczy, ale powinno to być reprezentatywne dla pojęć i różnych mechanizmów w grze.

Odpowiedź to nie wydajność. Muteksy niezwiązane z rejestracją prowadzą do lepszego kodu.

Przykład: A :: foo () przejmuje blokadę. Następnie wywołuje B :: bar (). To działało dobrze, kiedy to napisałeś. Ale jakiś czas później ktoś zmienia B :: bar (), aby wywołać A :: baz (), który również uzyskuje blokadę.

Cóż, jeśli nie masz rekurencyjnych muteksów, to impas. Jeśli je masz, działa, ale może się zepsuć. A :: foo () mógł pozostawić obiekt w niespójnym stanie przed wywołaniem bar (), przy założeniu, że baz () nie może zostać uruchomiony, ponieważ również nabywa muteks. Ale to chyba nie powinno działać! Osoba, która napisała A :: foo () założyła, że ​​nikt nie może wywołać A :: baz () w tym samym czasie - to jest cały powód, dla którego obie metody uzyskały blokadę.

Właściwy model mentalny do używania muteksów: Muteks chroni niezmiennika. Gdy muteks jest trzymany, niezmiennik może się zmienić, ale przed zwolnieniem muteksu niezmiennik zostaje ponownie ustanowiony. Blokady ponownego wysyłania są niebezpieczne, ponieważ przy drugim zakupie blokady nie możesz być już pewien, że niezmiennik jest prawdziwy.

Jeśli jesteś zadowolony z blokad ponownego wysyłania, to tylko dlatego, że nie musiałeś wcześniej debugować takiego problemu. Nawiasem mówiąc, Java ma obecnie blokadę bez ponownej rejestracji w java.util.concurrent.locks.

Jak napisał sam Dave Butenhof :

„Największy ze wszystkich dużych problemów z rekurencyjnymi muteksami polega na tym, że zachęcają cię do całkowitego zejścia z planu blokowania i zakresu. To jest śmiertelne. Zło. To„ zjadacz nici ”. Trzymasz zamki przez możliwie najkrótszy czas. Okres. Zawsze. Jeśli dzwonisz z blokadą trzymaną tylko dlatego, że nie wiesz, czy blokada jest zablokowana, lub ponieważ nie wiesz, czy odbiorca potrzebuje muteksu, to trzymasz go zbyt długo. celowanie strzelbą w aplikację i pociągnięcie za spust. Prawdopodobnie zacząłeś używać wątków, aby uzyskać współbieżność, ale właśnie ZAPOBIEGAŁeś współbieżności. ”

Właściwy model mentalny do używania muteksów: Muteks chroni niezmiennika.

Dlaczego jesteś pewien, że to naprawdę właściwy model mentalny do używania muteksów? Myślę, że odpowiedni model chroni dane, ale nie niezmienniki.

Problem ochrony niezmienników występuje nawet w aplikacjach jednowątkowych i nie ma nic wspólnego z wielowątkowością i muteksami.

Ponadto, jeśli chcesz chronić niezmienniki, nadal możesz użyć binarnego semafora, który nigdy nie jest rekurencyjny.

Jednym z głównych powodów, dla których rekurencyjne muteksy są przydatne, jest wielokrotne uzyskiwanie dostępu do metod przez ten sam wątek. Powiedzmy na przykład, że jeśli blokada mutex chroni bank A / c przed wypłatą, to jeśli z wypłatą wiąże się również opłata, należy zastosować ten sam mutex.

Jedynym dobrym przypadkiem użycia muteksu rekurencyjnego jest sytuacja, gdy obiekt zawiera wiele metod. Gdy dowolna z metod modyfikuje zawartość obiektu, a zatem musi zablokować obiekt, zanim stan będzie znów spójny.

Jeśli metody używają innych metod (np .: addNewArray () wywołuje metodę addNewPoint () i kończy się poleceniem recheckBounds ()), ale każda z tych funkcji musi sama zablokować muteks, rekurencyjny muteks jest korzystny dla wszystkich.

W każdym innym przypadku (rozwiązanie po prostu złego kodowania, użycie go nawet w różnych obiektach) jest wyraźnie błędne!

Do czego służą nierekurencyjne muteksy?

Są absolutnie dobre, gdy musisz upewnić się, że mutex jest odblokowany przed zrobieniem czegoś. Jest tak, ponieważ pthread_mutex_unlockmoże zagwarantować, że muteks zostanie odblokowany tylko wtedy, gdy nie będzie rekurencyjny.

pthread_mutex_t      g_mutex;

void foo()
{
    pthread_mutex_lock(&g_mutex);
    // Do something.
    pthread_mutex_unlock(&g_mutex);

    bar();
}

Jeśli g_mutexnie jest rekurencyjny, powyższy kod gwarantuje wywołanie bar()przy odblokowanym muteksie .

W ten sposób eliminuje się możliwość zakleszczenia w przypadku bar(), gdy zdarza się, że jest to nieznana funkcja zewnętrzna, która może zrobić coś, co może spowodować, że inny wątek będzie próbował uzyskać ten sam muteks. Takie scenariusze nie są rzadkie w aplikacjach zbudowanych na pulach wątków oraz w aplikacjach rozproszonych, w których wywołanie międzyprocesowe może odrodzić nowy wątek, nawet jeśli programista klienta nawet tego nie zauważy. We wszystkich takich scenariuszach najlepiej jest wywoływać wspomniane funkcje zewnętrzne dopiero po zwolnieniu blokady.

Gdyby g_mutexbyło rekurencyjne, po prostu nie byłoby sposobu, aby upewnić się, że jest odblokowane przed wykonaniem połączenia.