Thread 장단점

2009. 4. 8. 09:03

thread 장점

1. 프로세스의 경우 스택이나 코드, 데이터 영역을 위해 새로운 메모리를 잡음. 그러나 스레드는 같은 주소공간을 사용하기 때문에 메모리 효율성 높음
2. Context switching에 대한 비용이 적음
3. IPC를 사용하지 않음

===================================================================================

1) 운영체제=프로세스의 모임
2) 프로세스= 스케쥴링의 단위, 쓰레드의 모임, 1개 이상의 쓰레드로 구성
3) 쓰레드 = 스케쥴링의 가장 작은 단위(반드시 특정 프로세스에 포함)

* 쓰레드 vs. 프로세스
- 쓰레드는 프로세스의 구성원이다.
- 프로세스는 생성시(fork) 텍스트, 데이터, 스택을 위한 영역이 필요하며,
동일 프로세스(예를 들어, ls를 다수개 실행)인 경우 데이터와 스택만을 새로
생성하고 텍스트는 공유한다.
- 쓰레드는 생성시(posix의 경우: pthread_create) 텍스트, 데이터, 스택이 필요하나,
이중 텍스트와 데이터는 이미 해당 쓰레드를 내포하고 있는 프로세스에 있는 것을 사용하며, 단지,
스택만을 새로 할당받는다. (비용이 프로세스에 비해 조금 작다)
- 프로세스간의 통신은 전형적인 IPC(signal, pipe, fifo, semaphore, shared memory, socket등)에
의하며, 쓰레드는 그외에도 프로세스의 데이터를 마치 공유메모리처럼 사용할 수 있고, 뮤텍스라는
동기화 메카니즘을 지원한다.
- 동일 프로세스내의 쓰레드간에 시그널은 무방하나, 다른 프로세스의 특정쓰레드에게 시그널을 보낼
방법은 기본적으로 제공되지 않는다.

===================================================================================

왜 Thread인가?

Process 모델의 문제인 fork의 비효율성을 극복하기 위해 사용된다. 간단히 예를 들어보겠다. 무식한 Web Server 하나가 있다. 이 녀석은 2개 이상의 클라이언트로부터 요청이 오면 자신을 복제하여 새로운 Process를 생성한다. 그리고 이 녀석이 클라이언트 하나를 처리하도록 만든다. 여기서 Process 복사를 위해 fork system call이 발생하는데 동시에 다수의 클라이언트로부터의 요청을 처리하기 위해서는 그만큼의 fork가 일어나고 이는 시스템이 Process 복사를 하느라 다른 일을 처리하지 못하게 되는 상황이 된다. 매우 비효율적이다. 다른 이유를 찾아보면 멀티프로세싱(multi-processing)을 위해서이다. 하나의 Process는 하나의 프로세서(CPU)에서 동작하게 된다. 시스템이 자동적으로 Process를 병렬화 하는 것은 불가능 하기 때문에 멀티프로세싱이 가능한 시스템에서는 단일 Process로 동작하는 것은 매우 비효율적이다. 이러한 비효율성을 해결하기 위해서 Thread 가 등장한다.

두 모델간의 차이

1. Process 모델은 heavy-weight 모델이라고 표현할 수 있다. Process를 복사할 때 Process가 가지고 있는 모든 자료구조를 다시 생성하고 복사하는 등 이로 인해 발생하는 비용이 크다. 반면 Thread 모델은 light-weight 모델이다. Process의 대부분의 내용을 공유하며 Thread를 위한 자료구조, 지역변수, register 저장을 위한 공간, stack, PC 등만 필요할 뿐이다.

2. 전통적인 Process 자료구조 = Process Context + (data, code, stack), Process Context = Program Context + Kernel Context

3. 현대의 Process 자료구조 = Thread + (code, data) + Kernel context, Thread = Thread context + User stack

4. 각각의 Thread는 자신만의 logical control flow, 즉 PC(Program Counter)를 가진다.

5. 각각의 Thread는 동일한 code, data, Kernel context를 공유한다.

6. 각각의 Thread는 자신의 Thread ID를 가진다.

7. 논리적 구조가 Tree 형태가 아니다. Process로부터 파생이 되기는 하지만 모든 Thread는 동일한 Level의 Child 일 뿐이다. 반면 Process의 복제에서는 Tree처럼 이루어진다.

8. OS가 Swap out을 할 때 Process 단위로 이루어진다. Thread의 경우 Process가 Swap out되면 함께 되는 것이므로 따로 Swap out의 대상이 되지 않는다.

9. 하나의 Thread는 하나의 Process에만 속하게 된다. 그러나 하나의 Process는 여러 개의 Thread를 가질 수 있다.

주소공간의 차이

하나의 Process에 속해있는 Thread들은 같은 주소공간을 공유하기 때문에 정보 공유가 용이하다. 그러나 이로 인한 동기화의 문제가 있다. 이것은 이후에 언급하도록 하겠다.

간단히 정리한 공통점과 차이점

1. 공통점 : Thread와 Process는 스케줄링의 단위가 된다(context switch). 그리고 각각은 logical control flow인 PC를 가지며 동시에 동작한다.

