OS/공룡책(OSC)

[OSC7][Thread] Thread Model

Binceline 2014. 7. 17. 17:32

Thread는 다음과 같은 것들로 구성된다.

- Thread ID

- Program Counter

- Registers

- Stack


다음은 Thread의 특성이다.

- 하나의 프로세스가 다수의 스레드를 제어한다면, 프로세스는 동시에 하나 이상의 작업을 처리할 수 있게 된다.

- Thread는 코드, 데이터 섹션, 열린 파일이나 신호같은 운영체제 자원들을 같은 프로세스에 속한 다른 스레드와 공유할 수 있다.


단일 스레드 프로세스와 다중 스레드 프로세스의 각 구조는 다음과 같다.

이미지 출처 : 공룡책


통의 소프트웨어들은 하나의 프로세스에 여러 개의 스레드를 가진 프로세스 하나로 구현된다. 예를 들어서 웹 브라우저는 이미지와 텍스트를 표시하는 하나의 스레드와 네트워크 통신을 하는 스레드를 가진다.

옛날에는, 스레드 사용이 대중화 되기 전에는 하나의 프로세스에 여러 개의 스레드를 생성하는 방식을 쓰지 않고, 여러 개의 프로세스를 사용하는 방식이 보편적이었다. 프로세스 생성 작업은 매우 많은 시간을 소비하고 많은 자원을 필요로 하는 작업이다. 간단하게 생각해 보자. 프로세스는 스레드보다 상위의 개념이다. 그러므로 대부분의 경우 프로세스를 여러 개 사용하는 것 보다는 스레드를 여러 개 두는 것이 더 효율적이다. 보통의 경우엔 

[멀티 프로세스 < 멀티 스레드] 라는 소리다.

보통의 OS는 다중화되어 있는데, 커널 안에서 멀티스레드로 동작하고 Device나 Interrupt 처리 같은 작업을 수행한다.

Linux에서는 시스템의 자유 메모리를 관리하기 위해 커널 스레드를 사용한다.


- Responsiveness(응답성) : 여러 가지의 작업을 의 동시에 수행할 수 있다. 예를 들어 멀티스레드 웹 브라우저는 한 스레드가 이미지 파일을 받아오는 동안 다른 스레드에서 사용자와의 상호 작용이 가능한 것과 같은 것이다.

- Resource sharing(자원 공유) : 스레드는 자동적으로 그들이 속한 프로세스의 자원들과 메모리를 공유한다. 프로세스 내에 존재하는 메모리를 공유하여 이용할 수 있다는 것이다.

- Economy(경제성) : 프로세스 생성을 위한 메모리와 자원을 할당하는 것은 비용이 많이 든다. 하지만 스레드는 자신이 속한 프로세스의 자원을 공유하기 때문에 스레드를 사용하는 것이 더 경제적이다. 이 오버헤드를 경험하는 것은 매우 드물겠지만, 일반적으로 프로세스를 생성하고 관리하는 것이 스레드를 사용하는 것 보다 더 많은 오버헤드가 생긴다. 이것도 OS마다 다른데, Solaris에서는 프로세스를 생성하는 데 걸리는 시간이 스레드보다 30배, Context switching은 5배 정도 오버헤드가 걸린다.

- Utilizatiion of multiprocessor architectures(다중 처리기 구조의 활용) : 멀티스레드의 가장 중요한 장점이 있다. 단일 스레드를 사용하는 프로세스는 CPU 개수에 상관 없이 오로지 1개의 CPU만 사용한다. 하지만 멀티 스레드를 사용하는 프로세스는 CPU 수 만큼 병렬성이 증가한다.


OS의 멀티스레드 모델

사용자 스레드와 커널 스레드로 구성되는데, 사용자 스레드는 커널 스레드에 의해서 관리되고, 커널 스레드는 OS에 의해 관리된다. 기본적으로 다음과 같은 구조를 가진다.

- 다대일 모델

이 모델을 사용한 OS : Solaris, 등

은 user level 스레드를 하나의 kernel 스레드로 관리한다. 

스레드 라이브러리에 의해 관리되기 때문에 효율적일 수 있지만, Blocking System Call을 하게 된다면 전체 프로세스가 Block된다. 하나의 스레드만이 커널에 접근할 수 있기 때문에, 멀티 스레드로 돌려도 병렬로 동작하지 않는다.

Blocking System Call : 예를 들어 어떤 스레드 2개 A, B가 돌고 있는데, A가 시스템 콜을 하게 되어 커널에 접근하면 B는 멈추게 된다. 한 번에 하나의 스레드만이 커널에 접근할 수 있기 때문이다.

- 일대일 모델

이 모델을 사용한 OS : Windows, Linux, 등

각의 user level 스레드를 각각 하나의 kernel 스레드로 관리한다. user level, kernel level의 스레드가 하나씩 있는 것이 아니라, user level 스레드 하나 당 kernel level 스레드 하나로 관리하는 것이다. 

한 스레드가 Block되는 일이 생겨도 다른 스레드들은 영향받지 않고, 보통 멀티 스레드로 구현하기 때문에 그런 것인데 병렬성이 높다. 단점은 user level 스레드를 생성할 때 그에 따른 kernel 스레드를 생성해야 한다는 점이다. kernel 스레드를 생성하는 오버헤드가 성능을 저하시킬 수 있다. 그래서 보통 이 모델을 채용한 OS는 지원되는 스레드 수를 제한한다.

- 다대다 모델

여러 개의 user level 스레드를 그보다 적거나 같은 수의 kernel 스레드로 다중화시켜 관리한다. 다대일 모델은 개발자가 원하는 만큼의 user level 스레드를 생성하도록 허용하지만, 

다대일 모델은 한 번에 하나의 스레드만이 커널에 의해서 스케줄링되기 때문에 진정한 동시성을 획득할 수는 없다. 

일대일 모델은 병렬성이 높지만 너무 많은 스레드를 생성하지 않도록 주의해야 한다.

다대다 모델은 이런 두 단점들을 어느 정도는 해결할 수 있는 방법이다. 개발자는 필요한 만큼 user level 스레드를 생성할 수 있고, 대응되는 kernel 스레드가 멀티스레드로 병렬 수행될 수 있다. 어떤 스레드가 Blocking System Call을 한다고 해도 kernel이 다른 스레드의 수행을 스케줄링 할 수 있다.

다대다 모델의 변형이 있는데, Two-Level Model이라고 불리며 기존 다대다 모델의 형식을 유지하지만, 하나의 user level 스레드가 대응되는 하나의 kernel 스레드에 종속되는 것을 허용한다. IRIX, HP_UX, Tru64 UNIX, Solaris 9 이전 버젼, 등에서 이 모델을 지원하였다.

다대다 모델

Two-Level Model

반응형