Software, Support, Documentation
|
|
News,
Internal,
Projects,
Home Software, Support, Documentation |
"Kang, KiHyun" wrote: > 2. 커널 pthread 구현 문제 > 리눅스 커널은 리눅스의 clone() 시스템 콜에 기반한다. (LWP 방식이다.) 그건 사실상 프로텍션만 뺀 process지 LWP라긴 힘들 것 같습니다. > 덕분에 쓰레드 생성 갯수는 프로세스 max 값에 제한받고, > 로직이 쓰레드를 조금 많이 생성한다면.. ps 때렸을 경우 끔찍한 꼴을 보게 될 것이다. > LWP 방식의 또다른 문제점은? pid 기반으로 동작하는 시그널이 이상작동 할 여지가 있다는 점이다. 확인해보지 않았지만 개념만으로도 찜찜한건 사실이다. linux thread는 signal routing이 pthread 표준과 다르게 동작합니다. process만 갖고 thread를 에뮬레이팅 하고 있기 때문에 어쩔 수 없는 설계 상의 한계라고 할 수 있지요. 그러나 아이러니컬하게도 FreeBSD에도 이러한 process를 갖고 thread를 에뮬 레이팅할 수 있게 되어 있습니다. linux emulation을 통해서. 쓰레드를 수백개 이상 만드는 것은 보통 잘 권하지 않는 프로그래밍 습관 입니다. 특히 preemptive scheduler를 쓸 경우에는 스케쥴링 오버헤드가 무지막지합니다. (개인적으로 프로그램의 목적과 설계를 적절히 한다면 non preemptive sche duler를 쓰는 library thread가 효율적인 경우가 많다고 생각합니다.) > 그리고, Linux pthread 구현에서는, mutex handle 을 선언과 동시에 초기화 해 줘야만 한다. > 많은 라이브러리들을 써 보았지만 핸들은 선언과 동시에 초기화해주지 않으면 컴파일 에러가 나는 라이브러리는 처음이었다. 보통은 정적 초기화를 해서 사용하기 떄문에 별 관계없지 않나요. 실제로 mutex를 써보면 초기화를 안할 이유가 별로 없는데요. linux thread는 kernel based고 freebsd uthread는 library based니 간단히 비교하기는 어려운 문제이지만, 현 시점에서 한가지 확실한 것은 linux thread로 본격적인 프로그래밍을 한다는 것은 불가능하다는 겁니다. pthread를 사용한 프로그래밍은 일반 프로그래밍에 비해 몇 배는 복잡도가 올라가며 디버깅하기도 어려워집니다. 그런데 linux thread에서 만들어내는 core는 디버깅에 아무 쓸모가 없기 때 문에 테스트 코드 수준을 넘어선 규모의 프로그램을 작성하다가 버그가 발생 하면 환장하는 사태가 발생합니다. 작년에 누가 짜놓은 pthread를 사용해 linux에서 구현한 코드를 인수 받았다 가 몇 달 동안 죽도록 고생한 후, FreeBSD로 옮겨와서 버그도 잡고 마음의 평 안도 회복한 경험이 있거든요. :-( FreeBSD의 uthread는 pthread를 사용해 프로그래밍 하는데 무리 없는 구현 이며, 안정적이고, 디버깅이 가능하다는 점에서 최소한의 프로그래밍 환경 이라고 할 수 있습니다. (FreeBSD의 gdb는 최소한의 uthread지원을 합니다만, 솔라리스의 포르테 디 버거만큼 기능이 좋진 않습니다. 그래도 이정도면 해먹을만 합니다...) 개인적으로 잘 만들어진 쓰레드 구현은 pthread_attr_setscope()를 통해서 PTHREAD_SCOPE_SYSTEM과 PTHREAD_SCOPE_PROCESS를 선택적으로 사용할 수 있 는 것이 기본이라고 생각합니다. 그리고 interprocess mutex같은 것도 되면 좋겠지요. -- To Unsubscribe: send mail to majordomo@kr.FreeBSD.org with "unsubscribe chat" in the BODY of the message
|
Copyright © 1998-2005 Korea FreeBSD Users Group. All rights reserved. webmaster at kr.FreeBSD.org $Date: 2002/03/26 13:18:59 $ |
|