Насколько хорошим решением является использование pthread_kill для возобновления работы потоков?

Question

[Василий Дёмин]

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

Поясняющий код:

void* worker(void *arg) {
    struct sigset_t *sig = arg;
    int sig_num;
    for(;;) {
        // Ожидание SIGUSR1
        sigwait(sig, &sig_num);

        // Выполнение работы

        // Сигнализируем о выполненной работе
    }
    return NULL;
}

int main() {
    struct sigset_t sig;
    sigemptyset(&sig);
    sigaddset(&sig, SIGUSR1);
    pthread_sigmask(SIG_BLOCK, &sig, NULL);

    // Создаём 4 потока
    pthread_t threads[4];
    for(int i = 0; i < 4; i++) {
        pthread_create(&threads[i], NULL, worker, &sig);
    }

    // Некоторый код
    // Некоторый код
    // Некоторый код

    // Передаём данные через глобальные переменные 4-м потокам

    // Выводим 4-е потока из спящего режима
    for(int i = 0; i < 4; i++) {
        pthread_kill(threads[i], SIGUSR1);
    }

   // Ожидаем выполнения 4-х потоков
}

Answer 1

[jcmvbkbc]

Насколько хорошим решением является использование сигналов для выведения потоков из спящего режима, и стоит ли для этого использовать ...

Является решением, но не самым традиционным. Насколько хорошим -- зависит от модели совместной работы потоков/того как разделяются данные между ними. Не хватает контекста для ответа.

Comments

[Василий Дёмин]

Сами потоки друг с другом никак не взаимодействуют. Данные для потоков - начальный и конечный индексы в общем массиве. Каждый из потоков отрисовывает поверхности, соответствующие переданным в него индексам.

[jcmvbkbc]

Для такого использования -- нормально. Более традиционным способом синхронизации для этого случая был бы семафор -- по одному на каждый поток.

[Василий Дёмин]

Спасибо за ответ. Было интересно узнать, что думают другие программисты о взаимодействии потоков через сигналы, так как по поводу данного подхода особо ничего не написано. Если я правильно вас понял, то стандартным подходом является использование мьютексов. Изначально я пытался реализовать управление потоками через мьютексы и условную переменную, но столкнулся с следующей проблемой: при вызове pthread_cond_broadcast некоторые из потоков ещё не доходили до вызова pthread_cond_wait, из-за чего они блокировались. Если же в функции main перед вызовом pthread_cond_broadcast сначала захватывать соотвтетствующий i-му потоку мьютекс, то производительность будет снижаться, так как перед запуском i+1 потока придётся ждать, пока i-й дойдёт до pthread_cond_wait и отпустит мьютекс.

pthread_cond_t notify;

void* worker(void *arg) {
    pthread_mutex_t *mtx = arg;
    pthread_mutex_lock(mtx);
    for(;;) {
        pthread_cond_wait(&notify, mtx);

        // Выполнение работы

        // Сигнализируем о выполненной работе
    }
    return NULL;
}

int main() {
    pthread_t threads[4];
    pthread_mutex_t mtxs[4];

    // Инициализируем условную переменную
    pthread_cond_init(&notify, NULL);

    // Создаём 4 потока
    for(int i = 0; i < 4; i++) {
        pthread_mutex_init(&mtxs[i], NULL);
        pthread_create(&threads[i], NULL, worker, &mtxs[i]);
    }

    // Некоторый код
    // Некоторый код
    // Некоторый код

    // Передаём данные через глобальные переменные 4 потокам

    // Выводим 4 потока из спящего режима
    pthread_cond_broadcast(&notify);

    // Ожидаем выполнения 4 потоков
}

[jcmvbkbc]

Если я правильно вас понял, то под
бе семафор
вы имели в виду мьютекс.

Василий Дёмин, если бы я имел в виду мьютекс, я бы написал "мьютекс".
Но нет, я имел в виду именно семафор.

[jcmvbkbc]

pthread_cond_wait(&notify, mtx);

        // Выполнение работы

Василий Дёмин, так делать неправильно, потому что conditional не гарантирует, что произошло именно то событие, которого ты ожидал. Нужно проверять под мьютексом что да, событие произошло, а если нет -- возвращаться к ожиданию.
Кроме этого, в приведённом коде есть гонка между потоками выполняющими worker и основным потоком -- если основной поток просигналит в cond до того, как воркеры встанут на ожидание, они будут стоять на ожидании до следующего cond_broadcast.
Использование семафора решает обе эти проблемы.

[Василий Дёмин]

Спасибо за наводку на семафоры, только что переписал всё на них, что сделало приложение переносимым.

[jcmvbkbc]

что сделало приложение переносимым

Василий Дёмин, м... posix threads в общем-то тоже переносимый интерфейс. И твою исходную задачу можно не менее эффективно и переносимо (но, возможно, более многословно) решить на condvar.

[Василий Дёмин]

В своём проекте я буду использовать реализацию потоков и примитивов синхронизации от SDL, так как SDL уже используется, поэтому проблем с переносимостью возникнуть не должно, чего нельзя сказать о сигналах.