Pourquoi pthread_cond_wait a-t-il de faux réveils?

Pour citer la page de manuel:

Lors de l'utilisation de variables de condition, il existe toujours un prédicat booléen impliquant des variables partagées associées à chaque condition d'attente qui est vrai si le thread doit continuer. Des réveils parasites des fonctions pthread_cond_timedwait () ou pthread_cond_wait () peuvent se produire. Puisque le retour de pthread_cond_timedwait () ou pthread_cond_wait () n'implique rien sur la valeur de ce prédicat, le prédicat doit être réévalué lors d'un tel retour.

Donc, pthread_cond_waitpeut revenir même si vous ne l'avez pas signalé. À première vue du moins, cela semble assez atroce. Ce serait comme une fonction qui retournait aléatoirement la mauvaise valeur ou renvoyée aléatoirement avant d'atteindre réellement une instruction de retour correcte. Cela semble être un bug majeur. Mais le fait qu'ils aient choisi de documenter cela dans la page de manuel plutôt que de corriger cela semble indiquer qu'il y a une raison légitime pour laquelle pthread_cond_waitfinit par se réveiller de manière indue. Vraisemblablement, il y a quelque chose d'intrinsèque dans son fonctionnement qui fait que cela ne peut pas être aidé. La question est de savoir quoi.

Pourquoi ne pthread_cond_waitrevenir spuriously? Pourquoi ne peut-il pas garantir qu'il ne se réveillera que lorsqu'il aura été correctement signalé? Quelqu'un peut-il expliquer la raison de son comportement faux?

L'explication suivante est donnée par David R. Butenhof dans "Programming with POSIX Threads" (p. 80):

Des réveils parasites peuvent sembler étranges, mais sur certains systèmes multiprocesseurs, rendre le réveil des conditions complètement prévisible peut ralentir considérablement toutes les opérations des variables de condition.

Dans la discussion comp.programming.threads suivante , il développe la réflexion derrière la conception:

Patrick Doyle a écrit: 
> Dans l'article, Tom Payne a écrit: 
>> Kaz Kylheku a écrit: 
>>: Il en est ainsi car les implémentations ne peuvent parfois pas éviter d'insérer 
>>: ces faux réveils; il pourrait être coûteux de les empêcher.

>> Mais pourquoi? Pourquoi est-ce si difficile? Par exemple, parlons-nous de
>> des situations où une attente expire juste au moment où un signal arrive? 

> Vous savez, je me demande si les concepteurs de pthreads ont utilisé une logique comme celle-ci: 
> les utilisateurs de variables de condition doivent de toute façon vérifier la condition à la sortie, 
> nous ne leur imposerons donc aucune charge supplémentaire si nous permettons 
> faux réveils; et puisqu'il est concevable qu'autoriser des
> les réveils pourraient accélérer la mise en œuvre, cela ne peut aider que si nous 
> leur permettre. 

> Ils n'avaient peut-être aucune implémentation particulière en tête. 

Vous n'êtes en fait pas loin du tout, sauf que vous ne l'avez pas poussé assez loin. 

L'intention était de forcer un code correct / robuste en exigeant des boucles de prédicat. C'était
conduit par le contingent académique prouvé correct parmi les "threads de base" dans 
le groupe de travail, même si je ne pense pas que quiconque soit vraiment en désaccord avec l'intention 
une fois qu'ils ont compris ce que cela signifiait. 

