list :: empty () 멀티 스레드 동작?

다른 스레드가 요소를 가져 오기를 원하는 목록이 있습니다. 비어있을 때 목록을 보호하는 뮤텍스를 잠그지 않으려면 잠그기 empty()전에 확인하십시오 .

전화 list::empty()가 100 % 정확하지 않은 경우 괜찮 습니다. 동시 통화 list::push()와 list::pop()통화가 중단되거나 중단되는 것을 피하고 싶습니다 .

VC ++과 Gnu GCC가 때때로 empty()잘못되고 더 나쁜 것이 없다고 가정해도 안전 합니까?

if(list.empty() == false){ // unprotected by mutex, okay if incorrect sometimes
    mutex.lock();
    if(list.empty() == false){ // check again while locked to be certain
         element = list.back();
         list.pop_back();
    }
    mutex.unlock();
}

전화 list::empty()가 100 % 정확하지 않은 경우 괜찮 습니다.

아니, 괜찮아 목록이 일부 동기화 메커니즘 외부에서 비어 있는지 확인하면 (뮤텍스 잠금) 데이터 경쟁이 있습니다. 데이터 경쟁이 있다는 것은 정의되지 않은 행동을 의미합니다. 정의되지 않은 동작이 있다는 것은 더 이상 프로그램에 대해 추론 할 수 없으며 결과가 "정확"하다는 것을 의미합니다.

정신 건강을 소중히 여긴다면 성능을 확인하고 뮤텍스를 확인한 후에 확인하십시오. 즉, 목록이 올바른 컨테이너가 아닐 수도 있습니다. 작업 내용을 정확히 알려 주시면 더 나은 컨테이너를 제안하실 수 있습니다.

서로에 대해 동기화되지 않은 읽기 및 쓰기 (대부분 이름이 같다고 가정하는 경우 아마도 size멤버에 std::list대해)가 있습니다 . 하나의 스레드가 (외부에서 ) 호출 하고 다른 스레드가 내부에 들어 와서 실행 한다고 상상해보십시오 . 그런 다음 수정중인 변수를 읽습니다. 이것은 정의되지 않은 행동입니다.empty()if()if()pop_back()

일이 어떻게 잘못 될 수 있는지에 대한 예로서 :

충분히 똑똑한 컴파일러 mutex.lock()는 list.empty()반환 값을 변경할 수 없으므로 내부 if검사를 완전히 건너 뛸 수 있으므로 결국 pop_back첫 번째 요소 다음에 마지막 요소가 제거 된 목록이 표시됩니다 if.

왜 그렇게 할 수 있습니까? 에 동기화가 없으므로 list.empty()동시에 변경되면 데이터 경쟁을 구성합니다. 표준에 따르면 프로그램에는 데이터 레이스가 없어야하므로 컴파일러는 당연한 것으로 간주합니다 (그렇지 않으면 거의 최적화를 수행 할 수 없음). 따라서 비 동기화에 대한 단일 스레드 관점을 가정하고 list.empty()일정하게 유지해야한다는 결론을 내릴 수 있습니다.

이것은 코드를 손상시킬 수있는 몇 가지 최적화 (또는 하드웨어 동작) 중 하나 일뿐입니다.