운영 체제 (Operating System) - Thread

1. Thread의 정의

이전 강의에서 보았듯이, Process는 Scheduling 단위인 Execution unit과 자원의 보호인 Protection domain의 추상화로, Program을 실행한 개념이다. 그런데 프로세스에 실행 흐름이 다수 개라면 이 개념만으로 표현할 수 있을까? 그래서 하나의 실행 흐름(실행 혹은 스케줄링 단위, Execution unit)인 Thread를 도입하였다.  Thread는 프로세스 내의 실행 흐름으로 프로세스보다 작으며 동일 프로세스 내의 Thread간에는 Protection domain이 존재하지 않는다(Data, Code, Heap영역을 공유한다). Thread를 여러 개로 표현하여 다수의 실행 흐름을 구현하면 병렬적으로 태스크를 실행할 수 있기 때문에 병렬적으로 작업을 완수할 수 있다는 특징이 있다.

Thread는 Cooperative process와는 분명히 구분되는데, IPC를 통해 Process간에 통신을 하는 Cooperative process는 IPC의 비용과 Process간의 Context switching로 인한 비용으로 인해 비교적 전체 비용이 높다. 이후 자세히 다루겠지만, 한 프로세스 내의 Thread는 메모리를 공유하므로 Process context switching보다 비용이 낮다. 그러므로 Cooperative process 대신 Process 내에서 Cooperative thrad를 만든다면, 보다 적은 비용으로 동일한 업무를 수행할 수 있게 된다.

그렇다면 모든 프레세스를 많은 Thread로 만들면 절대적으로 성능이 향상될까? 그렇지만은 않다. 초기에는 Thread의 수가 증가할 수록 CPU의 Utilization이 증가하긴 하지만, Thread switching의 비용으로 인해 Thread의 갯수가 임계값을 넘어간다면 다시 줄어든다. 이 임계값은 CPU의 수가 많을 시스템일 수록 크기 때문에, 결론적으로 cpu의 수가 많을 수록 한 Process에서 여러 Thread를 병렬적으로 실행하는 것이 유리하다. 다음은 CPU의 수와 Thread 수와 Throughput의 상관관계이다.

 

 

2. Multi-Threaded Program

Multi-threade program은 단순히 다수의 Thread를 이용한 프로그램이다. 다시 개념을 명확하게 하기 위해 Process와 Thread의 특징을 비교해보자. Process는 하나의 Thread와 같은 실행 흐름을 가지며, Process 간의 Memory는 독립적이므로, 서로의 영역에 접근하기 어렵다. 또한 Process간의 switch비용이 크다 Thread는 하나의 Process 안에 여러개의 Thread가 존재하며 Process의 Code영역과 Data영역을 Thread간에 공유한다.(사실상 하나의 VM을 공유한다.) 또한 Thread는 같은 Memory영역을 사용하므로, Thread간 swtich비용이 적다

 

이처럼 Multi-thread program은 Responsiveness(하나의 Thread가 block되더라도 다른 Thread가 실행되므로 Interactive해 보임), Resource sharing(Thread간의 Memory 공유), Economy(VM을 새로 생성하지 않는다 -> Thread 생성 비용이 적다), Scalability(여러개의 Thread가 서로 다른 프로세서에서 동시에 실행이 가능하다)의 장점을 갖는다.

 

 

3. Multicore Programming

최근 프로세서는 여러개의 Computation core를 갖는다. 이를 Multicore processor라고 하는데, 이 시스템에서는 운영체제에서 각각의 Core를 하나의 Processor로 인식하고 scheduling한다. 그리고 앞서 Multi-thread program의 장점 중 Scalability에서 언급한것과 같이 시스템은 각각의 Thread를 여러 Core에 할당하여 실행 가능하다.

이때 프로세서 내의 (동일한 프로세스의 Thread가 돌아가는)Core 간에는 Cache를 공유하기 때문에 Data, Code 등 Process의 자원을 공유하는 Multi threaded programming보다 효율적이다.

 

 

4. User and Kernel thread

Thread는 지원하는 주체에 따라서 User thread와 Kernel thread로 나뉜다.

 

4-1. User thread

Kernel 영역 위에서 지원되며, 일반적으로 User level의 Library를 통해 구현된다(Library에서 Thread를 생성하고 스케줄링 관리를 해줌! 단, 실제로 그걸 수행하는 것은 결국 OS이다).

