Для этого в wait передают лямбду с условием, не?

нет, вообще никакой связи

Если ты условие удовлетворишь до нотифая, то оно проверится при wait и сразу выйдет

Ты как раз так и делаешь

// control
unique_lock lock(mtx);
terminate = true;
lock.unlock();
cv.notify_all();


// worker
for(;;) {
    unique_lock lock(mtx);
    if(terminate)
        return;
    cv.wait_for(lock, seconds(1));
    if(terminate)
        return;
    lock.unlock();
    do_work();
}

вот это, может, и сработает, у меня уже нет сил вникать. ИМХО ручной анлок - опасный антипаттерн, лучше я поставлю таймаут и не буду извращаться и усложнять код

wait не атомарен, потому условие ничего не решает, только может уменьшить вероятность дедлока

Ну вот как раз работа для mutex :) condition меняется под lock и проверяется перед/после wait - точно не пропустишь.

да, логично, разобрался. Но это не обязан быть тот же лок, который уходит в cv?

Но он же как раз в wait его отпускает и на выходе из wait захватывает.

Начинает проясняться, спасибо. Т. е. самой cv этот лок абсолютно не нужен, а интерфейс такой сделан для удобства моей работы с cv?

Ну теоретически может и нужен, например если там какое-то внутреннее состояние меняется под этим (предположительно заблокированным) мьютексом. Или логика как-то зависит от него через happens-before.

Кстати condition_variable_any тож не обходится без std::mutex (кроме BasicLockable) :) Просто он внутре сидит.
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/std/condition_variable#L261

А ещё в gcc немного поломатый wait_for, был вообще только на system_clock, сейчас чот условно приделали при наличии новомодного pthread_cond_clockwait, хотя pthread_condattr_setclock вроде то же самое делает.
Я такую вот заплатку пользую: https://github.com/bibmaster/condition_variable/blob/master/condition_variable.hpp

Вот например, https://code.woboq.org/userspace/glibc/nptl/pthread_cond_wait.c.html#394
>  We do need acquire MO  to synchronize with group reinitialization in   __condvar_quiesce_and_switch_g1.
Что бы это ни значило :)

git blame & email? )

Вобще в POSIX не хватает всё  таки простого relative wait. Получается я например прибавляю таймаут к clock_gettime(CLOCK_MONOTONIC). А оно внутре из abstime вычитает тот же clock_gettime(CLOCK_MONOTONIC) чтобы дернуть с таймаутом futex_reltimed_wait_cancelable. А c relative wait вообще бы ни один clock_gettime не понадобился.

Причём объяснение abstime семантики сводится к тому что а вот если был бы relative то с ожиданием абсолютного времени так неудобно... Как будто нельзя было две функции сделать.

Кто-нибудь уже пробовал намутить корутины на библиотеке libuv? Что бы как nodejs, только node++

Написал клиента на nodejs полёт нормальный. Видимо дело в qt. Или в flowcontrol

А там есть отличия от буст асио?

Хрен знает