Nous avons suivi cette intention avec plusieurs niveaux de justification. Le premier était que
"religieusement" l'utilisation d'une boucle protège l'application contre ses propres imperfections 
pratiques de codage. La seconde était qu'il n'était pas difficile d'imaginer abstraitement
machines et code d'implémentation qui pourraient exploiter cette exigence pour améliorer 
la performance des opérations d'attente de condition moyenne en optimisant 
mécanismes de synchronisation. 
/ ------------------ [David.Buten ... @ compaq.com] ------------------ \ 
| Compaq Computer Corporation POSIX Thread Architect |
| Mon livre: http://www.awl.com/cseng/titles/0-201-63392-2/ |
\ ----- [http://home.earthlink.net/~anneart/family/dave.html] ----- / 

Il y a au moins deux choses que pourrait signifier un `` faux réveil '':

• Un thread bloqué dans pthread_cond_waitpeut revenir de l'appel même si aucun appel vers pthread_call_signalou pthread_cond_broadcastsur la condition ne s'est produit.
• Un thread bloqué dans les pthread_cond_waitretours en raison d'un appel à pthread_cond_signalou pthread_cond_broadcast, cependant, après la réacquisition du mutex, le prédicat sous-jacent s'avère ne plus être vrai.

Mais ce dernier cas peut se produire même si l'implémentation de la variable de condition ne permet pas le premier cas. Considérez une file d'attente de consommateurs de producteurs et trois threads.

• Le thread 1 vient de retirer un élément de la file d'attente et de libérer le mutex, et la file d'attente est maintenant vide. Le thread fait tout ce qu'il fait avec l'élément qu'il a acquis sur un processeur.
• Le thread 2 tente de retirer un élément de la file d'attente, mais trouve que la file d'attente est vide lorsqu'elle est vérifiée sous le mutex, les appels pthread_cond_waitet les blocs dans l'appel en attente de signal / diffusion.
• Le thread 3 obtient le mutex, insère un nouvel élément dans la file d'attente, notifie la variable de condition et libère le verrou.
• En réponse à la notification du thread 3, le thread 2, qui attendait la condition, est planifié pour s'exécuter.
• Cependant, avant que le thread 2 n'arrive à accéder au CPU et à saisir le verrou de file d'attente, le thread 1 termine sa tâche en cours et retourne dans la file d'attente pour plus de travail. Il obtient le verrou de file d'attente, vérifie le prédicat et constate qu'il y a du travail dans la file d'attente. Il procède à la suppression de l'élément que le thread 3 a inséré, libère le verrou et fait tout ce qu'il fait avec l'élément que le thread 3 a mis en file d'attente.
• Thread 2 obtient maintenant sur un CPU et obtient le verrou, mais quand il vérifie le prédicat, il trouve que la file d'attente est vide. Le fil 1 `` a volé '' l'objet, donc le réveil semble être faux. Le thread 2 doit à nouveau attendre la condition.

Donc, comme vous devez déjà toujours vérifier le prédicat sous une boucle, cela ne fait aucune différence si les variables de condition sous-jacentes peuvent avoir d'autres types de réveils parasites.

La section "Réveils multiples par signal de condition" dans pthread_cond_signal a un exemple d'implémentation de pthread_cond_wait et pthread_cond_signal qui implique des réveils parasites.

Bien que je ne pense pas que cela ait été envisagé au moment de la conception, voici une raison technique réelle: en combinaison avec l'annulation de thread, il existe des conditions dans lesquelles prendre l'option de se réveiller "faussement" peut être absolument nécessaire, du moins à moins que vous sont disposés à imposer des contraintes très très fortes sur les types de stratégies de mise en œuvre possibles.

Le problème clé est que, si un thread agit sur l'annulation alors qu'il est bloqué pthread_cond_wait, les effets secondaires doivent être comme s'il ne consommait aucun signal sur la variable de condition. Cependant, il est difficile (et très contraignant) de s'assurer que vous n'avez pas déjà consommé un signal lorsque vous commencez à agir sur l'annulation, et à ce stade, il peut être impossible de «re-poster» le signal dans la variable de condition, car vous pouvez être dans une situation où l'appelant de pthread_cond_signalest déjà justifié d'avoir détruit le condvar et libéré la mémoire dans laquelle il résidait.

La tolérance pour un faux réveil vous permet de sortir facilement. Au lieu de continuer à agir sur l'annulation lorsqu'il arrive alors qu'il est bloqué sur une variable de condition, si vous avez peut-être déjà consommé un signal (ou si vous voulez être paresseux, quoi qu'il arrive), vous pouvez déclarer qu'un faux réveil s'est produit à la place, et revenez avec succès. Cela n'interfère pas du tout avec l'opération d'annulation, car un appelant correct agira simplement sur l'annulation en attente la prochaine fois qu'il bouclera et appellera à pthread_cond_waitnouveau.