상세 컨텐츠

본문 제목

[운영체제] 8. 스레드

CS구멍/운영체제🐣

by :Eundms 2021. 3. 23. 21:26

본문

Process - Abstraction for
* Execution Unit : Scheduling 단위
* Protection Domain : 소유하고 있는 자원에 대한 보호
⇒ 지금까지의 Process 개념 = 하나의 실행 흐름을 갖고 실행 중인 프로그램

Process vs Threads

Process Thread
하나의 Thread와 같은 실행 흐름.
Process간의 Memory는 독립적, 서로의 영역에 접근하기 어려움. (IPC없으면 접근 불가)
Process간의 Switch비용이 큼.
하나의 Process안에 여러개의 Thread
Process의 Code 영역과 Data 영역은 Thread간에 공유.
Thread들은 같은 Memory 영역을 사용하므로, Thread간 Switch비용이 적음.

Thread

- Execution Unit

- Process 내의 실행 흐름

- Process보다 작은 단위

(Process에서 할 작업을 여러 개로 나눈 후에 각각을 Thread화 해서 병렬적으로 작업을 완수한다.)

 

Cooperative Process와의 차이점

- Cooperative Process는 IPC가 필요하다.

- Context Switching 비용이 든다.

- Thread를 이용할 경우, Process보다 적은 비용으로 Cooperative Process가 하는 일을 동일하게 수행할 수 있다.

 

Thread수와 Throughput

Thread 수가 많을 수록 CPU Utilization이 증가하다가 임곗값을 넘어가면 다시 감소한다.이유, Thread Switching 비용이 증가하기에.CPU의 수가 많은 System일 수록 Thread를 이용하는 것이 유리하다.Multi-processor : CPU의 수가 많을 수록 한 Process에서 여러 Thread를 Parallel하게 실행하는 것이 유리.

 

Thread구조

Code, Data, File은 같은 Process 내의 다른 Thread와 공유한다.

Thread ID, PC, Register Set, Stack

 

Multi-Thread Program의 장점

1. Responsiveness

: 오래 걸리는 Thread가 있더라도 다른 Thread들은 실행되고 있기에 User 입장에서는 그 Program이 Interactive하다

2. Resource Sharing

: Process내 Thread끼리는 Code,Data,File 영역을 공유함.

3. Economy

4. Scalability

: 여러 개의 Thread가 각각 다른 Processor에서 동시에 실행가능.

 

Multicore Programming

여러개의 Core. 각각의 Core를 하나의 Processor로 인식하고 Scheduling하여 각각의 Core에 여러 Thread가 할당되어 수행 가능.

Multiple Processor가 달린 Multicore는 Cache를 공유함.

 

User Threads vs Kernel Threads

- User Threads

Kernel 영역 위에서 지원되며, 일반적으로 User level의 library를 통해 구현된다. library에서 thread를 생성, scheduling과 관련된 관리를 해준다. 동일한 메모리 영역에서 thread가 생성, 관리되기때문에 속도가 빠르지만, 여러 개의 User Thread 중 하나의 Thread가 System Call 요청으로 Block이 된다면, 나머지 모든 Thread 역시 Block 된다. Kernel은 여러 User Thread들을 하나의 Process로 간주하기 떄문.

 

- Kernel Thread

운영체제에서 thread를 지원.
thread가 system call을 호출하여 block이 되면, kernel은 다른 thread를 실행함으로써 전체적인 Thread Blocking이 없음.
Multiprocessor 환경에서 kernel이 여러 개의 Thread를 다른 Processor에 할당할 수 있음.
User Thread보다 생성 및 관리가 느림

 


User Threads를 Kernel Threads로 매핑시키는 방법

Many-to-One
여러개의 user level thread 들이 하나의 kernel thread로 mapping됨.
한번에 하나의 Thread 만 kernel에 접근 가능
kernel 입장에서 여러 개의 thread는 하나의 process 이기 때문에 Multiporcessor더라도 여러 개의 Processor에서 동시에 수행 불가능.
One-to-One
무한정으로 kernel thread를 생성할 수 없음.

Many-to-Many
kernel은 적절히 user thread와 kernel thread 사이의 mapping을 조절하여, 위와 같은 장점을 보장할 수 있음

 


Thread로 인한 운영체제의 변화

Process 기반의 운영체제 system call

⇒ thread의 개념에 대한 고려 필요

1. Multi-threaded Programming에 대한 지원

- fork(), exec() : thread 지원을 위해서는 변화가 필요

ex)
모든 Thread를 가지고 있는 Process를 만들 것인지

fork를 요청한 thread만을 복사한 Process를 만들 것인지

fork를 하고 exec를 수행할 경우 fork를 요청한 thread만이 복사되는 것이 더 바람직함.

아닌 경우, 모든 thread의 복사가 필요

fork
하나의 Program 내의 Thread가 fork를 호출하면,
exec


2. thread 종료 문제: Multi-thread일 경우, 함께 일하는 thread의 종료는 process보다 복잡해짐

thread 작업이 끝나기 전에 외부에서 작업을 중지시키는 것
하나의 thread에서 중지 명령이 결국은 다른 thread의 모든 작업을 중지시켜야 하는 경우
자원이 thread에게 할당된 경우 Cancellation의 문제


3. Thread Pools

새로이 Thread를 만드는 시간이 실제 Thread가 동작하는 시간보다 긴 경우가 있음
Thread Pool을 만들어 Process가 새로이 실행할 때, 정해진 수 만큼의 Thread를 만든 후, Pool에 할당
새로운 thread가 필요하면 pool에서 가져오고, 작업이 끝나면 그 thread를 pool에 넣음

4. Thread간 IPC

Multithreaded Programming에서는 Thread간 통신이 필요한데

Thread간 IPC 구현은 어떻게 할 것인가?

=> 공유 Memory가 효율적이다.

(이미 같은 Process의 Data 영역을 공유하므로 자연스럽게 공유 Memory가능)

결국 IPC가 최소화 됨. (Thread들 간의 자원 공유로 인하여 가능해짐)

다른 Process에 존재하는 다른 Thread와의 통신은?

- Process의 경우와 비슷한 성능을 보임.

- 이런 통신이 빈번하다면, Program 설계의 잘못.

'CS구멍 > 운영체제🐣' 카테고리의 다른 글

[운영체제] 2. Process  (0) 2021.03.17

관련글 더보기

댓글 영역