Sagen Sie, Sie haben diesen Code
%Vor%Meine Frage ist, warum brauchen Sie hier eine While-Schleife? Würde pthread_cond_wait nicht einfach warten, bis der Signalisierungsthread cam_video_cond signalisiert? OK, ich weiß, dass Sie möglicherweise einen Fall haben, in dem cam- & gt; status nicht WAIT_DISPAY ist, wenn pthread_cond_wait aufgerufen wird, aber in diesem Fall Sie können es einfach durch eine Bedingung if überprüfen, anstatt while zu verwenden.
Fehle ich hier etwas? Mein Verständnis von pthread_cond_wait ist, dass es nur auf unendlich wartet, wenn cam_video_cond nicht signalisiert wird. Darüber hinaus wird der cam_video_lock Mutex beim Aufruf entsperrt, aber wenn die Bedingung signalisiert wird, wird vor der Rückkehr cam_video_lock zurückgesendet. Habe ich Recht?
Es wird empfohlen, dass alle Threads den Zustand nach der Rückgabe prüfen von pthread_cond_wait , da die Bedingung mehrere Gründe hat könnte nicht wahr sein. Einer dieser Gründe ist ein ungewolltes Aufwecken; das ist, ein Thread wird möglicherweise aufgeweckt, obwohl kein Thread das signalisiert hat Bedingung.
Quelle: Spurious wakeup
Störende Wakeups sind ein Grund, aber legitime, aber fremde Wakeups sind eine andere.
Überlegen Sie:
Sie haben einen Job in eine Warteschlange gestellt.
Sie signalisieren die Zustandsvariable Waking Thread A.
Sie haben einen Job in eine Warteschlange gestellt.
Sie signalisieren die Zustandsvariable Waking Thread B.
Thread A wird geplant, macht den ersten Job.
Thread A findet die Warteschlange nicht leer und erledigt den zweiten Job.
Thread B wird eingeplant, nachdem er geweckt wurde, findet aber die Warteschlange noch leer.
Aus Leistungsgründen ermöglicht es die POSIX-API dem Betriebssystem, den Thread zu aktivieren, auch wenn die Bedingung nicht erfüllt ist (dies wird als bezeichnet Spurious Wakeup ).