[OS] Ep.8 Thread

Review of Process

Process - Abstraction for

• Execution Unit - Scheduling 단위
• Protection Domain - 소유하고 있는 자원에 대한 보호

Program과 Process 관계

• Executing program with a single thread of control
  지금까지의 Process 개념 = 하나의 실행 흐름을 갖고 실행 중인 Program

1개의 실행 흐름을 여러개로 만든다면??

Thread란 무엇인가?

정의

• Execution Unit
• Process 내의 실행 흐름
• Process 보다 작은 단위 (Finer Grain)
• Process가 제공한 Protection Domain은 없음
  (하나의 Process내의 Thread간 에는...)

동기

• 하나의 Process에는 하나의 Control만이 존재하기 때문에, 한 번에 하나의 일 만을 처리
• Process에서 할 작업을 여러 개로 나눈 후에 각각을 Thread화 한다면, 병렬적으로 작업을 완수 할 수 있음.
• Cooperative Process와의 차이점
  - Cooperative Process는 IPC가 필요 - 비용이 많이 듦
  • Process 사이의 Context Swithching 비용
  • Process 내에서 Cooperation하는 Thread를 만든다면
    Process보다 적은 비용으로 Cooperative Process가 하는 일을 동일하게 수행 가능

Process를 생성하는 것 보다, Thread를 생성하는 것이 더 적은 비용..(IPC, Context Switching)

Theread와 CPU Utilization

• Thread의 수가 증가할수록 CPU의 Utilization이 증가
  임계값을 넘어가면 다시 감소 -> Thread Switching 비용이 증가함.

• CPU가 많은 System일 수록 Thread를 이용하는 것이 유리
  Multi-processor, 즉 CPU의 수가 많을 수록 한 Process에서 여러 Thread를 Parallel하게 실행하는 것이 유리.

Process와 Threads

Process

• Single Thread process와 동일

• Process 간의 Memory는 독립적이므로, 서로의 영역에 접근하기 어려움
  IPC나 Shared Memory를 사용한다.

• Process간의 Switching 비용이 큼 (상대적으로 Heavy Weight)

Threads

• 하나의 Process 안에 여러개의 Thread가 존재
  (Multi Thread process와 동일)

• Process의 Code 영역과 Data 영역은 Thread간에 공유

• Thread들은 같은 Memory 영역을 사용하므로, Thread간 Switching 비용이 적음

Thread의 구성 요소

Thread는 Process내의 하나의 실행 흐름이므로, 실행과 관련된 자료 구조가 필요

• Thread ID : Thread 식별자

• Program Counter : 현재 실행중인 Instruction 주소

• Register Set : CPU의 Register 값들

• Stack : Process보다 Thread의 고유 정보 수가 적기 때문에 Thread Switching 비용이 적음

동일한 Process 내에 있는 다른 Thread와 공유하는 것

• Code : Program의 Code Section
• Data : Process의 Data Section
• File : Process에서 Open한 File

각 Thread 간에는 code, data, files 부분은 공유하고,
각 Thread는 registers와 stack을 가지고 있음을 알 수 있다.

Process vs. Thread

Multi-Process 환경에 비해서, Multi-Thread가 메모리 관점에서 더 이득임을 알 수 있다.

Multi-Threaded Program의 장점

Responsiveness

• Program의 어느 부분을 담당하는 Thread가 Block되거나 시간이 걸리는 작업을 하더라도, 다른 Thread들은 실행되고 있기 때문에 User의 입장에서는 그 Program이 Interactive하다고 볼 수 있음

Resource Sharing

• Thread들 간에는 Process의 Memory와 다른 자원들을 공유

Economy

• Thread들은 하나의 Process Memory 영역에서 실행하기 때문에 새로운 Process를 생성하는 것보다 Thread를 생성하는 것이 비용이 적게 들어감

Scalability

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

Multicore Programming

최근 Processor 설계 동향은 하나의 Chip에 여러 개의 Computing Core를 탑재 -> Multicore Processor

Multithread Programming은 Multicore 시스템에서도 효율적임

• Multicore Processor는 운영체제에서 **각각의 Core를 하나의 Processor로 인식하고 Scheduling
• 각각의 Core에 Thread를 할당하여 실행 가능
• Multiple Processor가 달린 Multicore는 Cache를 공유하기 때문에 Data, Code, 등 Process의 자원을 공유하는 Multithreaded Programming에 보다 효율적임

User and Kernel Threads

Thread를 지원하는 주체에 따라 나뉨(User vs Kernel)

User Threads

• Kernel 영역 위에서 지원되며, 일반적으로 User Level의 Library를 통해 구현됨

• Library에서 Thread를 생성, Scheduling과 관련된 관리를 해줌

• 장점
  동일한 Memory영역에서 Thread가 생성, 관리되므로 이에 대한 속도가 빠르다.

• 단점
  여러 개의 User Thread 중 하나의 Thread가 System Call 요청으로 Block이 된다면, 나머지 모든 Thread 역시 Block 된다.

