variable de condición - ¿por qué llamar a pthread cond signal() antes de llamar a pthread cond wait() es un error lógico?

Mis 2 centavos: No conozco los efectos secundarios de llamar a *pthread_cond_signal()* cuando no se ha bloqueado ningún hilo llamando a *pthread_cond_wait()*. Esto es realmente un detalle de implementación Lo que creo es que, si tu modelo threading / timimg no garantiza el orden correcto entre espera y señal, probablemente deberías considerar un mecanismo de sincronización diferente[como un simple semáforo , por ejemplo] cuando puedes señalar el semáforo desde el hilo B incluso si el hilo A no ha alcanzado la sincronización punto. Cuando el hilo A alcance el punto de sincronización, encontrará el semáforo incrementado y entrará en la sesión crítica.

Una variable de condición permite que un hilo despierte a otro de una espera. Funcionan solo si hay un hilo esperando en el momento en que se activa la condición. La forma de garantizar que este sea el caso es que el hilo de espera bloquee un mutex que está vinculado a la condición, y que el hilo de señalización bloquee ese mutex antes de activar la condición. En otras palabras, el hilo de señalización solo puede bloquear el mutex y activar la condición si el otro hilo tenía el mutex bloqueado pero ahora está esperando.

Estoy más familiarizado con boost, así que lo usaré en este ejemplo:

// A shared mutex, global in this case.
boost::mutex myMutex;

// Condition variable
boost::condition_variable myCondition;

void threadProc()
{
    // Lock the mutex while the thread is running.
    boost::mutex::scoped_lock guard( myMutex );

    while( true )
    {
        // Do stuff, then...

        myCondition.wait( guard ); // Unlocks the mutex and waits for a notification.
    }
}

void func()
{
    // Function wants to trigger the other thread. Locks the mutex...
    boost::mutex::scoped_lock guard( myMutex );

    // Since the mutex is locked, we know that the other thread is
    // waiting on the condition variable...
    myCondition.notify_all();
}

Señalar una variable de condición cuando no hay una espera correspondiente es un error lógico porque nada recibirá la señal. Las variables de condición no permanecen en un estado señalado.

Si no le importa que esta señal se pierda, no hay error. Es solo un error si esperas que el hilo en espera se despierte de cond_wait() inmediatamente.

Dado que este es el caso de uso habitual para pthread_cond, el tutorial llama a este error lógico. Pero nada se estrellará y no se producirá ningún comportamiento inesperado. En el flujo de ejecución normal, cond_signal() todavía puede emitirse cuando no hay subprocesos en cond_wait (): por ejemplo, todos los lectores pueden estar simplemente procesando mensajes cuando writer agrega otra pieza de datos en la cola.