Para citar a página do manual:
Ao usar variáveis de condição, sempre há um predicado booleano que envolve variáveis compartilhadas associadas a cada espera de condição que é verdadeira se o encadeamento continuar. Ativações espúrias das funções pthread_cond_timedwait () ou pthread_cond_wait () podem ocorrer. Como o retorno de pthread_cond_timedwait () ou pthread_cond_wait () não implica nada sobre o valor desse predicado, o predicado deve ser reavaliado com esse retorno.
Portanto, você pthread_cond_wait
pode retornar mesmo que não tenha sinalizado. À primeira vista, pelo menos, isso parece bastante atroz. Seria como uma função que retornasse aleatoriamente o valor errado ou retornasse aleatoriamente antes de realmente atingir uma declaração de retorno adequada. Parece um grande erro. Mas o fato de terem optado por documentar isso na página de manual, em vez de corrigi-lo, parece indicar que há uma razão legítima pela qualpthread_cond_wait
acorde espúrio. Presumivelmente, há algo intrínseco sobre como funciona que faz com que isso não possa ser ajudado. A questão é o que.
Por que pthread_cond_wait
retornar espuriosamente? Por que não pode garantir que só vai acordar quando for sinalizado corretamente? Alguém pode explicar a razão de seu comportamento espúrio?
pthread_cond_(timed)wait
: "Se um sinal for entregue ... o encadeamento continuará aguardando a variável de condição como se fosse interrompido ou retornará zero devido a despertar espúrio ". Outras funções de bloqueio indicam EINTR
quando interrompidas por um sinal (por exemplo read
) ou são necessárias para retomar (por exemplo pthread_mutex_lock
). Portanto, se não houvesse outras razões para despertar espúrio, pthread_cond_wait
poderia ter sido definido como qualquer uma dessas.