Planowanie wątków w systemie UNIX

Question

Co się stanie, jeśli wątek o niskim priorytecie blokuje muteks w strategii planowania RR, co spowoduje, że wątek zostanie usunięty przez program planujący, ponieważ oczekuje na to inny wątek o wysokim priorytecie?

Czy zwolni również blokadę z wątku o niskim priorytecie?

Przykładowo rozważ 3 wątki działające w procesie z priorytetami 10,20 i 30 w strategii planowania RR.

Teraz w danym momencie wątek o niskim priorytecie 1 blokuje mutex i nadal wykonuje operację, podczas gdy wątek o wysokim priorytecie pojawia się i czeka również na muteksie trzymanym przez wątek 1. Teraz wątek 2 pojawia się w obrazie, który również potrzebuje ten sam muteks zablokowany przez wątek 1.

O ile wiem, zgodnie z algorytmem szeregowania, wątki śpiące lub czekające na muteks, semafor itp. są usuwane, a pozostałe, nawet o niskim priorytecie, mogą być wykonywane. Czy to jest poprawne? Jeśli tak, w powyższym przykładzie wątki o najwyższym priorytecie czekają na zakończenie wątku o niskim priorytecie, co nie ma żadnego sensu. Czy tak działa system, jeśli wszystkie wątki są zaprojektowane tak jak powiedziałem powyżej?

lub priorytet wątku należy ustawić w taki sposób, aby jego wysoki priorytet nie był zależny od mutexe użytkownika o niskim priorytecie?

Czy ktoś może mi wyjaśnić, jak działa harmonogram na poziomie procesu? Jak ustawić priorytet dla procesu?

Answer 1

Zazwyczaj planowanie i blokady nie mają związku z żadnym innym aspektem niż "oczekujący wątek nie jest zaplanowany, dopóki nie zakończy się oczekiwanie". Byłoby raczej głupio mieć MUTEX, który "zatrzymuje inny wątek przed dostępem do moich danych", ale działa tylko wtedy, gdy drugi wątek ma taki sam lub niższy priorytet niż bieżący wątek.

Zjawisko "niskiego priorytetu jest blokadą, której wymaga wątek o wysokim priorytecie" "nazywa się inwersją priorytetów i jest to dobrze znany scenariusz w teorii komputerowej.

Istnieje kilka schematów, które "tymczasowo zwiększają priorytet wątku wstrzymującego blokadę, aż zwolnią blokadę do najwyższego priorytetu oczekujących wątków" (lub priorytet pierwszego oczekującego wątku, jeśli jest wyższy niż bieżący wątek, lub inne odmiany tego tematu). Odbywa się to w celu przeciwdziałania inwersji priorytetów - ale ma też inne wady, więc nie jest zaimplementowane we wszystkich systemach operacyjnych/planistach (w końcu wpływa na inne wątki niż ten, który również czeka).

Edit:

Punktem mutex (lub innych podobnych zamków) jest to, że zapobiega dwa wątki dostęp do tych samych zasobów na raz. Na przykład, powiedzmy, że chcemy zaktualizować pięć różnych zmiennych za pomocą dość długiego przetwarzania (skomplikowana matematyka, pobieranie danych z portu szeregowego lub dysku sieciowego, lub niektórych takich), ale jeśli robimy tylko dwie zmienne, niektóre inne procesy wykorzystują te otrzymają nieprawidłowy wynik, wtedy wyraźnie nie możemy "puścić" blokady.

Wątek o wysokim priorytecie musi po prostu poczekać na zaktualizowanie wszystkich pięciu zmiennych i blokadę o niskim priorytecie.

Nie ma prostego rozwiązania, które aplikacja może zrobić, aby "rozwiązać" ten problem - nie trzymaj zamków bardziej, niż to konieczne oczywiście [i może być tak, że faktycznie możemy rozwiązać problem opisany powyżej, wykonując długotrwałe przetwarzanie ZEWNĘTRZNE od zamka i wykonanie tylko końcowego "zapisz go w 5 zmiennych" przy włączonej blokadzie. Zredukuje to potencjalny czas oczekiwania wątku o wysokim priorytecie, ale jeśli system jest naprawdę zajęty, tak naprawdę nie naprawi problemu.

Na ten temat napisałem całą rozprawę doktorską i nie jestem specjalistą od "pisania harmonogramu" - mam dobry pomysł, jak działa, tak jak wiem, jak działa silnik w moim samochodzie - ale jeśli ktoś dał mi garść odpowiednich podstawowych kształtów ze stali i aluminium oraz wymaganych narzędzi/obszaru roboczego i powiedział mi, żebym zbudował silnik, wątpię by działał świetnie ... To samo z harmonogramem - wiem, jakie części są wywoływane, ale nie jak je zbudować.

Answer 2

Jeśli wątek o wysokim priorytecie musi czekać na wątek o niskim priorytecie (semafor mutex itp.), Wątek o niskim priorytecie jest tymczasowo podniesiony do tego samego priorytetu co wątek o wysokim priorytecie.

Answer 3

Wątek o wysokim priorytecie nie będzie miał blokady, o którą prosi, dopóki wątek o niskim priorytecie go nie odblokuje.

Aby tego uniknąć, możemy użyć semafora, w którym każdy inny wątek może zainicjować odblokowanie, ale w muteksie nie jest to możliwe.