Планирование потоков в unix

Question

В политике планирования RR, что произойдет, если поток с низким приоритетом блокирует мьютекс и удаляется планировщиком, потому что ожидает еще один высокоприоритетный поток?

Будет ли он также выпускать блокировку, удерживаемую резьбой с низким приоритетом?

Например, рассмотрите 3 потока, выполняющихся в процессе с приоритетами 10,20 и 30 в политике планирования RR.

Теперь в данный момент времени ничтожный приоритет нитки 1 блокирует мьютексы и все еще выполняет среднее выполнение, в то время как поток с высоким приоритетом всплывает, а также ожидает мьютекс, удерживаемый нитью 1. Теперь поток 2 приходит к картине, которая также нуждается в тот же мьютекс, заблокированный нитью 1.

Насколько я знаю, согласно алгоритму планирования потоки, спящие или ожидающие мьютекс, семафор и т. д., удаляются, а другие, даже имеющие низкий приоритет, могут выполняться. Это верно? Если это так, в приведенном выше примере в конечном счете потоки с высоким приоритетом ожидают завершения потока с низким приоритетом, что не имеет никакого смысла. Как работает система, если на всех потоках сконструированы, как я уже говорил выше?

или приоритет потока должен быть установлен таким образом, чтобы приоритет приоритета не зависел от мьютекса с низким приоритетом?

Также может кто-нибудь объяснить мне, как планирование работает на уровне процесса? Как установить приоритет для процесса?

Answer 1

Как правило, планирование и блокировки не связаны ни в каком другом аспекте, кроме как «ожидающий поток не запланирован, пока он не будет завершен». Было бы довольно глупо иметь MUTEX, который «останавливает доступ другого потока к моим данным», но он работает только в том случае, если другой поток имеет тот же или более низкий приоритет, чем текущий поток.

Явления с «низким приоритетом» содержат блокировку, требующую высокой приоритетности потока », называется инверсией приоритета, и это хорошо известный сценарий в компьютерной теории.

Существует несколько схем, которые «временно увеличивают приоритет фиксирующего потока, пока он не освободит блокировку до наивысшего приоритета ожидающих потоков» (или приоритет первого потока ожидания, если он выше текущего потока, или некоторые другие варианты этой темы). Это делается для борьбы с инверсией приоритета, но у него есть и другие недостатки, поэтому он не реализован во всех ОС/планировщиках (в конце концов, он влияет на другие потоки, кроме того, который тоже ожидает).

Редактировать:

Точка взаимной блокировки (или других подобных замков) является то, что он предотвращает два потока от доступа те же ресурсы одновременно. Например, предположим, что мы хотим обновить пять разных переменных с довольно длинной обработкой (сложная математика, выборка данных из последовательного порта или сетевого диска или некоторые из них), но если мы выполняем только две переменные, некоторые другие процессы используют они получили бы недействительный результат, тогда мы явно не можем «отпустить» блокировку.

В потоке с высоким приоритетом просто нужно дождаться обновления всех пяти переменных и блокировки с низким приоритетом.

Нет простого способа обхода, который приложение может выполнить для «исправления» этой проблемы - не держите блокировки больше, чем необходимо, конечно [и, возможно, мы можем исправить описанную выше проблему, выполнив длительная обработка ВЗЛЫ блокировки, и только сделать окончательный «сохранить его в 5 переменных» с блокировкой. Это уменьшит потенциальное время, в течение которого поток с высоким приоритетом должен ждать, но если система действительно занята, это не решит проблему.

На эту тему написана целая кандидатская диссертация, и я не специалист по «составлению планировщика». У меня есть справедливое представление о том, как работает, точно так же, как я знаю, как работает двигатель в моей машине - но если кто-то дал мне кучу подходящих базовых форм из стали и алюминия, а также необходимые инструменты/рабочее пространство и сказал мне, чтобы я построил двигатель, я сомневаюсь, что он отлично поработает ... То же самое с планировщиком - я знаю, какие части называются, но не как их построить.

Answer 2

Если поток с высоким приоритетом должен ждать по потоку с низким приоритетом (семафором мьютекса и т. Д.), Поток с низким приоритетом временно повышается до того же приоритета, что и поток с высоким приоритетом.

Answer 3

В потоке с высоким приоритетом не будет блокировки, для которой он запрашивает, пока нить низкого приоритета не разблокирует его.

Чтобы избежать этого, мы можем использовать семафор, где любой другой поток может инициировать разблокировку, но в мьютексе это невозможно.