pthread_cond_wait에는 왜 가짜 웨이크 업이 있습니까?

pthread_cond_wait에는 왜 가짜 웨이크 업이 있습니까?

---

매뉴얼 페이지를 인용하려면 :

조건 변수를 사용할 때 스레드가 계속 진행되어야하는 경우 각 조건 대기와 연관된 공유 변수와 관련된 부울 술어가 항상 있습니다. pthread_cond_timedwait () 또는 pthread_cond_wait () 함수에서 가짜 웨이크 업이 발생할 수 있습니다. pthread_cond_timedwait () 또는 pthread_cond_wait ()의 리턴은이 술어 값에 대해 아무 것도 암시하지 않으므로 해당 리턴시 술어를 다시 평가해야합니다.

그래서, pthread_cond_wait당신이 그것을 신호하지 않은 경우에도 반환 할 수 있습니다. 언뜻보기에는 꽤 끔찍한 것 같습니다. 그것은 잘못된 값을 무작위로 반환하거나 실제로 올바른 반환 문에 도달하기 전에 무작위로 반환되는 함수와 같습니다. 큰 버그 인 것 같습니다. 그러나 그들이 수정하기보다는 매뉴얼 페이지에서 이것을 문서화하기로 선택한 사실은 pthread_cond_wait가짜로 깨어나는 이유가 합법적 인 이유가 있음을 나타냅니다 . 아마도 도움이 될 수 없도록 작동하는 방식에 본질적인 것이있을 것입니다. 문제는 무엇입니까.

왜 않는 pthread_cond_wait가짜로 복귀? 신호가 올 바르면 깨어날 것이라고 보장 할 수없는 이유는 무엇입니까? 누구나 가짜 행동의 이유를 설명 할 수 있습니까?

---

다음 설명은 David R. Butenhof가 "POSIX 스레드 프로그래밍" (80 페이지)에서 제공합니다.

스퓨리어스 웨이크가 이상하게 들릴 수 있지만 일부 멀티 프로세서 시스템에서 상태 웨이크 업을 완전히 예측 가능하게하면 모든 조건 변수 작업이 상당히 느려질 수 있습니다.

다음 comp.programming.threads 토론 에서 그는 디자인의 기본 개념을 확장합니다.

Patrick Doyle은 다음과 같이 썼습니다. 
> 기사에서 Tom Payne은 다음과 같이 썼습니다. 
Kaz Kylheku는 다음과 같이 썼다. 
>> : 구현이 때때로 삽입을 피할 수 없기 때문에 
>> :이 가짜 모닝콜; 이를 방지하는 데 비용이 많이들 수 있습니다.

그러나 왜? 왜 이렇게 어려운가요? 예를 들어서
신호가 도착하는 것처럼 대기 시간이 초과되는 상황은 무엇입니까? 

> pthreads 디자이너가 다음과 같은 논리를 사용했는지 궁금합니다. 
> 조건 변수 사용자는 종료시 조건을 확인해야합니다. 
> 허용 할 경우 추가 부담을주지 않습니다. 
> 가짜 모닝콜; 그리고 스퓨리어스를 허용하는 것을 생각할 수 있기 때문에
> 깨어 나면 구현이 더 빨라질 수 있습니다. 
> 허용하십시오. 

> 특정 구현을 염두에 두지 않았을 수 있습니다. 

당신은 그것을 멀리 밀어 넣지 않았다는 것을 제외하고는 실제로 전혀 멀지 않습니다. 

목적은 술어 루프를 요구하여 올바른 / 강건한 코드를 작성하는 것이 었습니다. 이했다
의 "핵심 실"중에 아마도 정확한 학문적 우발에 의해 구동 
실무 그룹, 나는 아무도 의도에 동의하지 않는다고 생각하지 않습니다. 
일단 그들은 그것이 무엇을 의미하는지 이해했습니다. 

우리는 몇 가지 수준의 정당화로 그 의도를 따랐습니다. 첫 번째는
"유연하게"루프를 사용하면 응용 프로그램 자체의 불완전 성을 방지합니다 
코딩 관행. 두 번째는 추상적으로 상상하기 어렵지 않다는 것입니다
이 요구 사항을 이용하여 개선 할 수있는 기계 및 구현 코드 
최적화를 통한 평균 조건 대기 작업의 성능 
동기화 메커니즘. 
/ ------------------ [David.Buten ... @ compaq.com] ------------------ \ 
| Compaq Computer Corporation POSIX 스레드 설계자 |
| 나의 책 : http://www.awl.com/cseng/titles/0-201-63392-2/ |
\ ----- [http://home.earthlink.net/~anneart/family/dave.html] ----- / 

---

'스퓨리어스 웨이크 업'이 의미 할 수있는 최소한 두 가지가 있습니다.

• A thread blocked in pthread_cond_wait can return from the call even though no call to signal or broadcast on the condition occurred.
• A thread blocked in pthread_cond_wait returns because of a call to signal or broadcast, however after reacquiring the mutex the underlying predicate is found to no longer be true.

But the latter case can occur even if the condition variable implementation does not allow the former case. Consider a producer consumer queue, and three threads.

• Thread 1 has just dequeued an element and released the mutex, and the queue is now empty. The thread is doing whatever it does with the element it acquired on some CPU.
• Thread 2 attempts to dequeue an element, but finds the queue to be empty when checked under the mutex, calls pthread_cond_wait, and blocks in the call awaiting signal/broadcast.
• Thread 3 obtains the mutex, inserts a new element into the queue, notifies the condition variable, and releases the lock.
• In response to the notification from thread 3, thread 2, which was waiting on the condition, is scheduled to run.
• However before thread 2 manages to get on the CPU and grab the queue lock, thread 1 completes its current task, and returns to the queue for more work. It obtains the queue lock, checks the predicate, and finds that there is work in the queue. It proceeds to dequeue the item that thread 3 inserted, releases the lock, and does whatever it does with the item that thread 3 enqueued.
• Thread 2 now gets on a CPU and obtains the lock, but when it checks the predicate, it finds that the queue is empty. Thread 1 'stole' the item, so the wakeup appears to be spurious. Thread 2 needs to wait on the condition again.

So since you already always need to check the predicate under a loop, it makes no difference if the underlying condition variables can have other sorts of spurious wakeups.

---

Section "Multiple Awakenings by Condition Signal" in pthread_cond_signal has an example implementation of pthread_cond_wait and pthread_cond_signal which involves spurious wakekups.

참고URL : https://stackoverflow.com/questions/8594591/why-does-pthread-cond-wait-have-spurious-wakeups