Что такое priority inversion? Как с ней бороться?

Priority Inversion (инверсия приоритетов)

Priority inversion — это проблема многопоточности, когда поток с высоким приоритетом блокируется потоком с низким приоритетом, запрашивающим один и тот же ресурс. В результате система работает неправильно, несмотря на расставленные приоритеты.

Пример проблемы

#include <thread>
#include <mutex>
#include <iostream>

std::mutex resource;
int shared_data = 0;

void low_priority_task() {
    // Поток с низким приоритетом
    {
        std::lock_guard<std::mutex> lock(resource);
        // Критическая секция
        for (int i = 0; i < 1000000000; i++) {
            shared_data++;  // Долгая операция с блокировкой
        }
    }
}

void high_priority_task() {
    // Поток с высоким приоритетом
    {
        std::lock_guard<std::mutex> lock(resource);  // Ждёт, пока низкий приоритет освободит!
        shared_data++;
    }
}

int main() {
    std::thread low(low_priority_task);
    std::thread high(high_priority_task);
    
    // high ждёт, пока low закончит, несмотря на свой высокий приоритет
    // Это PRIORITY INVERSION!
    
    low.join();
    high.join();
}

Почему это проблема?

1. Нарушение гарантий приоритета

   • Запланированный порядок выполнения нарушается
   • Высокий приоритет становится бесполезным

2. В real-time системах критично

   // Пример: медицинское оборудование
   // Высокий приоритет: контроль сердцебиения (критичен!)
   // Низкий приоритет: логирование (некритично)
   // Если логирование заблокирует контроль — может быть трагедия!
   

3. Непредсказуемость

   • Время отклика (latency) становится непредсказуемым
   • Нарушаются real-time гарантии

Классический пример: Pathfinder (NASA)

В 1997 году марсоход NASA Pathfinder полностью завис из-за priority inversion:

1. Высокий приоритет: контроль движения
2. Средний приоритет: коммуникация
3. Низкий приоритет: сборка метеоданных (держит mutex)

Порядок:
- Низкий захватил mutex
- Высокий хотел mutex → ЖДЁТ
- Средний запущен и преимущество вытеснить высокий
- Высокий остаётся в очереди ожидания
- Система зависает!

Решение 1: Priority Inheritance (Наследование приоритета)

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

#include <thread>
#include <mutex>

// Мьютекс с наследованием приоритета
std::mutex resource;

void low_priority_with_inheritance() {
    {
        std::lock_guard<std::mutex> lock(resource);
        // Пока держим lock, приоритет = максимальному ждущему потоку
        // Если его ждёт высокий приоритет, мы получим высокий приоритет
        shared_data++;
    }
    // Приоритет вернулся к исходному
}

В POSIX:

#include <pthread.h>

pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);  // Наследование приоритета

pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr);

Решение 2: Priority Ceiling (Потолок приоритета)

Устанавливается максимальный приоритет для ресурса. Все потоки, захватывающие ресурс, автоматически повышаются до этого приоритета.

#include <pthread.h>

pthread_mutexattr_t attr;
pthread_mutexattr_init(&attr);
pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_PROTECT);
pthread_mutexattr_setprioceiling(&attr, 99);  // Приоритет потолка

pthread_mutex_t mutex;
pthread_mutex_init(&mutex, &attr);

Преимущества:

• Проще для анализа
• Меньше контекстных переключений
• Гарантирует отсутствие deadlock'ов

Недостатки:

• Нужно знать приоритеты заранее

Решение 3: Избегать взаимных блокировок

Правило 1: Минимизируй критические секции

// ПЛОХО
void bad_function() {
    {
        std::lock_guard<std::mutex> lock(resource);
        // Долгая операция внутри lock
        for (int i = 0; i < 1000000000; i++) {
            do_something();
        }
    }
}

// ХОРОШО
void good_function() {
    auto data_to_process = [this]() {
        std::lock_guard<std::mutex> lock(resource);
        return shared_data;  // Копируем быстро
    }();
    
    // Долгая операция БЕЗ lock
    for (int i = 0; i < 1000000000; i++) {
        do_something_with(data_to_process);
    }
}

Правило 2: Никогда не вложи lock в lock

// ОЧЕНЬ ПЛОХО — может привести к deadlock
{
    std::lock_guard<std::mutex> lock1(mutex1);
    {
        std::lock_guard<std::mutex> lock2(mutex2);
        // Если другой поток возьмёт mutex2 потом mutex1 — deadlock
    }
}

// ХОРОШО — использовать std::lock для атомного захвата
std::lock(mutex1, mutex2);
std::lock_guard<std::mutex> lock1(mutex1, std::adopt_lock);
std::lock_guard<std::mutex> lock2(mutex2, std::adopt_lock);

Решение 4: Lock-free структуры

Избегать мьютексов вообще:

#include <atomic>

std::atomic<int> shared_data = 0;  // Никаких мьютексов!

void task1() {
    shared_data++;  // Атомарная операция, без блокировки
}

void task2() {
    shared_data++;  // Сразу выполнится, без ожидания
}

Когда использовать:

• Простые типы данных
• Высокая конкурентность
• Real-time требования

Решение 5: Condition Variables с правильной синхронизацией

#include <condition_variable>

std::mutex mtx;
std::condition_variable cv;
bool ready = false;

void high_priority_waiter() {
    std::unique_lock<std::mutex> lock(mtx);
    while (!ready) {
        cv.wait(lock);  // Освобождает мьютекс во время ожидания
    }
    // Работаем с данными
}

void low_priority_worker() {
    std::this_thread::sleep_for(std::chrono::seconds(1));
    {
        std::lock_guard<std::mutex> lock(mtx);
        ready = true;
    }
    cv.notify_all();  // Пробуждает ждущие потоки
}

Best Practices

1. Используй mutex с наследованием приоритета в real-time

   pthread_mutexattr_setprotocol(&attr, PTHREAD_PRIO_INHERIT);
   

2. Минимизируй время в критической секции

   • Copy-modify-update вместо долгих операций

3. Избегай глубокой вложенности мьютексов

   • Порядок захвата мьютексов должен быть всегда один и тот же

4. Используй lock-free структуры где возможно

   • std::atomic, lockfree очереди

5. Профилируй реальное время отклика

   • Priority inversion может быть скрытой даже в тестах

Priority inversion — классическая проблема многопоточности, требующая понимания синхронизации и приоритетов в системе.