동일한 Memory영역에서 Thread가 생성 및 관리 되므로 속도가 빠르다는 장점이 있지만, 여러개의 User thread 중 하나의 Thread가 system call 요청으로 block된다면 나머지 모든 Thread역시 block된다는 단점이 있다. (Kernel에서 여러 User thread를 하나의 Process로 간주하기 때문에!)

 

4-2. Kernel thread

운영체제에서 지원하며, Kernel영역에서 Thread를 생성하고 스케줄링 등을 관리한다.

Thread가 system call을 호출하여 block이 되면 Kernel은 다른 Thread를 실행함으로써 전체적인 Thread blocking이 없고, Multiprocess환경에서 Kernel이 여러개의 Thread를 다른 Processor에 할당할 수 있다는 장점이 있지만, User thread에 비해 생성 및 관리가 느리다는 단점이 있다.

 

이 User thread와 Kernel thread의 block여부는 User program과 Kernel program에서의 block을 생각해보면 쉽다. 예를 들어, 하나의 User program에서 context switching(system call)으로 인한 interrupt로 block된다면, 모든 thread가 멈춘다. 하지만, Kernel에서 user process의 system call로 block되더라도, 멈추지 않고 다른 Kernel thread가 또 다른 User process의 system call을 처리할 것이다. 이 과정에서 몇개의 User thread가 몇개의 Kernel thread 와 연결 되어야 하는지 명시해줄 필요가 생겼다.

 

5. Mapping of User & Kernel thread

5-1. Many to One

Kernel thread를 지원하지 못하는 시스템에서 사용되는 방식으로, 여러개의 User thread가 하나의 Kernel thread로 매핑되는 방식이다. Kernel thread가 하나이므로 한번에 하나의 User thread만이 kernel에 접근 가능하여, 여러 개의 thread가 동시에 kernel에 접근 및 system call 사용을 할 수 없다는 한계가 있다. 이는 Multiprocessor이더라도 여러 개의 Thread는 하나의 Proess이기 때문에 여러 개의 Processor에서 동시에 수행이 불가능하다

 

5-2. One-to-One

1대 1로 매핑된 방식, 동시에 호출 할 수 없다는 점과 Multiprocessor에서 동시 수행이 불가능하다는 5-1의 문제점이 개선되었으나, Kernel thread도 한정 자원이므로 무한정 생성할 수 없어 User thread도 한정되어 그 갯수에 대한 제한이 생긴다.

 

5-3. Many-to-Many

many to many로 매핑된 관계. Kernel thread는 생성된 User thread와 같거나 적은 수 만큼 생성되어 적절이 스케줄링 된다. 이 방식은 One to One처럼 사용 thread의 수를 고려할 필요도, user thread가 Block될 걱정도 없다. 

 

6. Thread issue

thread라는 새로운 execution unit이 등장하면서 고려해야 할 요소들이 증가하게 되었다. 예를 들어 Mutli-threaded programming을 위해 Thread scheduling과 Thread간의 통신과 Thread가 사용할 메모리 공간의 할당에 대한 고려가 필요해졌다. 즉, 논리적 실행 흐름의 실행과 종료의 복잡도가 증가하였다. 어떠한 issue들이 있고 어떻게 현재 시스템에서 해결하는지 알아보자.

 

6-1. Thread creation

fork할 때 fork를 호출하는 thread만 복사할 것인지, 모든 thread를 복사할 것인지에 대한 문제 

 

6-2. Thread cancellation

중지할 때 다른 thread의 모든 작업을 중지 할 것인가? / 자신(thread)에게 할당된 자원을 해제해야하는가?(자신이 file open한걸 다른 thread에서 쓴다면?)

 

6-3. Thread pools

Thread가 자주 생성, 제거 되는 환경에서 Thread를 만드는 시간이 너무 오래걸릴 수 있음 + 최대한의 Thread수의 제한이 필요함

    -> Thread pool을 만들어 Process가 새로 실행 될 때 정해진 수만큼 thread를 만든 후 Pool에 할당한다.(이 수는 시스템의 메모리나 작업 수에 따라 휴리스틱 하게 결정) 그리고 새로운 Thread가 필요하다면 Pool에서 가져오고 작업이 끝나면 Thread 제거 대신 Pool에 넣어 보관한다. 

 

6-4. Thread간 IPC

Multithreaded Programming에서는 Thread 간 통신이 필요 -> 공유 메모리 활용

 

6-5. Thread creation