-> Kernel은 여러 User Thread들을 하나의 Process로 간주하기 때문

Kernel Thread

• 운영체제에서 Thread를 지원

• Kernel 영역에서 Thread의 생성, Scheduling 등을 관리

• 장점
  Thread가 System Call을 호출하여 Block이 되면, Kernel은 다른 Thread를 실행함으로써 전체적인 Thread Blocking이 없음
  Multiprocessor 환경에서 Kernel이 여러 개의 Thread를 다른 Processor에 할당할 수 있음

• 단점
  User Thread보다 생성 및 관리가 느림

Mapping of User & Kernel Thread

Many-to-One

• Thread 관리는 User Level에서 이루어짐(=User-level Threading)

• 여러 개의 User Level Thread들이 하나의 Kernel Thread로 Mapping됨

• Kernel Thread를 지원하지 못하는 System에서 사용됨

• 한계점
  한번에 하나의 Thread만 Kernel에 접근 가능
  - 하나의 Thread가 Kernel에 접근 (System Call)하면, 나머지 Thread들은 대기해야 함
  - 진정한 Concurrency는 지원하지 못함
  - 동시에 여러 개의 Thread가 System Call 사용 불가
  

Kernel의 입장에서 여러 개의 Thread는 하나의 Process이기 때문에 Multiprocessor더라도 여러 개의 Processor에서 동시에 수행 불가능

One-to-One

• 각각의 User Thread를 kernel Thread로 Mapping

• User Thread가 생성되면, 그에 따른 Kernel Thread가 생성

• Many-to-One 방법에서 문제가 되었던, System Call 호출 시 다른 Thread들이 Block되는 문제를 해결

• 여러 개의 Thread를 Multiprocessor에서 동시에 수행할 수 있음

• 한계점
  Kernel Thread도 한정된 자원이기 때문에, 무한정으로 생성할 수 없음
  Thread를 생성, 사용하려 할 때 그 개수에 대한 고려가 필요

Many-to-Many

• 여러 개의 User Thread를 여러 개의 Kernel Thread로 Mapping

• Many-to-One과 One-to-One Model의 문제점을 해결

• Kernel Thread는 생성된 User Thread와 같거나, 적은 수 만큼만 생성이 되어 적절히 Scheduling됨
  One-to-One처럼 사용할 Thread의 수에 대해 고민할 필요가 없음
  Many-to-One처럼 Thread가 System Call을 사용할 경우, 다른 Thread들이 Block되는 현상에 대해 걱정할 필요가 없음.

• Kernel은 적절히 User Thread와 Kernel Thread 사이의 Mapping을 조절하여, 위와 같은 장점을 보장할 수 있음
  

Thread로 인한 운영체제의 변화

Process 기반의 운영체제 System Call

• Process 관련 System Call Semantics는 Process 기준으로 작성됨
• Thread의 개념에 대한 고려 필요
  fork(), exec() : Thread 지원을 위해서 변화가 필요
  Thread 종료 문제 : Multi-thread일 경우, 함께 일하는 Thread의 종료는 Process보다 복잡해짐

Thread Issues : Creation

Fork()

Thread에서 fork() 요청 시,
모든 thread를 가지고 있는 Process를 만들 것인지,
fork()를 요청한 thread만을 복사한 Process를 만들 것인지.

Exec()

fork()를 하여 모든 Thread를 복사한 경우 exec()을 수행하면 모든 Thread들은 새로운 Program으로 교체가 됨

fork()를 하고 exec()을 수행할 경우 fork()를 요청한 Thread만이 복사되는 것이 더 바람직함
그러나 fork()를 하고 exec()를 수행하지 않는 경우에는 모든 Thread의 복사가 필요하기도 함

Thread Issues : Cancellation

• Thread Cancellation : Thread의 작업이 끝나기 전에 외부에서 작업을 중지시키는 것

• 하나의 Thread에서 중지 명령이 결국은 다른 Thread의 모든 작업을 중지시켜야 하는 경우

• 자원이 Thread에게 할당된 경우 Cancellation의 문제
  System의 자원을 사용하고 있는 Thread가 중지 될 경우 할당된 자원을 함부로 해제할 수 없음-다른 Thread가 그 자원을 사용하고 있을지도 모르기 때문

Thread Issues : Thread Pools

• Thread가 자주 생성되고 제거되는 상황에서 새로이 Thread를 만드는 시간이 실제 Thread가 동작하는 시간보다 긴 경우가 있음

Pool을 만들어 정해진 수 만큼의 Thread를 만든 후 Pool에 할당

Thread Issues : Thread IPC

• Multithreaded Programming에서는 Thread간 통신이 필요함
• Thread간 IPC 구현은?
  동일한 Process 내의 Thread 간 통신은, Shared Memory가 효율적임
  (Thread들은 같은 Process의 Data영역을 공유하므로)
• 결국 IPC가 최소화 됨
• 다른 Process에 존재하는 다른 Thread와의 통신은?
  Process의 경우와 비슷한 성능을 보임
  이런 통신이 빈번하다면, Program 설계의 잘못