TL; DR L'assunzione ("contratto") di wakeups spurie è una decisione architettonica ragionevole per consentire realistiche implementazioni robuste del thread sheduler.
Le "considerazioni sulle prestazioni" sono irrilevanti qui, questi sono solo fraintendimenti che si sono diffusi a causa del fatto di aver dichiarato in un riferimento autorevole pubblicato. (riferimenti autorevoli potrebbero avere errori, sai - basta chiedere l'articolo Galileo Galilei ) di Wikipedia il riferimento alla nota che hai citato solo perché combacia perfettamente con le linee guida formali per citare il riferimento pubblicato.
La risposta a SO che si basa su dettagli aggiuntivi è una ragione molto più convincente per introdurre il concetto di wakeups spurie fornito in una (versione precedente) di quello stesso articolo:
The Wikipedia article on spurious wakeups has this tidbit:
The pthread_cond_wait() function in Linux is implemented using the futex system call. Each blocking system call on Linux returns abruptly with EINTR when the process receives a signal. ... pthread_cond_wait() can't restart the waiting because it may miss a real wakeup in the little time it was outside the futex system call...
Basti pensare che ... come qualsiasi codice, lo scheduler dei thread potrebbe subire un blackout temporaneo a causa di qualcosa di anormale che accade nell'hardware / software sottostante. Naturalmente, è necessario fare attenzione affinché ciò accada il più raramente possibile, ma poiché non esiste software affidabile al 100%, è ragionevole supporre che questo possa accadere e occuparsi del recupero agevole in caso se lo scheduler lo rileva (ad esempio osservando i battiti cardiaci mancanti ).
Ora, come potrebbe recuperare lo scheduler, tenendo conto che durante il blackout potrebbero mancare alcuni segnali destinati a notificare thread in attesa? Se lo scheduler non fa nulla, le discussioni "sfortunate" si bloccheranno, aspettando per sempre - per evitare ciò, lo scheduler semplicemente invierà un segnale a tutti i thread in attesa.
Ciò rende necessario stabilire un "contratto" che il thread in attesa possa essere notificato senza una ragione. Per essere precisi, ci sarebbe un motivo - blackout dello scheduler - ma poiché thread è progettato (per una buona ragione) per essere ignaro dei dettagli di implementazione interna dello scheduler, questo motivo è probabilmente meglio presentare come "spurio".
Dal punto di vista del thread, questo assomiglia un po 'alla legge di Postel (alias principio di robustezza ),
be conservative in what you do, be liberal in what you accept from others
L'assunzione di wakeup spuri obbliga il thread a essere conservativo in ciò che fa : imposta la condizione quando notifica altri thread e liberal in ciò che accetta : controlla la condizione su qualsiasi ritorna dall'attesa e ripeti attendi se non c'è ancora.