2. 차이점 : Thread는 code, data를 공유하지만 Process는 그렇지 않다. 그리고 생성과 context switching, 종료의 관점에서 Thread가 훨씬 비용이 적게 든다.

Thread의 이점

생성, 종료, context switching 비용이 적어 경제적이다. 리소스 공유를 통한 향상된 통신을 할 수 있다. 즉, Process와는 다르게 Kernel의 간섭 없이 Thread 간의 빠르게 정보교환을 할 수 있다. Process의 경우 IPC따위를 통해야 하기 때문에 복잡하다. 마지막으로 멀티프로세서 환경에서 매우 유용하다. 각각의 Thread는 다른 프로세서에서 병렬적으로 동작할 수 있다.

User Level , Kernel Level Threads

1. User Level Thread

Library의 link를 통해서 Thread를 관리한다. 라이브러리는 Kernel의 축소판이다. Thread를 컨트롤하기 위해 사용한다. Kernel의 도움 없이 동기화, 생성, 스케줄링을 할 수 있다. 즉, Kernel의 리소스를 사용하지 않는다. 그러나 Process와 동일한 주소공간을 사용한다. 그리고 User stack과 register 등의 context를 따로 저장하고 있다. 그러나 하나의 Process가 Thread를 관리하는 구조가 되므로 멀티 프로세서를 지원하지 못하는 문제점과 Thread가 Block될 경우 Process 전체가 Block되는 문제가 있다.

2. Kernel Level Thread : system call을 통해 Thread를 관리한다.

Kernel이 Process와 Thread를 위한 context 정보를 유지하고 있다. Process와는 독립된 스케줄링을 할 수 있으며 Kernel의 표준 동기화 메커니즘을 사용할 수 있다. Thread가 Block되어도 Process가 Block되지 않으며 멀티프로세서를 지원한다. 그러나 User-Level Thread에 비해 느리고 무겁다. Thread 생성, 스케줄링, 동기화 등을 하기 위해 system call이 사용 되기 때문이다. 또한 Thread 정보가 Kernel에 저장되기 때문에 Kernel 리소스의 제약에 의해 Thread수의 제한이 생긴다.

Threading Models

1. Many-to-one : 여러 개의 Thread가 하나의 Kernel Thread로 동작한다. 하나의 Kernel Thread는 Process가 될 수 있다. 즉, User-Level Thread 만으로 구성되는 모델이다. User Level Thread의 장단점을 그대로 가지고 있다.

2. One-to-one : Kernel Level Thread만으로 구성되는 모델이다. Kernel Level Thread의 장단점을 그대로 가지고 있다. (Win 2k, NT, OS/2 등)

3. Many-to-Many : Many-to-one + one-to-one 의 형태이다. 많은 User Level Thread가 하나의 Kernel Level Thread에서 동작한다. 그리고 Process당 여러 개의 Kernel Level Thread가 생성 될 수 있다. Thread 의 생성은 User space에서 완료되며 멀티프로세서를 지원한다. 또한 block system call이 발생해도 전체 Process가 block 되지 않는다. (Solaris HP-UX, IRix 등)

Threading Issues

1. Fork Issue: Thread 내에서 fork가 일어나면 모든 Thread를 복사해야 하는가 아니면 새로운 Process에 해당 Thread만 생성하고 말아야 하는가?

2. Cancellation Issue :할당 받은 메모리가 남아있거나 다른 Thread와 공유중인 데이터가 업데이트 중일 때 말소될 경우 어떻게 처리해야 하는가?

3. Signal handling Issue : signal이 발생했을 때 이를 처리할 Thread는? 즉 signal을 모든 Thread에게 보내주어야 하나 아니면 특정 Thread에만 보내주어야 하나? 참고로 Solaris의 경우 모든 Thread에서 Signal을 처리하도록 하고 있다.

4. Thread polling Issue : Process가 시작하면 가능한 수만큼 Thread를 생성하여 pool에 보관했다가 작업이 필요하면 사용한다.

5. Thread Interface Issue : Vender에 의존적이다. 즉 OS마다 다르다. 그러나 pThreads 같이 POSIX 표준을 지원할 경우 동일한 인터페이스로 Thread를 관리할 수 있다.

OS별 Thread 구조

1. Solaris : Many-to-many model 이다. 여러 개의 LWP(Light Weight Process)에 여러 개의 User Level Thread가 동작한다. LWP는 Kernel Level Thread 이다. User Level Thread는 하나의 LWP에 bound된다. User Level Thread는 Kernel의 간섭 없이 Thread 라이브러리를 통해 스케줄링 된다. 각각의 Process는 최소 하나의 LWP를 가진다. LWP의 자료구조는 Kernel에서 유지하고 있다.

2. Window 2k : one-to-one model 이다.

3. Linux Thread : 멀리스레딩을 지원한다. 그러나 효율적인 Kernel레벨의 멀티스레딩을 지원하지는 않는다. 대신 LWP와 비슷한 형태를 제공한다. 특징이라고 하면 Process와 Thread를 구분하지 않는다는 것이다. Task_struct 하나만을 사용하고 있다. LWP는 clone() system call을 통해 만들어 진다. Fork와 유사하다. Process의 복사본을 만드는 것 대신 parent task의 주소공간을 공유하는 분리된 Process를 생성한다.