Jak na tym article:Dlaczego blokowanie std :: mutex dwa razy "Niezdefiniowane zachowanie"?
Jeśli spróbujesz i zablokować nierekursywnych mutex dwa razy z tego samego wątku bez odblokowywania pomiędzy, masz niezdefiniowane zachowanie.
Mój bardzo naiwny umysł mówi mi, dlaczego po prostu nie zwróci błędu? Czy istnieje powód, dla którego to musi być UB?
Ponieważ nigdy nie dzieje się w poprawnym programie, a sprawdzenie czegoś, co nigdy się nie dzieje, jest marnotrawstwem (i aby to sprawdzić, musi przechowywać własny identyfikator wątku, który również jest nieekonomiczny).
Należy pamiętać, że nieokreślony umożliwia implementacjom debugowania zgłaszanie wyjątku, na przykład, przy jednoczesnym zapewnieniu maksymalnej wydajności wydania.
dobre A, ale tbh Myślę, że dobre wdrożenia dbg powinny twierdzić, ponieważ ppl czasami: P pisać kod, który zjada wyjątki bez robienia dużo hałasu. :RE – NoSenseEtAl
Niezdefiniowane zachowanie pozwala implementacjom robić to, co jest najszybsze/najwygodniejsze. Na przykład wydajna implementacja nierekurencyjnego muteksu może być pojedynczym bitem, w którym operacja blokowania jest realizowana za pomocą atomowej instrukcji porównania i wymiany w pętli. Jeśli wątek będący właścicielem muteksu próbuje zablokować go ponownie, spowoduje to zakleszczenie, ponieważ oczekuje na odblokowanie muteksa, ale ponieważ nikt inny nie może go odblokować (chyba że jest jakiś inny błąd, w którym jakiś wątek, który nie jest jego właścicielem, odblokowuje go) wątek będzie czekać na zawsze.
Być może chcesz użyć atomic_flag z domyślną kolejnością pamięci. Nie ma wyścigów danych i nigdy nie rzuca wyjątków, takich jak mutex w przypadku wielu połączeń odblokowujących (i przerywa w niekontrolowany sposób, dodam ...). Alternatywnie, istnieje atomowa (na przykład atomowa [bool] lub atomowa [int] (z nawiasami trójkątnymi, nie [])), która ma ładne funkcje, takie jak load i compare_exchange_strong. http://www.cplusplus.com/reference/atomic/atomic_flag/ http://www.cplusplus.com/reference/atomic/atomic/ – Andrew
Również ponieważ 'mutex' może być zaimplementowany z natywnym muteksem systemu OS, to nie ma sensu, aby nie definiować, co może być różne w różnych systemach operacyjnych, tak aby 'std :: mutex' mogło być cienkim opakowaniem dla systemu operacyjnego zawierającego mutex. – Phil1970