Considere el siguiente ejemplo.

std::mutex mtx;
std::condition_variable cv;

void f()
{
  {
    std::unique_lock<std::mutex>  lock( mtx );
    cv.wait( lock );  // 1
  }
  std::cout << "f()\n";
}

void g()
{
  std::this_thread::sleep_for( 1s );
  cv.notify_one();
}

int main()
{
  std::thread  t1{ f };
  std::thread  t2{ g };
  t2.join();
  t1.join();
}

g() "saber esof() está esperando en el escenario que me gustaría discutir. De acuerdo acppreference.com no hay necesidad deg() para bloquear el mutex antes de llamarnotify_one. Ahora en la línea marcada "1"cv liberará el mutex y lo volverá a bloquear una vez que se envíe la notificación. El destructor delock lo libera nuevamente inmediatamente después de eso. Esto parece ser superfluo, especialmente porque el bloqueo es costoso. (Sé que en ciertos escenarios el mutex necesita ser bloqueado. Pero este no es el caso aquí).

Por quecondition_variable no tiene función "wait_nolock"que no vuelve a bloquear el mutex una vez que llega la notificación. Si la respuesta es que pthreads no proporcionan dicha funcionalidad: ¿por qué no se pueden extender pthreads para proporcionarla? ¿Existe alguna alternativa para realizar el comportamiento deseado?