pthread_cond_wait에 스플리어스 웨이크업이 발생하는 이유는 무엇입니까?

pthread_cond_wait에 스플리어스 웨이크업이 발생하는 이유는 무엇입니까?

man 페이지를 인용하려면:

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

그렇게,pthread_cond_wait신호를 보내지 않아도 다시 돌아올 수 있습니다.적어도 얼핏 보면, 그건 꽤 끔찍해 보인다.이는 잘못된 값을 랜덤으로 반환하거나 실제로 올바른 반환문에 도달하기 전에 랜덤으로 반환하는 함수입니다.그것은 큰 벌레처럼 보인다.그러나 그들이 이것을 수정하기 보다는 man 페이지에 기록하는 것을 선택했다는 사실은 왜 그 이유를 정당하게 보여주는 것 같습니다.pthread_cond_wait정신없이 깨어난다.아마도, 그것이 어떻게 작동하는지에 대한 본질적인 무언가가 있기 때문에, 그것은 어쩔 수 없을 것이다.문제는 뭘까?

왜?pthread_cond_wait씩씩하게 돌아오다니?왜 신호가 제대로 잡혔을 때만 깨어난다고 장담할 수 없는 걸까요?누가 그것의 거짓된 행동의 이유를 설명할 수 있나요?

'스플리어스 웨이크업'은 다음 두 가지 이상을 의미합니다.

• 에 막힌 실pthread_cond_wait에의 콜이 없어도 콜에서 복귀할 수 있다.pthread_call_signal또는pthread_cond_broadcast발생한 조건으로
• 에 막힌 실pthread_cond_wait에의 콜에 의한 반환pthread_cond_signal또는pthread_cond_broadcast단, mutex를 재취득한 후 기본 술어가 더 이상 참이 아닌 것으로 판명되었습니다.

그러나 후자의 경우는 조건 변수 구현이 전자의 경우를 허용하지 않더라도 발생할 수 있습니다.생산자 소비자 큐와 세 개의 스레드를 고려합니다.

• 스레드 1은 요소의 큐를 해제하고 뮤텍스를 해방하여 큐가 비어 있습니다.스레드는 일부 CPU에서 취득한 요소를 사용하여 모든 작업을 수행합니다.
• 스레드 2는 요소를 큐 해제하려고 하지만 mutex, calls에서 체크하면 비어 있는 큐를 검출합니다.pthread_cond_wait및 신호/대기를 대기 중인 콜을 차단합니다.
• 스레드 3은 뮤텍스를 취득하여 큐에 새로운 요소를 삽입하고 조건 변수에 통지하여 잠금을 해제합니다.
• 스레드 3으로부터의 통지에 응답하여 조건을 기다리고 있던 스레드2가 실행되도록 스케줄 되어 있습니다.
• 단, 스레드2가 CPU에 접속하여 큐 잠금을 취득하기 전에 스레드1은 현재 작업을 완료하고 큐로 돌아가 더 많은 작업을 수행합니다.큐 잠금을 취득하여 술어를 체크하고 큐에 작업이 있음을 검출합니다.스레드 3이 삽입한 아이템을 큐 해제하고 잠금을 해제하며 스레드 3이 큐잉한 아이템에 대해 모든 작업을 수행합니다.
• 스레드 2는 CPU에 접속하여 잠금을 취득하지만 술어를 체크하면 큐가 비어 있음을 알 수 있습니다.스레드 1은 항목을 '스폴'하기 때문에 웨이크업 상태가 가짜인 것 같습니다.스레드 2는 그 조건으로 다시 대기해야 합니다.

따라서 루프의 술어는 항상 체크해야 하므로 기본 조건 변수에 다른 종류의 스플리어스 웨이크업이 있을 수 있어도 아무런 차이가 없습니다.

David R에 의해 다음과 같이 설명됩니다.POSIX 스레드를 사용한 프로그래밍(80페이지):

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

다음 comp.programming에서.스레드 토론을 통해 설계의 이면에 있는 사고를 확장합니다.

