이 질문은 Breaking a condition variable deadlock에서옵니다. 여러 스레드가 조건 변수에서 대기 중일 수 있습니다. 특정 스레드에서만 스레드 1을 말하고 교착 상태 시나리오의 참가자 인 것처럼 스레드에게 신호를 보내야합니다. 내가 단편적인 실을 신호로 보낼 수있는 방법이 있나.조건 변수를 기다리는 많은 스레드 중 특정 스레드에게 신호 보내기
어떤 도움을
감사
편집 gratefull이 될 것이다 Nemo의 의견을 존중합니다. 나는 이것이 나쁜 생각이라는 것을 이해합니다. 그러나 할 수있는 방법이 있습니까
지연 취소 지점을 사용할 수 있습니다. 스레드에서 pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldstate);을 사용하십시오 (이것이 기본값이지만 명시적일 필요는 없습니다). pthread_setcancelstate을 사용하여 취소를 비활성화하십시오. 취소 할 수 있기를 기다리는 조건 변수는 예외입니다. 취소 클린업 핸들러를 설정하려면 pthread_cleanup_push을 사용해야합니다. 이것은 RAII와 잘 어울리지 않습니다.
이제 스레드를 pthread_cancel 할 수 있습니다. 취소 정리 처리기가 등록 순서의 역순으로 실행되고 TLS 데이터 소멸자가 호출되고 스레드가 종료됩니다 (조건 변수 wait에서 돌아 가지 않음).
물론 이것은 다소 못 생기는 디자인입니다. 이상적으로는 교착 상태를 피해야합니다. 그게 가능하지 않다면, 나라면, 한 번에 하나의 cvar를 차단하는 단 하나의 스레드를 준비하고, 여러 cvar를 처리하기 위해이 cvars를 기반으로 상위 수준 (명시적인 웨이터 목록)을 작성하십시오. 웨이터가 스레드를 개별적으로 주소 지정할 수있게합니다.
조금 더 자세히 설명해 주시겠습니까? 취소를 가능하게하고 상태 변수를 기다리는 사이에는 근본적인 경쟁 조건이 존재하지 않습니까? 즉, 뮤텍스를 잡고 취소를 허용 한 다음 cond var에서 기다리려고합니다.하지만 그동안 뮤텍스를 보유하고있는 동안 누군가가 교착 상태에 빠졌다고 결정합니까? – Nemo
@Nemo, pthread_cond_wait 맨 페이지에서 : "조건 대기 (시간 초과 여부와 상관 없음)는 취소 지점입니다.스레드의 취소 가능성 활성화 상태가 PTHREAD_CANCEL_DEFERRED로 설정되면 조건 대기 중에 취소 요청시 작동하는 부작용은 첫 번째 취소 정리 처리기를 호출하기 전에 뮤텍스가 다시 획득된다는 것입니다. "그래서 정리 핸들러는 뮤텍스를 릴리스해야합니다. – bdonlan
필요한 코드를 정확하게 작성하십시오. 조건 변수는이 동작을 제공하지 않으므로 지름길은 없습니다. 그래서 그냥 써주세요. 그것에 대해 어려운 점은 없습니다. 예를 들어 특수 플래그를 설정하고 조건 변수에서 차단 된 모든 스레드를 깨우고 스레드를 다시 작성하여 플래그를 확인하여 다시 절전 모드로 되돌아 가야하는지 확인할 수 있습니다.
확률이 1에 가까울수록 설계에 결함이 있습니다. 거의 확실하게 "교착 상태를 감지하고 그것에 참여하고있는 스레드 중 하나를 죽이기"를 원하지는 않습니다. 교착 상태가 발생하지 않도록 기본 디자인을 수정하려고합니다. – Nemo
@ Nemo ... 나는 당신과 동의합니다. 그러나 우리의 경우에는 교착 상태가 발생할 확률이 매우 낮기 때문에 교착 상태를 감지하고 해결하는 대신 교착 상태를 감지하고 해결합니다. –
미안 @ 저글러,하지만 그 철학을 사지 않아. 이것은 소프트웨어입니다. "극히 드문 경우"와 같은 것은 없습니다. "절대"와 "버그"만 있습니다. 또는 요다가 말했듯이, 아무런 시도도 없습니다. – Nemo