User Level Thread vs Kernal Level Thread
-
User-Level threads는 응용 프로그램과 Link/Load가 되는 라이브러리로 구현되어집니다. 이 라이브러리에 동기화, 스케줄링 기능을 모두 담고 있습니다.
-
커널에서는 아무런 지원을 해주지 않으며, 커널이 보기에는 단지 그냥 Single process일 뿐입니다. (운영체제에서 제공하는 thread동기화를 사용하지 않고 싱글 프로세스내에서 응용프로그램과 라이브러리를 통해 동기화를 구현하기 때문이다.)
-
프로세스마다 런타임 라이브러리의 Copy가 호출되므로 스케줄링 정책을 프로세스마다 달리 취할 수 있다.
-
각 Thread마다 time quantum을 소모할 필요 없고, 런타임 라이브러리가 context를 유지하기때문에 switching(커널모드와 사용자모드의 전환)을 할 필요가 없습니다. 그래서 User-Level Threads는 빠르고, 매우 효율적입니다.
-
(응용프로그램에서 제공하는 thread간 전환이 이루어질때 커널 스케줄러를 호출할 필요가 없기때문에 커널모드와 사용자모드의 전환이 발생하지 않는다. 참고로 사용자 모드와 커널모드의 변환은 많은 비용을 발생시킨다.)
-
Blocking System Calls Blocking function이란 처리가 완료되지않으면 return되지 않는 함수인데, 만약 특정 Thread(응용프로그램과 라이브러리가 제공하는 thread) 에서 Blocking이 되어 버리면, 전체 process가 Blocking이 되어버립니다. 이런 이유로 운영체제가 제공하는 non-blocking 함수들만 사용해야 하며, 사용 빈도가 높은 함수(read,select,wait,...)들은 해당 함수의 non-blocking 버젼으로 대체해야할 필요가 있습니다.
-
Shared System Resources 동기화나 Locking없이 Thread끼리 공유하는 변수(드러나지 않고 감춰져 있는 경우)가 있을때, 그 Thread가 thread-safe하지 않으면 Overwrite되는 문제가 생길 수 있습니다. 이 이유로 사용할 함수는 재진입이 가능해야합니다. User-Level뿐만아니라 Kernel-Level 함수까지 모두.
-
signal Handling, Thread Scheduling User-Level에서 이것을 구현하기란 상당히 어렵습니다. Timeslice를 다루기 위해 Hardware Clock 인터럽트를 보통의 방법으로는 받지 못합니다. 선점형(Preemptive) 스케줄링을 하기 위해서는 커널로 부터 Time Siganl을 받는 함수를 등록해두어야 하며, Timer Alarm Siganl을 다루는것은 다른 시그널을 다루는 것보다 아주 어렵습니다.
-
프로세스내의 한 쓰레드가 커널로 진입하는 순간 나머지 쓰레드들이 모두 정지된다. 커널이 쓰레드의 존재를 알지 못하기 때문이다.
-
CPU가 아무리 많더라고 커널 모드에서 쓰레드 단위로 스케줄이 안되므로 각 CPU에 효율적으로 쓰레드를 배당할 수 없는 문제가 있다. (커널쓰레드는 프로세스 단위로만 배당이 되기 때문이다.)
- 쓰레드를 kernal에서 관리한다.
-
kernel-level에 있는 Threads는 독립적으로 스케줄되므로 특정 Thread에서의 Blocking이 process로 전파되지 않는다. 그래서 Blocking System Calls 이용할 수 있습니다. 또한 각 Threads끼리 Signal을 주고 받을 수 있습니다.
-
가장큰 장점은 멀티프로세서의 장점을 활용할 수 있다는 것이다.
- Kernel-level threads는 안정성에 비해서 너무 느리다는게 큰 단점이다. 바로 Thread Context-Switch 때문이다. 10배정도 느리다