패트릭 도일은 이렇게 썼다.> Tom Payne은 기사에서 다음과 같이 썼다.Kaz Kylheku는 다음과 같이 썼다.>>: 구현 시 삽입을 피할 수 없는 경우가 있기 때문입니다.>>: 이러한 가짜 웨이크업. 이를 방지하려면 비용이 많이 들 수 있습니다. 

그런데 왜?이게 왜 이렇게 어려워?예를 들어, 우리가 말하는 것은신호가 도착하자마자 대기시간이 타임아웃되는 경우 

pthreads의 설계자는 다음과 같은 논리를 사용했을까요?> condition 변수 사용자는 종료 시 상태를 체크해야 합니다.>그러기 때문에, 가능하다면, 추가의 부담은 없습니다.> 스플리어스 웨이크업, 스플리어스 허용 가능> Wake up을 통해 구현 시간을 단축할 수 있습니다.이것에 도움이 되는 것은,> 허용한다. 

> 특정 실장을 염두에 두고 있지 않았을 수 있습니다. 

사실 그렇게 멀리 가지 않았다는 것만 빼면요 

그 목적은 술어 루프를 요구함으로써 올바른/강력한 코드를 강제하는 것이었다.이게 뭐냐면...에서의 '핵심'들 사이에서 입증할 수 있을 만큼 정확한 학술적 결과에 의해 추진된다.작업 그룹은, 그 의도에 동의하지 않는 사람은 없다고 생각합니다만,그게 무슨 뜻인지 알게 되면요 

우리는 몇 가지 수준의 정당성을 가지고 그 의도를 따랐다.첫 번째는요.루프를 '종교적으로' 사용하여 애플리케이션 자체의 불완전성으로부터 보호코드화 방법.두 번째는 추상적으로 상상하는 것이 어렵지 않았다는 것이다.이 요건을 악용하여 개선할 수 있는 머신과 구현 코드평균 조건 대기 동작의 퍼포먼스를 최적화하여동기 메커니즘 
/------------------------------------------------------부텐...@compaq.com ]-------------------------------------\| Compaq Computer Corporation POSIX 스레드 아키텍트 || 제 책 : http://www.awl.com/cseng/titles/0-201-63392-2/ |\---[ http://home.earthlink.net/ ~anneart / family / family . https ]-----/

pthread_cond_signal의 "Multiple Awakeing by Condition Signal" 섹션에는 pthread_cond_wait 및 pthread_cond_signal의 구현 예가 있으며, 여기에는 스플리어스 웨이크업이 포함됩니다.

설계 당시에는 고려되지 않았던 것 같습니다만, 실제 기술적인 이유는 다음과 같습니다.스레드 취소와 조합하여 어떤 종류의 구현 전략이 가능한지에 대해 매우 강력한 제약을 가할 의사가 없는 한 "스파이시하게" 웨이크업 옵션을 선택해야 하는 조건이 있습니다.

중요한 문제는 스레드가 차단되어 있는 동안 취소 시 동작하는 경우입니다.pthread_cond_wait부작용은 조건변수에서 어떤 신호도 소비하지 않은 것처럼 보여야 합니다.단, 취소처리를 시작할 때 이미 신호를 소비하지 않았는지 확인하는 것은 어렵고(또한 매우 제약이 있습니다), 이 단계에서 조건변수에 신호를 "재포스트"하는 것은 불가능할 수 있습니다.이것은, 발신자가 다음의 상황에 있는 경우가 있기 때문입니다.pthread_cond_signalcondvar를 파괴하고 condvar가 상주했던 메모리를 해방한 것은 이미 정당화되어 있습니다.

스플리어스 웨이크 허용으로 쉽게 빠져나갈 수 있습니다.조건변수로 차단되어 있을 때 취소처리를 계속하는 것이 아니라 이미 신호를 소비하고 있는 경우(또는 어떤 경우에도 게으름을 피우고 싶은 경우), 대신 스플리어스 웨이크가 발생했다고 선언하고 정상적으로 복귀할 수 있습니다.이것은 취소 조작에 전혀 방해가 되지 않습니다.올바른 발신자는 다음에 루프하여 호출할 때 보류 중인 취소에 대해 조치를 취하기만 하면 되기 때문입니다.pthread_cond_wait

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