Dlaczego potrzebujemy pętli while czekając na stan zmiennej

Question

Powiedzmy, że masz ten kod

pthread_mutex_lock(&cam->video_lock); 
while(cam->status == WAIT_DISPLAY) // <-- Why is this a 'while' and not an 'if'? 
    pthread_cond_wait(&cam->video_cond, &cam->video_lock); 
pthread_mutex_unlock(&cam->video_lock); 

Moje pytanie brzmi, dlaczego trzeba pętli while tutaj. Czy nie czekałoby pthread_cond_wait, aż wątek sygnalizacyjny sygnalizuje cam_video_cond? OK, wiem, że możesz mieć sprawę gdzie cam-> Stan nie jest równa WAIT_DISPAY gdy pthread_cond_wait nazywa, ale w tym przypadku można po prostu sprawdzić go przez jeżeli stanie zamiast używać chwilę.

Czy tu czegoś brakuje? Moje rozumienie pthread_cond_wait jest to, że po prostu czeka na nieskończony, jeśli cam_video_cond nie jest sygnalizowane. Co więcej, odblokowuje on mutex cam_video_lock po wywołaniu, ale gdy stan jest sygnalizowany, przed powrotem zwraca się do cam_video_lock. Czy mam rację?

Answer 1

Zaleca się, aby wszystkie wątki sprawdzić stan po powrocie z pthread_cond_wait ponieważ istnieje kilka powodów stan nie może być prawda. Jednym z tych powodów jest fałszywe przebudzenie; to jest, wątek może się obudzić, nawet jeśli żaden wątek nie sygnalizuje stanu .

Źródło: Spurious wakeup

Answer 2

Ze względów wydajnościowych interfejs POSIX API umożliwia systemowi przebudzenie wątku, nawet jeśli warunek ten nie został spełniony (to się nazywa spurious wakeup).

Answer 3

Niepożądane wybudzeń są jednym z powodów, ale uzasadnione, ale obce wybudzeń są innego.

Rozważmy:

1. umieścić pracę w kolejce.

2. można sygnalizować zmienną warunku, budząc wątek A.

3. umieścić pracę w kolejce.

4. można sygnalizować zmienną warunku, budząc wątek B.

5. nawlec zostanie zaplanowane, czy pierwsza praca.

6. Wątek A stwierdza, że ​​kolejka nie jest pusta i wykonuje drugie zadanie.

7. Wątek B zostaje zaplanowany, po przebudzeniu, ale stwierdza, że ​​kolejka jest pusta.