3
왜 sem_wait을 신호 처리기 (특히 스레드 당 SIGSEGV 신호)에서 사용할 수 없습니까? 누군가가 응용 프로그램을 중단시킬 예제 시나리오를 줄 수 있습니까? 나는 sem_wait이 모두 재진입과 스레드 안전 인 것 같아 여기에 무슨 문제가 있습니까? 왜 그렇지 않습니까 비동기 안전?sem_wait 및 신호 처리기
A
답변
1
세마포 값이 0 인 동안 응용 프로그램에서 신호를 수신하고 신호를 수신하는 스레드가 세마포 값 (sem_post)을 증가시키는 것으로 간주되는 경우 어떻게됩니까? 그런 다음 시그널 핸들러에서 sem_wait를 호출하면 프로세스가 교착 상태가 될 것입니다.
물론 sem_wait가 비동기 신호 안전 함수 목록에없는 경우 구현시 비강 악마를 호출 할 수 있습니다.
3
비동기 안전은 스레드 안전보다 훨씬 엄격한 요구 사항입니다. 주요 섹션을 사용하여 전역 데이터를 보호하기 위해 프리미티브를 사용하여 스레드 안전 코드를 작성할 수 있습니다. 신호 핸들러는 이것에 의존 할 수 없습니다. 예를 들어, sem_wait 내의 중요한 섹션 안에있을 수 있으며 segfault를 유발하는 작업을 동시에 수행 할 수 있습니다. 이것은 sem_wait의 thread-safe 보호를 깨뜨릴 것이다.
1
sem_wait 이러한 이유로, 신호 처리기에서 사용될 수 없다 :
스레드 A가 호출 sem1에 sem_wait이다. 스레드 A가 완료되면 sem1에 게시됩니다. 그러나 완료되기 전에 신호가 수신 된 후 핸들러가 입력되어 sem1에서 sem_wait를 호출합니다. A는 sem1에 게시 할 A이므로 핸들러는 결코 돌아 오지 않으며 교착 상태가 발생합니다. 이것이 신호 처리기에서 어떤 것도 기다리지 않는 것이 좋은 규칙입니다. ASFAIK의 문제는 충돌보다는 교착 상태와 관련이 있습니다.
또한 외부 인터럽트를 처리 한 다음 신속하게 처리하고있는 신호 처리기의 이상적인 목적을 위배합니다.
마지막으로 SIGSEGV를 처리하는 대신 자신을 없애는 것이 더 나은 목표가 아닙니까?
세마포어가 당신을 보호해야하는 작업 유형 (스레드, 인터럽트, 예외 등)을 추가하는 것이 좋습니다. 이것은 큰 차이를 만듭니다. – gnometorule
관련 : https://stackoverflow.com/questions/14421951/guaranteeing-mutex-safety-with-async-signals/47304426. 나는'sem_wait (& x)'가 같은'x '에있는'sem_wait (& x)'와 충돌하는 것은 분명히 문제라고 생각하지만 기술적으로 아직 정의되지 않은 동작 임에도 불구하고 다른 세마포어로 수행 가능해야한다. – PSkocik