Как разблокировать одновременно 2 потока?

А в чем, собственно, проблема?

В авторе топика.

ОС обычно не предоставляет гарантии одновременности разблокировки. Ты можешь только попросить с уважением, а как оно там дальше пойдёт не известно.

Вопрос - как бэ из потока декодера запускать сразу 2 потока енкодеров, при этом поток декодера должен ждать завершения обоих???

декодер:

pthread_mutex_lock(&mutex);
...работаем
encode1_done = 0;
encode2_done = 0;
pthread_cond_signal(&cond_encoder1);
pthread_cond_signal(&cond_encoder2);

while (!encode1_done || !encode2_done) {
    pthread_cond_wait(&cond_decoder, &mutex);
}
pthread_mutex_unlock(&mutex);

енкодер1:

pthread_mutex_lock(&mutex);
pthread_cond_wait(&cond_encoder1, &mutex);
...работаем
encode1_done = 1;
if (encode1_done && encode2_done) {
    pthread_cond_signal(&cond_decoder);
}

pthread_mutex_unlock(&mutex);

енкодер2:

pthread_mutex_lock(&mutex);
pthread_cond_wait(&cond_encoder2, &mutex);
...работаем
encode2_done = 1;

if (encode1_done && encode2_done) {
    pthread_cond_signal(&cond_decoder);
}

pthread_mutex_unlock(&mutex);

Разве в этом случае будет одновременная работа 2х енкодеров? Как понимаю у вас они выполняются по очереди, у меня в обоих енкодерах нет относительно друг друга критических секций.

Было бы не плохо семафор сразу +2 делать когда нужно )

у меня в обоих енкодерах нет относительно друг друга критических секций

Тогда попробуй юзать одну переменную состояния для обеих потоков, а из потока декодера слать pthread_cond_broadcast().

А вот ещё очень интересно - зависит кто первый захватит семафор/мутекс от порядка кто как начал ждать???

Спасибо, буду разбираться

Зависит от конкретной реализации. См в документации. В целом, это свойство блокировок называется честностью (fairness).

из потока декодера слать pthread_cond_broadcast().

Погодите, но ведь проблема в одном и том же мутексе у обоих енкодеров!?

Погодите, но ведь проблема в одном и том же мутексе у обоих енкодеров!?

Верно. Но тебе обеим потокам главное выйти из режима ожидания. А кто из энкодеров захватить мютекс – пофигу. Когда они закончат работу, у выставят переменные encode0_done и encode1_done в 1 и просигналят декодеру.

Это все лишь в теории. Проверь, прокатит ли такой трюк на практике. Мне самому лень проверять, тоже сейчас сам вожусь с подобными ребусами блокировок.

С одной стороны конечно дважды поднять семафор енкодеров не проблема, осталось понять кто последний пришел к финишу и может поднять семафор декодера…

Не, мне надо именно запараллелить, тк и так сильно просаживается фпс с камеры при пересжатии и ещё пауз на 50-100мс хотелось бы избежать

мне надо именно запараллелить

Так идея в том, чтоб начать работу параллельно в обеих енкодерах сразу после pthread_cond_wait(). Т.е. ты будишь оба потока одновременно через бродкаст и они работают.

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

первый вышедший из условной переменной захватит мутекс

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

Нет, из спячки выходит только первый взявший снова мутекс, ну вроде так в доках написано

спячки выходит только первый взявший снова мутекс

Да, в случае pthread_cond_signal(). В случае с pthread_cond_broadcast() – просыпаются оба.

DESCRIPTION
     The pthread_cond_broadcast() function unblocks all threads waiting for
     the condition variable cond.

Поскольку pthread_cond_broadcast() заставляет все потоки, блокированные некоторым состоянием, бороться за мьютекс, ее нужно использовать аккуратно

https://www.opennet.ru/docs/RUS/ipcbook/node75.html

Еще раз… Идея в том, чтоб просто разбудить, а не бороться за мютекс. Для борьбы для этого и суют pthread_cond_wait() в цикл while.

Ещё раз как я понимаю условную переменную

• блокируешь мутекс
• встаёшь на переменную, отпуская мутекс
• приходит событие на переменную, происходит захват мутекса

Тебе нужны барьеры? Когда к барьеру подходит N потоков, то все они «проскакивают» барьер скопом, до этого ждут. Так можно тригернуть на запуск и ожидать завершения

Спасибо, вроде то что надо, разбираюсь

приходит событие на переменную, происходит захват мутекса

Правильно… А после этого ты можешь отпустить мютекс и просигналить второму потоку чтоб он начал работу.

Те отпускать мутекс сразу после захвата… Спасибо, надо обдумать

параллельный редко запускаемый енкодер (снимки) добавить

Можно сделать разблокировку сообщениями. Например, через pipe. И уже в сообщении указывать действие - только поток или поток+снимок.

FUTEX_WAKE (since Linux 2.6.0)
              This operation wakes at most val of the waiters that are
              waiting (e.g., inside FUTEX_WAIT) on the futex word at the
              address uaddr.  Most commonly, val is specified as either
              1 (wake up a single waiter) or INT_MAX (wake up all
              waiters).  No guarantee is provided about which waiters
              are awoken (e.g., a waiter with a higher scheduling
              priority is not guaranteed to be awoken in preference to a
              waiter with a lower priority).

Тут пример есть:
https://habibutsu.github.io/synchronize.html

Интересно, конечно, есть ли какие-то альтернативы в pthread. Но всё что я видел помимо фьютекса пробуждает потоки по одному

P.S
Возможно, это оно:
https://stackoverflow.com/questions/40126442/best-way-to-wakeup-multiple-thre...

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

это то да, сейчас так и сделано для 2х потоков (декодер+енкодер), но в конце цикла нужно из енкодера пнуть декодер, а если ИНОГДА 2 енкодера, то и появляется дилемма кто из 2х енкодеров может переключить декодер на другой буфер и отправить его писать в него.

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

зы. а еще самый первый енкодер хоть и нагружает систему большего всего, но он нужен условно 1 раз в час (а может и сутки не нужен) в течении 1-2 минут, а второй енкодер (снимки) железно каждые 10 минут нужен

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

хотя… если из декодера либо пинать 2 раза семафор енкодера, либо 1 раз и 1 раз барьер - теоретически должно получиться… или нет )

или просто у енкодера сделать 2 семафора - начала и конца и из декодера пинать либо 2 раза семафор старта, либо 1 раз старт и 1 раз конца… не, тоже не то.

… а может вообще 4 поток сделать, который и будет управлять запусками и контролировать остановки потоков на основе семафоров

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