[쓰레드] 2. 쓰레드의 유형 /사용자 수준 쓰레드와 커널 수준 쓰레드
사용자 수준 쓰레드(ULT: User-level thread)
- 순수한 ULT 구현에서, 쓰레드 관리와 관계된 모든 일은 응용이 수행하며 커널은 쓰레드의 존재를 알지 못한다.
- 쓰레드 라이브러리를 이용하여 모든 응용을 멀티쓰레드 기반으로 프로그래밍 가능
- 쓰레드 라이브러리는 쓰레드의 생성과 제거, 쓰레드 간의 메시지와 데이터 전달, 쓰레드 수행의 스케쥴링, 쓰레드 문맥의 저장과 복구 코드 포함.
- 응용은 시작하자마자 하나의 쓰레드를 가지며, 그 쓰레드에서 수행을 시작.
- 응용과 쓰레드는 커널에 의해서 하나의 프로세스에 할당된다.
KLT 대신 ULT를 사용할 경우 장점
1. 쓰레드 교환에 커널 모드의 권한이 요구되지 않는다. 따라서 두 모드 사이의 전환 오버헤드를 절감시켜 준다.
2. 스케쥴링이 응용에 맞게 구성될 수 있다.
3. ULT는 어떤 운영체제에서도 적용이 가능하다.
KLT 대신 ULT를 사용할 경우 단점
1. 일반 운영체제에서 대부분의 시스템 호출은 해당 쓰레드를 블록시킨다. 결과적으로 같은 프로세스 내에 모든 쓰레드가 블록
2. 순수한 ULT 기반의 멀티쓰레드 응용은 멀티프로세싱의 장점을 살릴 수 없다.
=> 해결 방안1 : 응용을 멀티 쓰레드 대신 멀티프로세스로 작성 -> 이 경우 쓰레드 교환 대신 프로세스 교환을 함으로써 오버헤드가 증가됨.
=> 해결 방안2 : (자켓팅) 블록형 시스템 호출을 비블록형 시스템 호출로 변환
커널 수준 쓰레드
- 순수한 KLT 구현에서는 쓰레드 관리와 관련된 모든 작업이 커널에 의해 이루어진다.
- 응용 영역에는 쓰레드 관리를 위한 코드가 없고, 단순히 커널 쓰레드 기능에 대한 API가 있다. (Windows)
- 커널은 전체 프로세스에 대해 문맥 정보 및 각 프로세스 내 쓰레드에 대한 문맥 정보를 유지한다.
ULT 대신 KLT를 사용할 경우 장점
1. 커널은 여러 처리기에게 같은 프로세스 내의 여러 쓰레드를 동시에 스케쥴 가능
2. 한 프로세스의 쓰레드가 블록되면 커널은 같은 프로세스에서 다른 쓰레드를 스케쥴 가능.
=> 커널 루틴 자체가 멀티쓰레드로 구성될 수 있다는 것!
ULT 대신 KLT를 사용할 경우 단점
1. 같은 프로세스 내의 한 쓰레드에서 다른 쓰레드로 제어를 넘길 때, 커널 모드 전환이 필요.> 오버헤드 발생
결합된 접근 방법
ULT와 KLT가 결합된 형태
쓰레드는 완전히 사용자 공간에서, 쓰레드에 대한 스케줄링 및 동기화도 대부분 사용자 공간에서 이루어짐.
- 한 응용의 쓰레드들이 다수의 처리기에서 병렬로 수행
- 블록형 시스템 호출이 전체 프로세스를 블록 시키지 않음.
=> ULT와 KLT의 장점을 모두 살림