Jak zapobiegać głodom wątków w C++ 11

Question

Zastanawiam się tylko, czy istnieje polityka blokowania w C++ 11, która zapobiegnie głodom wątków.

Mam wiele wątków, które rywalizują o jeden mutex. Teraz mój problem polega na tym, że wątek, który opuszcza krytyczną sekcję, zaczyna natychmiast rywalizować o ten sam muteks i przez większość czasu wygrywa. Dlatego też inne wątki oczekujące na muteks są głodne.

Nie chcę, aby wątek, pozostawiając krytyczną sekcję, spał przez jakiś minimalny czas, aby inne wątki mogły zablokować muteks.

Pomyślałem, że musi istnieć jakiś parametr, który umożliwiłby uczciwe blokowanie wątków oczekujących na muteksie, ale nie byłem w stanie znaleźć żadnego odpowiedniego rozwiązania.

Znalazłem funkcję std :: this_thread :: yield(), która zakłada zmianę harmonogramu wykonywania wątków, ale jest to tylko wskazówka dla wątku harmonogramu i zależy od implementacji wątku harmonogramu, jeśli przestawia wątki, czy nie.

Czy istnieje sposób zapewnienia sprawiedliwego zamknięcia dla wątków oczekujących na ten sam muteks w C++ 11? Jakie są zwykle stosowane strategie?

Dzięki

Answer 1

Jest to wspólna optymalizacja muteksy zaprojektowane, aby uniknąć marnowania czasu przełączania zadań, gdy ten sam wątek może zająć mutex ponownie. Jeśli bieżący wątek nadal pozostawia czas w swoim wycinku czasu, to uzyskujesz większą przepustowość w kategoriach instrukcji użytkownika wykonywanych na sekundę, pozwalając mu pobrać muteks zamiast zawieszać go i przełączając się na inny wątek (co prawdopodobnie powoduje duże przeładowanie linii pamięci podręcznej i różne inne opóźnienia).

Jeśli masz tyle sporów na muteksie, że to jest problem, to twój projekt aplikacji jest nieprawidłowy. Wszystkie te wątki są blokowane na muteksie, a zatem nie robią nic: prawdopodobnie lepiej będzie bez tak wielu wątków.

Powinieneś zaprojektować aplikację, aby w przypadku, gdy wiele wątków konkurowało o muteks, nie ma znaczenia, który wątek uzyska blokadę. Bezpośrednia rywalizacja powinna być również rzadkością, szczególnie bezpośrednim sporem z wieloma wątkami.

Jedyną sytuacją, w której mogę myśleć, że jest to scenariusz OK, to sytuacja, w której każdy wątek czeka na zmienną warunku, która jest następnie nadawana, aby obudzić je wszystkie. Każdy wątek będzie walczył o muteks, ale jeśli robisz to dobrze, wszyscy powinni szybko sprawdzić, czy nie jest to fałszywy ślad, a następnie zwolnić muteks. Nawet wtedy jest to nazywane sytuacją "grzmiącego stada" i nie jest idealne, właśnie dlatego, że serializuje wszystkie te wątki.