1// 제 목: POSIX thread 에 관한 몇가지 참고사항
// 작성자: 김영대( http://www.howto.pe.kr )
1.쓰레드
1) 쓰레드간에 공유하는 자원
.work directory,
.heap
.global/static variable
.UID/GID
.code segment
.file/socket descriptor
.signal
2) 쓰레드 고유 자원
.errno
.쓰레드 우선순위
.stack
.쓰레드 ID
.register (PC, SP, …)
2.프로그래밍 관점에서의 쓰레드 분류
(주의) 많은 문서들에서 커널 쓰레드 를 논할 때 용어에 혼돈이 올 수 있다
전통적인 O/S의 Kernel Thread 는 O/S 영역에 위치하여 Kernel Scheduler에 의해 스케줄링되는
쓰레드를 의미하지만 프로그래밍시의 커널 쓰레드는 LWP 자료구조를 통하여 Kernel Thread 에
bound 되어 사용되는 사용자 프로세스의 쓰레드를 커널 쓰레드라 하고 있다
그래서 이하 O/S의 커널 쓰레드를 'Kernel Thread' 라 하고 프로그래밍시의 커널 쓰레드는 그냥
'커널 쓰레드'라 칭한다
1.사용자 레벨 쓰레드, user-level thread (project Andrew)
.사용자 쓰레드 방식이 커널 쓰레드보다 오버헤드가 적은 이유는 쓰레드간 context switching시
커널 스케줄러를 호출할 필요가 없이 라이브러리에 의해 제공되는 사용자쪽 스케줄러에 의해 처리된다
.사용자 쓰레드의 단점은 프로세스내의 한 쓰레드가 커널로 진입하는 순간 나머지 쓰레드들도 전부
blocking된다. 커널 쓰레드의 경우는 Kernel Thread에 bound 되어 Kernel Scheduler에 의해 스케줄링
되므로 blocking 이 발생하지 않는다. 그러므로 프로그래밍시 read/write 같은 시스템콜이 많은 경우는
커널 쓰레드를 사용하는 것이 유리하다
.또다른 단점은 CPU가 아무리 많더라도 사용자 쓰레드는 커널에의해 인식되지 않는 쓰레드 이므로
사용자 쓰레드가 위치한 프로세스 단위로 스케줄링이 이루어 지므로 한 프로세스내의 모든 사용자
쓰레드는 1개의 CPU 만 할당받게 된다(SMP:Symmetric Multi Processor 사용못함).
.라이브러리에 의한 빠른 context switching (커널자원 사용 최소화)
.system call 호출시 유저 모드에서 커널 모드로 전환시 task 내의 모든 thread 가 block 됨
.unfair scheduling (preemption, non-preemption)
2.커널 레벨 쓰레드, kernel-level thread (Windows NT, MACH, OS/2)
.커널 쓰레드는 Kernel Scheduler에 의해 CPU를 할당받아 사용하므로 프로그램에서 시스템콜을 사용시
blocking 되지 않고 또한 dual/quad 등 복수 CPU 시 모든 CPU를 스케줄링 받아 사용한다(SMP 사용).
.쓰레드간 context switch할 때마다 Kernel Scheduler를 호출해야 하므로 Kernel Scheduler로 진입하려면
프로세서 모드를 사용자 모드에서 커널 모드로 전환해야 하는데, 이때 사용자쪽 하드웨어 레지스터를
전부 저장시키고, 커널 레지스터를 복구하고, 기타 등등...의 overhead 가 일어난다.
.각 thread 별로 schedule 될 수 있음
.문맥전환(context switch) 시 kernel scheduler 로 진입하기위한(user mode -> kernel mode)
overhead 발생 (user-level thread 에 비해 10배)
.각 thread 가 동시에 system call 할 수 있음
3.하이브리드 쓰레드, hybrid thread (Solaris 2)
.3-levels of thread (user-level thread, LWP, kernel-level thead)
.각 task (process)는 최소한 하나의 LWP 에 bound 됨
.kernel은 LWP 단위로 스케줄링하고, LWP는 대기중인 thread를 골라서(bound) 실행
.LWP (Lightweight Process) 는 thread library 에 의해 조작되며
LWP 는 register data, accounting info, memory info 를 포함한 일종의 PCB(Process Control Block)
.LWP의 context switching 비용은 kernel-level threas 보다 결코 싸지 않습니다
.다중 CPU에서 효율적일려면 각 Thread는 각각 다른 LWP에 할당되어야 한다.
.각 Thread의 LWP 할당과 LWP의 CPU 할당은 별개로서 이루어지기 때문에, 각 Thread가 서로다른 CPU에
할당될려면 이렇게 작동하겠끔 하는 매커니즘이 따로 존재하여야 한다.
1).PTHREAD_SCOPE_PROCESS - It is not lightweight
.pthread_attr_setscope() 함수에서 PTHREAD_SCOPE_PROCESS 로 지정
.하나의 LWP를 공유하여(N:1) thread poole을 이루어 라이브러리에 의해 스케줄링 되므로 LWP와 같은 자원을
덜 사용하고 context overhead 가 적다.
.LWP가 Blocking이 되면 이 LWP에 bound 된 쓰레드들도 동시에 Blocking이 된다
2).PTHREAD_SCOPE_SYSTEM - multiplexes threads to kernel ones
.pthread_attr_setscope() 함수에서 PTHREAD_SCOPE_SYSTEM 로 지정
.thread 당 LWP 가 영구적으로 할당되어(1:1) Kernel Thread 에 bound 되어 커널과 연결된다
3.플랫폼별 Pthread 지원 현황
* JAVA의 경우는 JVM 이 native thread 를 사용하므로 플랫폼에 의존적이다
1) Linux
.clone() 시스템 콜을 기반하므로(kernel based의 LWP 방식) PTHREAD_SCOPE_SYSTEM 만 지원한다
.PTHREAD_SCOPE_SYSTEM 만 지원되므로 default 도 PTHREAD_SCOPE_SYSTEM 이다.
.쓰레드 프로그래밍의 디버깅이 불편하다
2) IBM - AIX
. kernel based(PTHREAD_SCOPE_SYSTEM), library based(PTHREAD_SCOPE_PROCESS) 모두 지원한다
. PTHREAD_SCOPE_PROCESS 가 default 이다
3) SUN - Soalris
. kernel based(PTHREAD_SCOPE_SYSTEM), library based(PTHREAD_SCOPE_PROCESS) 모두 지원한다
. PTHREAD_SCOPE_PROCESS 가 default 이다
.쓰레드 프로그래밍의 디버깅이 편하다
4) FreeBSD
. library based(PTHREAD_SCOPE_PROCESS) 만 지원한다
.PTHREAD_SCOPE_PROCESS 만 지원되므로 default 도 PTHREAD_SCOPE_PROCESS 이다.
.쓰레드 프로그래밍의 디버깅이 편하다
|
|
