условные переменные

Там не сигнал, а «положено и лежит» значение в переменной. При следующей проверке пролоезет, авось.

При следующей проверке

Так её не будет - поток спит же

Вообще ничего не понял. Лучше бы с кодом.

Где вы condition variable возмете которая без мутекса работает ?

int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex);

They are called with mutex locked by the calling thread or undefined behaviour will result.

А всякие STL и BOOST в конечном итоге мапятся в pthread (под linux)

Потери сигнала не будет только если соблюдать правило о том, что - метод notify обязательно вызывать под той же захваченной блокировкой (согласно задумке изобретателей паттерна condition variable, как в pthreads).

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

... нужен код ...

Не компилирующийся пример, конечно, но думаю ситуацию прояснит:

struct lock
{
    void lock() {}
    void unlock() {}
};

std::atomic<unsigned char> c = 0;
lock l;
std::condition_variable_any cv;

void control()
{
    //передаём рабочему потоку нечто на исполнение,
    //запускается он в другом месте
    ...
    //здесь надо подождать завершения исполнения задачи и,
    //например, забрать результат
    std::unique_lock<...> lock(l);
    cv.wait(lock, [](){ return c == 5; });
    //что-то делаем с результатами
    ...
}

void worker()
{
    //ждём задачу, как придёт - начинаем исполнение
    ...
    //после исполнения выставляем флаг готовности
    c=5;
    cv.notify_all();
    //goto 1;
}

Есть std::condition_variable_any<>, которая работает с BasicLockable типом(вместо мьютекса). Можно, конечно, посмотреть как всё сделано в gcc, но это ж конкретная реализация, да ещё и конкретной версии - поэтому стандарт пытаюсь раскурить

Я понял вашу мысль, сам также рассуждаю. Но

метод notify обязательно вызывать под той же захваченной блокировкой

В крестах такого требования нет(???)

проверка предиката и переход в состояние ожидания выполняются НЕ атомарно.

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

Это означает возможность потери сигнала пробуждения?

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

не должно быть проблемой в общем случае

Касательно случаев использования полноценных блокировок вопросов нет - там всё нормально

метод notify обязательно вызывать под той же захваченной блокировкой

В крестах такого требования нет(???)

Вот ответ на похожий вопрос: https://stackoverflow.com/questions/17101922/do-i-have-to-acquire-lock-before... .

не должно быть проблемой в общем случае

Касательно случаев использования полноценных блокировок вопросов нет - там всё нормально

Разумеется, блокировка, как бы она ни реализовывалась, должна быть полноценной.

Может, std::future использовать?

Я знал, что этот комментарий здесь будет) Со стандартными фьючерсами долгая история, запилить на их основе получается только с использованием больших костылей