Joe Duffy "la Programmation Simultanée Sur Windows" mentionne ce (P311-312, P598). Ce bit est intéressant:
Note que dans tous les exemples ci-dessus, les threads doivent faire face à quelque chose qui s'appelle les fausses wake-up - code qui utilise les variables de condition devrait rester correct et animée, même dans les cas où il est réveillé prématurément, qui est, avant de l'affection recherchée a été établi. Ce n'est pas parce que la mise en œuvre sera effectivement faire ce genre de choses (bien que certaines implémentations sur d'autres plates-formes telles que Java et des Pthreads sont connus pour le faire), ni au fait que le code va se réveiller fils intentionnellement lorsqu'il n'est pas nécessaire, mais plutôt en raison du fait qu'il n'existe aucune garantie autour de quand un thread qui a été éveillé va devenir prévue. Les variables de Condition ne sont pas justes. Il est possible - et même probable - que l'autre thread va acquérir les associés de verrouillage et faire la condition faux à nouveau avant de l'éveillé thread a une chance d'acquérir le verrou et le retour à la région critique.
Ensuite, il donne le rythme normal pour une boucle while test de la condition.
Je dirais qu'à partir de ce qu'il est raisonnable de s'attendre à ce qu' Monitor.Wait
ne sera pas normalement vous réveiller prématurément, et que si vous devez absolument savoir que rien d'autre ne peut avoir changé la condition, alors vous pourriez être en mesure de s'en tirer sans la condition de la boucle: mais qu'il est préférable de l'inclure de toute façon, juste au cas où votre logique est erronée.