Что может заставить планировщик Windows игнорировать поток с высоким приоритетом, когда доступны ядра ЦП?

Question

У меня есть многопоточное приложение, в котором один из потоков выполняет критичную по времени работу. Этот критичный ко времени поток имеет приоритет «критичный ко времени» при запуске. Кроме того, другие потоки в приложении имеют маску привязки к процессору, так что этот критичный ко времени поток всегда имеет полный доступ к восьми ядрам ЦП (из 12 в общей сложности для двух Xeon). На сервере не запущены никакие другие приложения (кроме служб, которые Windows запускает самостоятельно).

Тем не менее, даже со всеми этими мерами предосторожности я записываю события, когда этот критический по времени поток не работает в течение 80-100 мс привремя. Моя регистрация показывает, что иногда она останавливается в середине задачи и возобновляется после 80-100 мс.

Мой вопрос: что может быть причиной этих 80-100 мс отключений потока и/ или как мне выяснить, что их вызывает?

Некоторая другая, возможно, относящаяся к делу информация:

• Отключения сильно коррелируют с высокой активностью в других прикладных потоках, но я отслеживаю графики использования ЦП вМонитор ресурсов и может видеть, что процессоры, выделенные для срочной задачи, намного меньше, чем 100% (но 4, которые имеют полный доступ, обычно в это время составляют 100%)
• Во время этих операций также наблюдается интенсивная работа сетипериоды пиковой производительности, в которых обычно происходят отключения электроэнергии.
• Критически важная по времени задача заключается в взаимодействии с аппаратной частью через связь PCIe, но события «отключения» не обязательно происходят при обращении к этому устройству.
• Когда все работает правильно,критический по времени поток тратит около 1-2 мс на выполнение работы, а затем ждет около 30 мс в занятом цикле.
• критическая по времени задача делит ресурс с некоторыми другими потоками, но она защищена с помощью спин-блокировки, и запись в журнал указываетотключения в ожидании блокировки не происходит. Кроме того, я вижу, что эти другие потоки не удерживают спин-блокировку более нескольких микросекунд.
• Изменение приоритета приложения на «ВЫСОКИЙ» с помощью диспетчера задач не улучшает производительность
• У меня есть тестовые серверы под управлением Win7 и Win10, и оба показывают проблему.

Answer 1

За последние несколько дней я провел несколько тестов и смог собрать некоторые интересные данные, которые я обобщу ниже.

1. Проблема почти никогда не возникает, когда процессоры в значительной степениidle
2. Я могу легко вызвать сбой, выгружая процессор из другого процесса, который просто использует его, используя множество потоков
3. Я думал, что смогу уменьшить проблему, ограничив большинство потоков с помощью масок соответствия процессов и оставивкритичные ко времени потоки на их собственных выделенных процессорах. Однако оказалось, что это не было полным решением, потому что существуют некоторые общие блокировки (для передачи информации, а также средств ведения журналов), которые вызывали проблемы конкуренции. Потоки с высоким уровнем конкуренции, но с низким приоритетом, которые кратковременно удерживают критическую блокировку, будут переведены в режим сна, удерживая блокировку, в результате чего мои потоки с высоким приоритетом (на простом процессоре, обратите внимание) ожидают.
4. Безусловно, большинствоИнтересный тест, который я проводил, состоял в том, чтобы взять определенную тестовую систему Windows 7 с высокой частотой отказов, и я установил свежую копию Windows 10 на том же самом оборудовании и запустил точно такое же программное обеспечение. Это значительно уменьшило частоту отказов при тех же точных рабочих условиях.

В конечном счете, я считаю, что проблема сводится к тому, что Windows не справляется с работой 1) приоритетами потоков в целом и 2) приоритетамивопросы инверсии особенно. Удивительно, но Windows 10, по-видимому, справляется с этими проблемами значительно лучше, чем Windows 7.

У Microsoft есть краткая статья о том, как ОС обрабатывает инверсию приоритетов, но кажется, что когда процессоры сильно загруженыс несколькими потоками этой стратегии недостаточно для предотвращения длительных задержек в критических потоках, особенно в Windows 7.