TL; DR Assumption ("contratto") di risvegli spuri è una decisione architettonica ragionevole presa per consentire implementazioni realisticamente robuste di sheduler di filo.
Le "considerazioni sulle prestazioni" sono irrilevanti qui, sono solo incomprensioni che sono diventate diffuse a causa di aver dichiarato in un riferimento autorevole pubblicato. (i riferimenti autorevoli potrebbero avere errori, sai - basta chiedere a Galileo Galilei ) L' articolo di Wikipedia mantiene il riferimento alla nota che hai citato solo perché corrisponde perfettamente alle loro linee guida formali per citare il riferimento pubblicato.
Una ragione molto più convincente per introdurre il concetto di risvegli spuri è fornita in questa risposta a SO che si basa su ulteriori dettagli forniti in una (versione precedente) di questo stesso articolo:
L' articolo di Wikipedia sui risvegli spuri ha questo compito:
La pthread_cond_wait()funzione in Linux è implementata usando la futexchiamata di sistema. Ogni chiamata di sistema bloccante su Linux ritorna bruscamente con EINTRquando il processo riceve un segnale. ... pthread_cond_wait()non è possibile riavviare l'attesa perché potrebbe mancare un vero risveglio nel poco tempo in cui era fuori dalla futexchiamata di sistema ...
Pensaci ... come qualsiasi altro codice, lo scheduler dei thread potrebbe subire un blackout temporaneo a causa di qualcosa di anormale nell'hardware / software sottostante. Naturalmente, occorre prestare attenzione perché questo avvenga raro come possibile, ma dal momento che non c'è alcuna cosa come software robusto 100% è ragionevole supporre questo può accadere e prendersi cura sul recupero di grazia nel caso in cui se scheduler rileva tale (ad esempio, osservando i battiti del cuore mancanti ).
Ora, come potrebbe recuperare lo scheduler, tenendo conto del fatto che durante il blackout potrebbero mancare alcuni segnali destinati a notificare i thread in attesa? Se lo scheduler non fa nulla, i thread "sfortunati" citati si bloccheranno, aspettando per sempre - per evitarlo, lo scheduler invierebbe semplicemente un segnale a tutti i thread in attesa.
Ciò rende necessario stabilire un "contratto" per cui il thread in attesa può essere notificato senza motivo. Per essere precisi, ci sarebbe un motivo - blackout dello scheduler - ma poiché il thread è progettato (per una buona ragione) per essere ignaro dei dettagli dell'implementazione interna dello scheduler, è probabile che questo motivo sia meglio presentarlo come "spurio".
Dal punto di vista del thread, questo in qualche modo assomiglia a una legge di Postel (aka principio di robustezza ),
sii prudente in ciò che fai, sii liberale in ciò che accetti dagli altri
L'assunzione di risvegli spuri costringe il thread a essere conservativo in ciò che fa : imposta la condizione quando notifica altri thread e liberale in ciò che accetta : controlla la condizione al ritorno dall'attesa e ripeti l'attesa se non è ancora presente.