Para citar la página del manual:
Cuando se usan variables de condición, siempre hay un predicado booleano que involucra variables compartidas asociadas con cada espera de condición que es verdadero si el hilo debe continuar. Pueden ocurrir activaciones espurias de las funciones pthread_cond_timedwait () o pthread_cond_wait (). Dado que el retorno de pthread_cond_timedwait () o pthread_cond_wait () no implica nada sobre el valor de este predicado, el predicado debe ser reevaluado en dicho retorno.
Por lo tanto, pthread_cond_wait
puede regresar incluso si no lo ha señalado. A primera vista, al menos, eso parece bastante atroz. Sería como una función que devolvió aleatoriamente el valor incorrecto o regresó aleatoriamente antes de que realmente alcanzara una declaración de retorno adecuada. Parece un error importante. Pero el hecho de que eligieron documentar esto en la página del manual en lugar de corregirlo parece indicar que hay una razón legítima por la que pthread_cond_wait
termina despertando espuriosamente. Presumiblemente, hay algo intrínseco en su funcionamiento que hace que no se pueda evitar. La pregunta es qué.
¿ Por quépthread_cond_wait
vuelve espuriamente? ¿Por qué no puede garantizar que solo se despertará cuando se haya señalado correctamente? ¿Alguien puede explicar la razón de su comportamiento espurio?
pthread_cond_(timed)wait
: "Si se entrega una señal ... el hilo se reanuda esperando la variable de condición como si fuera no se interrumpe, o devolverá cero debido a la activación espuria ". Otras funciones de bloqueo indican EINTR
cuando se interrumpe por una señal (p read
. Ej. ), O se requiere que se reanuden (p pthread_mutex_lock
. Ej .). Entonces, si no hubiera otras razones para el despertar espurio, pthread_cond_wait
podría haberse definido como cualquiera de esos.