Существуют ли случаи, когда приоритетное наследование нежелательно?

Ответ 1

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

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

Представьте приложение, которое должно обслуживать 100 прерываний в секунду с его высокоприоритетной нитью. И 10 прерываний в секунду с его срединно-приоритетным потоком (где каждому прерыванию требуется 30 мс для обработки). Низкоприоритетный поток может блокировать некоторый ресурс (используемый вместе с высокоприоритетным потоком). И иногда (очень редко) он мог блокировать его в течение длительного времени (1 сек). При приоритетном наследовании первый доступ к этому ресурсу с помощью высокоприоритетного потока повышает приоритет фонового потока до 1 секунды. Таким образом, поток среднего приоритета пропустит 10 прерываний. В то же время высокоприоритетная нить может пропустить 100 прерываний. Без приоритетного наследования срединно-приоритетный поток обслуживает все прерывания, но высокоприоритетный поток пропускает до 130 прерываний. Если прерывания, обслуживаемые средой с приоритетным приоритетом, более ценны, мы должны предпочесть отключить приоритетное наследование.

Я никогда не видел такого реального приложения. Поэтому я придумал один, чтобы проиллюстрировать этот случай. Пусть это приложение для захвата видео с заданием на компьютерное зрение в фоновом режиме и (как дополнительный бонус) звукозапись. Видеокадры захватываются потоком среднего приоритета. Звук захватывается высокоприоритетным потоком (поскольку в противном случае процесс захвата видео может блокировать значительную часть звуковых прерываний). Видео записывается в предварительно выделенный буфер. Аудио записывается с отключением тишины (для захвата тишины не требуется память). Таким образом, для аудиопотока требуются динамически выделенные блоки памяти (это наш общий ресурс). Задача компьютерного зрения также иногда выделяет блоки памяти. Когда мы выходим из памяти, сборщик мусора блокирует выделение памяти и выполняет некоторую работу. Здесь без приоритетного наследования видеозахват работает безупречно. Но с приоритетным наследованием аудиопоток иногда блокирует захват видео (что считается неправильным для этого приложения).

Также есть приложения, где приоритетное наследование не дает никаких преимуществ:

• Когда есть (1) несколько фоновых потоков и (2) несколько короткоживущих приоритетных потоков. Каждая группа потоков использует ресурсы только внутри своей собственной группы.
• Когда один ресурс разделяется потоками с приоритетами 1 и 2, другой - потоками с приоритетами 3 и 4 и т.д.
• Когда процессор имеет больше ядер, чем в приложении есть критические по времени потоки.
• Во многих других случаях.

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