쓰레드프로그래밍 질문요......흑흑
글쓴이: yoyowon / 작성시간: 월, 2003/03/31 - 11:20오전
리눅스에서 쓰레드로 서버 프로그래밍을 하고 있는데요....
ps -lef로 스레드의 상태를 확인할수 있자나요.
근데 잘 돌다가....rt_sig란 상태가 나타나면서
sigsuspend로 빠져서 쓰레드가 블럭된 상태로 멈춰 있거던요...
이 방법 저방법 다 생각하는데 원인을 알수가 없군요.
추상적이긴 하지만 비슷한 경험을 한 분의 도움을 원합니다.
물론 mutex 사용했구요....
그러니까...제가 알고 싶은것은 이 경우 쓰레드가 어떤 시그날을 받아서 rt_sig로 빠진건지 알수 있는 방법이 없을까 하는 겁니다.
만약 어떤 종류의 시그날을 받아서 그렇게 된 경우라면, 해당 시그날을 처리해서 원인이 뭔지 밝힐수 있을꺼 같은데.
일일이 모든 시그날에 대한 핸들링을 주어야 알 수 있나요?
아니면,,,, 시그날이 원인이 아닌 다른 어떤 넘이 있는지....정말 궁금하네요.
꽤 오랜 시간을 끌어와서 지칠대로 지쳤지만, 너무 궁금합니다.
비슷한 경험을 하신분 있다면 리플좀 달아주세요.
너무 질문이 추상적이죠? 죄송^^;
하지만 비슷한 아무 얘기라도 좀 부탁드립니다.
모든 가능성을 체크 해 봐야 겠어요...
죽을 맛이네요.....ㅠㅠ
수고하세요.
Forums:
defunct가 뜨나요?
defunct가 뜨나요?
앞마당 먹고 시작한 저그의 8할은 뮤탈 테크를 먼저 탄다. 하지만 나머지 2할때문에 항상 스켄이 모자란다. - _-;
아녀아녀...
defunct 그런거 전혀 안 뜨고요....
근데 가만히 보니...해당 프로그램도 rt_sig 가 뜨는데...
그거 말고도 inetd 에 관한 프로세스들에도 rt_sig가 있네요.
시스템에 문제가 있는건 아니겠져? 정말 답답하네요.....T.T
100 S root 1 0 0 60 0 - 280 do_sel Mar17 ? 00:00:11 init
040 S root 2 1 0 60 0 - 0 bdflus Mar17 ? 00:00:00 [kflushd]
040 S root 3 1 0 60 0 - 0 kupdat Mar17 ? 00:00:07 [kupdate]
040 S root 4 1 0 60 0 - 0 kpiod Mar17 ? 00:00:00 [kpiod]
040 S root 5 1 0 60 0 - 0 kswapd Mar17 ? 00:00:02 [kswapd]
040 S root 6 1 0 40 -20 - 0 md_thr Mar17 ? 00:00:00 [mdrecoveryd]
140 S root 316 1 0 60 0 - 293 do_sel Mar17 ? 00:00:01 syslogd -m 0
140 S root 325 1 0 60 0 - 362 do_sys Mar17 ? 00:00:00 klogd
040 S root 339 1 0 60 0 - 332 nanosl Mar17 ? 00:00:01 crond
140 S root 353 1 0 60 0 - 289 do_sel Mar17 ? 00:00:00 inetd
100 S root 382 1 0 60 0 - 273 read_c Mar17 tty1 00:00:00 [mingetty]
100 S root 383 1 0 60 0 - 273 read_c Mar17 tty2 00:00:00 [mingetty]
100 S root 384 1 0 60 0 - 273 read_c Mar17 tty3 00:00:00 [mingetty]
100 S root 385 1 0 60 0 - 273 read_c Mar17 tty4 00:00:00 [mingetty]
100 S root 386 1 0 60 0 - 273 read_c Mar17 tty5 00:00:00 [mingetty]
100 S root 387 1 0 60 0 - 273 read_c Mar17 tty6 00:00:00 [mingetty]
000 S root 12847 353 0 60 0 - 367 wait_f Mar29 ? 00:00:00 in.identd -e -o
040 S root 12848 12847 0 60 0 - 367 do_pol Mar29 ? 00:00:00 in.identd -e -o
040 S root 12849 12848 0 60 0 - 367 rt_sig Mar29 ? 00:00:00 in.identd -e -o
040 S root 12850 12848 0 60 0 - 367 rt_sig Mar29 ? 00:00:00 in.identd -e -o
040 S root 12851 12848 0 60 0 - 367 rt_sig Mar29 ? 00:00:00 in.identd -e -o
여기 보면 rt_sig 막 있져...제가 짠 프로그램은 없는 상태이고요....이거 보면 프로그램상이 아니라 시스템상에서 문제가 있는게 아닌가여?
어떨때 이런 상황이 벌어지는 거져?
제가 보기엔 ㅡㅡ?
제가 보기엔 dead lock 이 걸린것 같습니다.
뮤텍스 락을 걸고 언락으로 풀어주지 않았던가 아니면 같은 종류의 락을
두번 걸었다던가 할 때 생기는 현상같습니다.
일단 rt_sig는 무시 하셔도 될것 같은데 ㅡㅡ;
찾아 보고 있긴 하지만 저두 초보라 잘 모르겠더라구요...
한번 서버 소스를 천천히 신중히 살펴 보심이 좋으실듯 하네요.
ps로 프로세스를 보시면 계속 running 상태의 프로세스가 있으면 dead lock이라고 볼수 있죠.
그럼 이만...(^^)(__) 답변이 되었는지 ㅡㅡ?
thread hang
위의 문제의 범위가 시그널인지 혹은 mutex 관련된 것인지 명확하지 않네요.
1. 쓰레드 환경에서의 시그널 처리는 매우 신중해야 합니다. 특히나,
리눅스의 경우 아키텍쳐의 한계(linux thread system)로 인해
시그널 처리가 표준과 다릅니다. 따라서, 가장 좋은 방법은
서버 내에서 어떠한 USER 시그날도 발생하지 않도록
sigblock을 시키는 것입니다.
그러나, 시스템 내부에서 사용되는 시그널까지 막으면 문제가 발생하므로
sigaction을 통해 각각 지정하세요. Kill -l으로 하시면 리스트를
볼 수 있습니다.
가능하면 쓰레드 프로그램 내에서는 시그널 핸들러를 사용하지 않기를
권고합니다. 모든 시스템 콜에 대한 예외 처리에 자신이 없다면요...
2. mutex의 경우는 방법이 없습니다
문제가 발생한 시점에 gdb로 attach해서 해당 쓰레드에 대해
where 명령어로 스택을 확인하고, 어떤 경로를 통해
정지되었는지 유추하십시요.
그래도 안된다면, 모든 mutex에 대해 stdout으로 lock, unlock
메시지를 찍어서 잡고 놓아주지 않는 쓰레드를
확인하세요.
더 좋은 방법은 쓰레드 mutex사용에 대한 *명확한*
사용 원칙을 두고 코딩을 하시는 것입니다.
좋은 하루 되십시요.
고도의 추상화, 극도의 구체화, 에디슨을 그리워하다.
답변 감사드립니다.
여러가지 답변 감사 드립니다.
제 생각에도 분명 signal 아니면 mutex 인데....
여러 테스트를 해보고 posix thread 책 뒤적거리고 해봤는데요....
우선 김성진님이 말씀하신데로...
모든 mutex lock과 unlock 부분에 출력을 넣고 돌려보려고 합니다.
시그날 문제는 몇몇 기본적인 시그날이 왔을때....해당 시그날을 출력하고 죽도록 해놨습니다.(죽어야될 시그날만요....)
뭐 하여간....근데 이넘이 웃긴게 대중없이 죽습니다.
공통점을 찾아야 될텐데....하루도 못넘기기도 하고,,,사나흘 잘 돌기도 하고....
하여간 테스트 와 결과 나오면 다시 올리세요....
좋은 하루 되세요...감솨합니다.
댓글 달기