214 votes

Fausses réveils effectivement le cas ?

Voyant de verrouillage différents liés à la question et (presque) toujours trouver la boucle parce que de fausses réveils " conditions1 , je me demande, quelqu'un a connu ce genre de un réveil (en supposant un matériel décent/environnement logiciel par exemple)?

Je sais que le terme "parasites" signifie, sans raison apparente, mais quelles peuvent être les raisons de ce genre d'événement?

(1 Note: je ne mets pas en question la boucle de la pratique.)

Edit: Un assistant de question (pour ceux qui aiment les exemples de code):

Si j'ai le programme suivant, et je le lance:

public class Spurious {
    public static void main(String[] args) {
        Lock lock = new ReentrantLock();
        Condition cond = lock.newCondition();
        lock.lock();
        try {
            try {
                cond.await();
                System.out.println("Spurious wakeup!");
            } catch (InterruptedException ex) {
                System.out.println("Just a regular interrupt.");
            }
        } finally {
            lock.unlock();
        }
    }
}

Que puis-je faire pour réveiller ce await jusqu'faussement, sans attendre une éternité pour un événement aléatoire?

209voto

John Kugelman Points 108754

La Wikipedia article sur la base de fausses réveils a cette friandise:

L' pthread_cond_wait() fonction dans Linux est mis en œuvre à l'aide de l' futex appel système. Chaque blocage des appels système sous Linux retourne brusquement, EINTR lorsque le processus reçoit un signal. ... pthread_cond_wait() peut pas redémarrer l'attente parce qu'il peut manquer d'un vrai réveil du peu de temps qu'il était à l'extérieur de l' futex appel système. Cette condition ne peut être évitée que par l'appelant de la vérification pour un invariant. Une POSIX signal va donc générer un faux réveil.

Résumé: Si un processus Linux est signalé son threads en attente à chacun de profiter d'une belle, chaude fallacieux de réveil.

- Je l'acheter. C'est plus facile une pilule à avaler que la vague "c'est pour la performance" raison souvent invoquée.

23voto

Mr.Dirty.Birdy Points 101

J'ai un système de production qui présente ce comportement. Un thread attend un signal qu'il y a un message dans la file d'attente. Dans les périodes de pointe, jusqu'à 20% de la réveils sont fausses (c'est à dire quand il se réveille il n'y a rien dans la file d'attente). Ce fil est le seul consommateur de messages. Il fonctionne sur Linux SLES-10 8-processeur boîte et est construit avec GCC 4.1.2. Les messages proviennent d'une source externe et sont traitées de manière asynchrone, car il y a des problèmes si mon système ne permet pas de lire assez rapidement.

16voto

Aniket Thakur Points 10135

Pour répondre à la question dans le titile - Oui! c'est le cas.Si le Wiki de l'article mentionne une bonne affaire sur les parasites des réveils une belle explication pour la même que j'ai trouvé est la suivante -

Il suffit de penser... comme n'importe quel code, planificateur de threads peut expérience temporaire d'interdiction en raison de quelque chose d'anormal qui se passe dans le sous-jacentes de matériel / logiciel. Bien sûr, les soins devraient être prises pour que cela arrive aussi rares que possible, mais depuis il n'y a pas une telle chose comme 100% logicielle robuste, il est raisonnable de supposer ce qui peut arriver et de prendre soin sur les gracieuses de récupération dans le cas où si le planificateur de le détecte (par exemple par l'observation de pulsations manquantes).

Maintenant, comment pourrait-planificateur de récupérer, en tenant compte du fait que pendant blackout il pourrait manquer des signaux destinés à informer les threads en attente? Si le planificateur ne fait rien, mentionné "malchanceux" fils va se pendre, en attente pour toujours - pour éviter cela, planificateur serait tout simplement d'envoyer un signal à tous les threads en attente.

Cela rend nécessaire la création d'un "contrat" que le thread en attente peut être notifié sans raison. Pour être précis, il y aurait une raison - planificateur de blackout, mais depuis le thread est conçu (pour une bonne raison) d'être insensible à planificateur de la mise en œuvre interne de détails, cette raison est probablement préférable de les présenter comme des "parasites".

J'ai été la lecture de cette réponse de la Source et l'a trouvé assez raisonnable.

9voto

oxbow_lakes Points 70013

Cameron Purdy a écrit un blog post tout à l’heure à être touché par le problème de réactivation fallacieux. Alors oui, il arrive

Je devine que c’est dans les spécifications (comme une possibilité) en raison des limitations de certains des plates-formes Java obtient déployée sur ? même si je peux me tromper !

8voto

ReneS Points 1526

Juste pour ajouter ceci. Oui il arrive et j’ai passé trois jours à la recherche de la cause d’un problème de multi-threading sur un ordinateur de 24 cœurs (JDK 6). 4 des 10 exécutions connu cela sans n’importe quel modèle. Ce n’est jamais arrivé sur core 2 ou 8 cœurs.

A étudié certains contenus en ligne et ce n’est pas un problème de Java, mais un comportement général de rare mais attendu.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X