Llamar a pthread_cond_signal sin bloquear mutex

Leí en alguna parte que deberíamos bloquear el mutex antes de llamar a pthread_cond_signal y desbloquear el mutex después de llamarlo:

La rutina pthread_cond_signal () se usa para señalar (o despertar) otro hilo que está esperando la variable de condición. Se debe llamar después de que el mutex esté bloqueado y debe desbloquearlo para que se complete la rutina pthread_cond_wait ().

Mi pregunta es: ¿no está bien llamar a los métodos pthread_cond_signal o pthread_cond_broadcast sin bloquear el mutex?

Si no bloquea el mutex en la ruta de código que cambia la condición y las señales, puede perder las activaciones. Considere este par de procesos:

Proceso A:

pthread_mutex_lock(&mutex);
while (condition == FALSE)
    pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);

Proceso B (incorrecto):

condition = TRUE;
pthread_cond_signal(&cond);

Luego considere este posible entrelazado de instrucciones, donde conditioncomienza como FALSE:

Process A                             Process B

pthread_mutex_lock(&mutex);
while (condition == FALSE)

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

El conditiones ahora TRUE, pero el proceso A está atascado esperando en la variable de condición: perdió la señal de activación. Si modificamos el proceso B para bloquear el mutex:

Proceso B (correcto):

pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);

... entonces lo anterior no puede ocurrir; el despertar nunca se perderá.

(Tenga en cuenta que en realidad puede mover el pthread_cond_signal()mismo después de pthread_mutex_unlock(), pero esto puede resultar en una programación de subprocesos menos óptima, y ​​necesariamente ha bloqueado el mutex ya en esta ruta de código debido al cambio de la condición en sí).

Según este manual:

Las funciones pthread_cond_broadcast()o pueden ser llamadas por un subproceso, ya sea que actualmente posea o no el mutex que los subprocesos llaman o tienen asociado con la variable de condición durante sus esperas; sin embargo, si se requiere un comportamiento de programación predecible, entonces ese mutex será bloqueado por el hilo que llama o .pthread_cond_signal()pthread_cond_wait()pthread_cond_timedwait()pthread_cond_broadcast()pthread_cond_signal()

Dave Butenhof (autor de Programming with POSIX Threads ) explicó el significado de la declaración de comportamiento de programación predecible en comp.programming.threads y está disponible aquí .

caf, en su código de muestra, el Proceso B modifica conditionsin bloquear primero el mutex. Si el Proceso B simplemente bloqueó el mutex durante esa modificación, y luego desbloqueó el mutex antes de llamar pthread_cond_signal, no habría ningún problema, ¿tengo razón en eso?

Creo intuitivamente que la posición de caf es correcta: llamar pthread_cond_signalsin tener el bloqueo mutex es una mala idea. Pero el ejemplo de caf no es realmente una evidencia que apoye esta posición; es simplemente evidencia en apoyo de la posición mucho más débil (prácticamente evidente por sí misma) de que es una mala idea modificar el estado compartido protegido por un mutex a menos que haya bloqueado ese mutex primero.

¿Alguien puede proporcionar algún código de muestra en el que la llamada pthread_cond_signalseguida de pthread_mutex_unlockun comportamiento correcto, pero la llamada pthread_mutex_unlockseguida de pthread_cond_signalun comportamiento incorrecto?