A suposição TL; DR ("contrato") de ativações espúrias é uma decisão arquitetural sensata feita para permitir implementações realmente robustas do sheduler de encadeamentos.
As "considerações sobre desempenho" são irrelevantes aqui, são apenas mal-entendidos que se espalharam por terem sido declarados em uma referência oficial publicada. (as referências autoritativas podem ter erros, você sabe - basta perguntar ao Galileo Galilei ). O artigo da Wikipedia mantém a referência à nota que você citou, apenas porque combina perfeitamente com as diretrizes formais de citação da referência publicada.
Razões muito mais convincentes para a introdução do conceito de ativação espúria são fornecidas nesta resposta no SO, com base em detalhes adicionais fornecidos em uma (versão mais antiga) desse mesmo artigo:
O artigo da Wikipedia sobre despertares espúrios tem este boato:
A pthread_cond_wait()função no Linux é implementada usando a futexchamada do sistema. Cada chamada do sistema de bloqueio no Linux retorna abruptamente EINTRquando o processo recebe um sinal. ... pthread_cond_wait()não é possível reiniciar a espera porque pode perder uma ativação real no pouco tempo em que esteve fora da futexchamada do sistema ...
Basta pensar nisso ... como qualquer código, o agendador de threads pode sofrer um apagão temporário devido a algo anormal acontecendo no hardware / software subjacente. Obviamente, deve-se tomar cuidado para que isso aconteça o mais raro possível, mas como não existe software 100% robusto, é razoável supor que isso possa acontecer e tomar cuidado com a recuperação normal, caso o agendador detecte isso (por exemplo, observando batimentos cardíacos ausentes ).
Agora, como o agendador poderia se recuperar, levando em consideração que durante o blecaute poderia perder alguns sinais destinados a notificar threads em espera? Se o planejador não fizer nada, os encadeamentos "azarados" mencionados simplesmente travarão, aguardando para sempre - para evitar isso, o agendador simplesmente enviaria um sinal para todos os encadeamentos em espera.
Isso torna necessário estabelecer um "contrato" para que o thread em espera possa ser notificado sem um motivo. Para ser mais preciso, haveria um motivo - blecaute do planejador - mas como o encadeamento foi projetado (por um bom motivo) para não dar atenção aos detalhes de implementação interna do planejador, é provável que esse motivo seja melhor apresentado como "espúrio".
Da perspectiva do thread, isso se assemelha um pouco à lei de Postel (também conhecida como princípio da robustez ),
seja conservador no que faz, seja liberal no que aceita dos outros
A suposição de despertares espúrios força o encadeamento a ser conservador no que faz : definir condição ao notificar outros encadeamentos e liberal no que aceita : verifique a condição em qualquer retorno da espera e repita a espera se ainda não estiver lá.