뮤텍스를 잠그지 않고 pthread_cond_signal 호출

뮤텍스를 잠그지 않고 pthread_cond_signal 호출

---

pthread_cond_signal 을 호출하기 전에 뮤텍스 를 잠그고 호출 한 후 mutext를 잠금 해제 해야한다는 내용을 읽었 습니다.

pthread_cond_signal () 루틴은 조건 변수에서 대기중인 다른 스레드를 신호 (또는 깨우기)하는 데 사용됩니다. 뮤텍스가 잠긴 후에 호출되어야하며 pthread_cond_wait () 루틴이 완료 되려면 뮤텍스를 잠금 해제해야합니다.

내 질문은 : 뮤텍스를 잠그지 않고 pthread_cond_signal 또는 pthread_cond_broadcast 메서드 를 호출해도 괜찮지 않습니까?

---

조건과 신호를 변경하는 코드 경로에서 뮤텍스를 잠그지 않으면 wakeup이 손실 될 수 있습니다. 다음 프로세스 쌍을 고려하십시오.

프로세스 A :

pthread_mutex_lock(&mutex);
while (condition == FALSE)
    pthread_cond_wait(&cond, &mutex);
pthread_mutex_unlock(&mutex);

프로세스 B (잘못된) :

condition = TRUE;
pthread_cond_signal(&cond);

그런 다음 다음 condition과 같이 시작하는 명령의 인터리빙 가능성을 고려하십시오 FALSE.

Process A                             Process B

pthread_mutex_lock(&mutex);
while (condition == FALSE)

                                      condition = TRUE;
                                      pthread_cond_signal(&cond);

pthread_cond_wait(&cond, &mutex);

은 condition지금 TRUE하지만, 프로세스 A는 조건 변수에 붙어 대기 - 그것은 웨이크 업 신호를 놓쳤다. 프로세스 B를 변경하여 뮤텍스를 잠그면 :

프로세스 B (정확함) :

pthread_mutex_lock(&mutex);
condition = TRUE;
pthread_cond_signal(&cond);
pthread_mutex_unlock(&mutex);

... 위의 상황이 발생할 수 없습니다. 웨이크 업은 절대 놓치지 않을 것입니다.

( 실제로 자체를. 뒤에 이동할 수 있지만 이로 인해 스레드의 최적 스케줄링이 떨어질 수 있으며 조건 자체를 변경하기 때문에이 코드 경로에 이미 뮤텍스를 잠근 것입니다).pthread_cond_signal()pthread_mutex_unlock()

---

이 설명서에 따르면 :

pthread_cond_broadcast()또는 pthread_cond_signal()기능 은 현재 뮤텍스 소유 여부를 스레드에 의해 호출 할 수 있습니다 스레드가 호출하는 것을 pthread_cond_wait()나 pthread_cond_timedwait()자신을 기다리는 동안 조건 변수와 관련된 한을; 예측 가능한 일정 행동이 필요한 경우, 그 뮤텍스는 스레드의 호출에 의해 고정된다 pthread_cond_broadcast()거나 pthread_cond_signal().

예측 가능한 스케줄링 동작 명령문 의 의미는 Comp.programming.threads에서 Dave Butenhof ( POSIX 스레드를 사용한 프로그래밍의 저자)에 의해 설명되었으며 여기에서 사용할 수 있습니다 .

---

샘플 코드에서 프로세스 B는 condition먼저 뮤텍스를 잠그지 않고 수정합니다 . 프로세스 B가 수정하는 동안 단순히 뮤텍스를 잠근 다음을 호출하기 전에 뮤텍스를 잠금 해제하면 pthread_cond_signal문제가 없을 것입니다 .--- 내가 맞습니까?

저는 직관적으로 caf의 위치 가 옳다고 믿습니다 pthread_cond_signal. 뮤텍스 잠금을 소유하지 않고 호출 하는 것은 나쁜 생각입니다. 그러나 caf의 예 는 실제로이 입장을 뒷받침하는 증거가 아닙니다. 뮤텍스를 먼저 잠그지 않는 한 뮤텍스에 의해 보호되는 공유 상태를 수정하는 것이 나쁜 생각이라는 훨씬 약한 (실질적으로 자명 한) 입장을 뒷받침하는 증거 일뿐입니다.

누구든지 호출 pthread_cond_signal후 pthread_mutex_unlock올바른 동작 을 생성하지만 호출 pthread_mutex_unlock후 pthread_cond_signal잘못된 동작 을 생성 하는 샘플 코드를 제공 할 수 있습니까 ?

참고 URL : https://stackoverflow.com/questions/4544234/calling-pthread-cond-signal-without-locking-mutex