unp 2권에 7장에
mutex between processes , read-write locks , posix semaphore의 경우 lock을 얻은후 프로세스가 종료하면(unlock하기전에) 시스템이 자동적으로 lock을 해제시키지 않는다고 하네요.
유일하게 record locking만이 커널에서 프로세스 종료시 lock을 자동으로 해제한다고 되어있네요.
또, System V 세마포가 위에분 말씀대로 커널이 아닌 application수준에서 세마포lock을 해제할지 안할지 SEM_UNDO를 사용해서 결정할수있다고 하네요.
우선 질문하신 sem_post는 SYSTEM V계열의 세마포어가 아니고,
쓰레드 concurrency control 관련함수네요.
이러한 것을 가진 쓰레드 혹은 프로세스는
(여기는 프로세스라고 예를 드는 이유는 process shared
mutex가 POSIX Thread 표준의 optional로 명시되어 있기
때문입니다.)
해당 Mutex 혹은 semaphore를 획득후 종료하면,
절대로 해제가 불가능하다고 보셔야 합니다.
이러한 예외의경우가 두가지가 있는데
첫째, fcntl을 이용한 file record locking이고,
두번째가 시스템 세마포어를 이용한 SEM_UNDO 옵션입니다.
그외의 경우에는 일단 안된다고 보시구요,
이러한 문제를 posix thread 입안자들이 고려를 해서
thread cancellation 과정에서 해당 mutex를 자동으로 unlock할
수 있도록 push, pop 관련 api를 만들어 놓았습니다.
그러나, 해당 쓰레드, 프로세스가 비정상적으로 종료할경우
획득한 상태의 mutex는 해제가 불가능하므로,
조심해서 사용하시기 바랍니다.
그럼 이만.
뱀꼬리) 제가 테스트해 본 바에 의하면 실제와는 다르게
mutex획득후 쓰레드 종료로 인해 무한 대기 mutex의 상태는
제3의 쓰레드 혹은 프로세스에 의해 unlock이 가능했었습니다.
그러나, 이러한 트릭은 표준이 아니므로, 사용해서는
안되겠죠.
semaphore action을 보면, undo 에 대한 것이 있을 것입
semaphore action을 보면, undo 에 대한 것이 있을 것입니다. (SEM_UNDO)
pid가 죽었을 경우에 -1 을 자동으로 해준다는 것이지요.
마땅한 예제가 안떠오르네요.
Stevens 책에도 사실 복잡하게나마 설명돼있지요.
---
http://coolengineer.com
Lock을 가지는동안 프로세스 종료
unp 2권에 7장에
mutex between processes , read-write locks , posix semaphore의 경우 lock을 얻은후 프로세스가 종료하면(unlock하기전에) 시스템이 자동적으로 lock을 해제시키지 않는다고 하네요.
유일하게 record locking만이 커널에서 프로세스 종료시 lock을 자동으로 해제한다고 되어있네요.
또, System V 세마포가 위에분 말씀대로 커널이 아닌 application수준에서 세마포lock을 해제할지 안할지 SEM_UNDO를 사용해서 결정할수있다고 하네요.
Re: 세마포로 Lock을 걸고 안에서 죽는다면.
세마포를 만드실때 유동화해서 만들지 마시고 고정 세마포를 만드셨다면
다른 프로세스에서 죽이는게 가능합니다.
다음은 쉘상에서 세마포 관련 유틸입니다. 그냥 참고하세요.
ipcs
ipcrm
sem_post.. 관련.
질문과 답변이 서로 다른 이야기를 하고 있네요..^^
우선 질문하신 sem_post는 SYSTEM V계열의 세마포어가 아니고,
쓰레드 concurrency control 관련함수네요.
이러한 것을 가진 쓰레드 혹은 프로세스는
(여기는 프로세스라고 예를 드는 이유는 process shared
mutex가 POSIX Thread 표준의 optional로 명시되어 있기
때문입니다.)
해당 Mutex 혹은 semaphore를 획득후 종료하면,
절대로 해제가 불가능하다고 보셔야 합니다.
이러한 예외의경우가 두가지가 있는데
첫째, fcntl을 이용한 file record locking이고,
두번째가 시스템 세마포어를 이용한 SEM_UNDO 옵션입니다.
그외의 경우에는 일단 안된다고 보시구요,
이러한 문제를 posix thread 입안자들이 고려를 해서
thread cancellation 과정에서 해당 mutex를 자동으로 unlock할
수 있도록 push, pop 관련 api를 만들어 놓았습니다.
그러나, 해당 쓰레드, 프로세스가 비정상적으로 종료할경우
획득한 상태의 mutex는 해제가 불가능하므로,
조심해서 사용하시기 바랍니다.
그럼 이만.
뱀꼬리) 제가 테스트해 본 바에 의하면 실제와는 다르게
mutex획득후 쓰레드 종료로 인해 무한 대기 mutex의 상태는
제3의 쓰레드 혹은 프로세스에 의해 unlock이 가능했었습니다.
그러나, 이러한 트릭은 표준이 아니므로, 사용해서는
안되겠죠.
고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.
정리하자면,세마포어 사용시, lock걸다가 종료되었을경우,
정리하자면,
세마포어 사용시, lock걸다가 종료되었을경우,
system V 세마포어에서는, 다른 프로세스들이 lock을 걸수있고
POSIX semaphore에서는, 다른 쓰레드들이 lock을 걸수없다.. 네요.
맞죠??? ^^a
항상 감사하는 마음으로...
댓글 달기