[Multi-Thread] Kernel thread vs User Thread

오늘 지인으로 아래와 같은 질문을 받았다.

질문 : "본인이 Unix(solaris로 추정)에서 작업한 프로그램을 Linux로 포팅하고 있는데, ps -ef | grep "xxx"로 모니터링을 하면, 유닉스에서는 프로세스가 나왔는데, 리눅스에서는 각 thread가 나온다고 한다. 이거 이상하다?"

답변 : 이런 상황에 대해서 이전에 경험한적이 있어 아래와 같이 정리했다.
아시다 시피, Multi-thread programming을 할때는 각 OS별로 어떠한 형식의 Thread를 지원하는 숙지할 필요가 있다. 내가 기억하기로는, Kernel thread를 지원하는 것은 윈도우, solaris, 그리고 일부 Linux버젼(커널 버젼별로 차이가 있다.)이다. 그럼 좀 더 자세하게 살펴 보자.

1.  Process vs Thread
1.1 Process = code + data + stack + heap segment

1.2 Thread = stack + register , 그리고 나머지 code + data+ heap은 다른 thread와 공유한다. 특히 heap을 다른 thread와 공유하기 때문에, 동기화 이슈가 발생한다.

2. User thread란?
결론부터 말한다면, Kernel Thread보다 빠르다. 왜냐면, context switching(thread switching)이 Kernel level로 내려가지 않고, User mode에서 모두 처리가 된다.(즉 system call이 발생하지 않는다.) 그렇기 때문에 Kernel thread보다 빠르다.

또한, 일반적으로 학교에서 많은 종류의 thread scheduling algorithms(FIFO, FILO, RR etc)을 배웠다. 하지만 이러한 알고리즘은 OS에 종속적이고, 대부분의 OS가 RR을 사용하고 있는것으로 알고 있다. 하지만 때로는 내가 쓰레드 스케줄링 알고리즘을 선택하고 싶을때가 있다. 이것은 User Thread에서 가능하다. 이것이 가능한 이유는 User Thread를 구현하기 위해서는 POSIX와 같은 라이브러리가 필요한데, 이 라이브러를 통해서 이 스케줄링 알고리즘을 선택또는 변경 할수 있기 때문이다. 또한 thread의 생성과 관리가 빠르다.

하지만 문제점이 있다.
첫째: 커널 관점에서는 하나의 프로세스(또는 thread)에서 여러개의 thread가 동작하고 있다. 프로세스에서는 내부적으로 thread가 어떻게 돌아가는지 알수가 없다. 그래서 만약 하나의 thread가 blocking system call을 한 경우, 즉 하나의 thread가 non-blocking IO를 발생시키면, Kernel에서는 어느 thread가 이 call을 했는지 모른다. 이러한 thread sheduling에 대한 부분은 사용되는 라이브러리의 안정성과 성능에 달려 있다. 

둘째: Multi-cpu환경에서는 구조성 병렬성이 떨어진다. 좀더 자세하게 이야기하면, 프로세스는 CPU의 단위이다. OS는 각각의 프로스가 관리하는 thread들에 대한 내용을 모른다. 
 

3. Kernel Thread란?
모든 thread의 생성과 관리(스케줄링)가 OS에서 한다. 당연히 system call로 작업이 되기 대문에 User thread보다 성능이 않좋다(?).

장점: 개발등 관리가 편하다. 모든 것을 OS(윈도우, 솔라리스)에서 관리해주기 때문이다.
단점: 상대적으로 속도가 늦다.