OS: Thread(cooperating system)

Process를 보는 두가지 시야:

● 리소스 소유 단위
    프로세스에는 프로그램 코드 및 데이터가 포함된 주소 공간이 있음.
    프로세스에 파일이 열려 있거나 I/O 장치를 사용하는 경우.
● 스케줄링 단위
    CPU 스케줄러는 한 번에 하나의 프로세스를 CPU로 전송.
    프로세스와 연관된 것은 PC, SP 및 기타 레지스터의 값.

 

(~1988) 두가지 단위를 묶을 필요가 없다

Process = 리소스 소유 단위

Thread = 스케줄링 단위

스레드(LWP):

프로세스 내의 단일 순차적 실행 스트림

쓰레드는 child를 생성/block 할 수 있음

동시에 실행 됨 (고유한 레지스터=>프로그램 카운터(PC), 스택&스택 포인터(SP) 보유)

 

동시성 vs 병렬성

 

2. Concurrency vs Parallelism
(1) Concurrency

  - 병행성, 동시성
  - 여러 job 들이 interleaving 하면서 진행.
  - 실제로 동시에 진행되고 있지는 않지만, user 입장에서는 동시에 진행되는 듯한 illusion을 제공

(2) Parallelism

  - 병렬성
  - 여러 코어에서 실제로 동시에 실행되고 있는 것을 말함.
  - concurrent 하지 않아도 parallel 할 수 있다.

 

스레드가 다른 스레드와 공유:

    주소 공간, 프로그램 코드, 전역 변수, 힙,  OS 리소스(파일, I/O 장치)    

 

프로세스(HWP)의 자원:
    주소 공간, 프로그램 코드, 전역 변수, 힙, 스택, 리소스 없음(파일, I/O 장치 등)

 

프로세스 vs 스레드

• 프로세스는 여러개의 스레드를 가질 수 있다
• 스레드는 하나의 프로세스에 bound 된다
• 프로세스는 스레드 실행의 틀이다
  → PID, address space, user and group ID, open file descriptors, current working directory, etc.
• 스레드는 스케쥴링의 최소 단위이다
• 프로세스는 정적이지만 스레드는 동적이다.

멀티스레드의 장점

• Concurrency 를 구현하는데 드는 비용이 적다
• 멀티프로세스/코어 구조를 활용할 수 있다 (병렬가능)
• 리소스의 공유가 용이하다 (같은 주소 공간을 공유)

• 프로그램의 구조를 향상시킨다
  → 큰 task를 쪼개 여러개의 스레드로 처리할 수 있음

 

쓰레드 사용 이유:

서버:

    하나의 서버 프로세스에 여러 프로세스 사용 -> 하나의 쓰레드가 막혀도 다른 쓰레드로 대체 가능

    IPC를 안 써도 자원을 공유할 수 있음

    멀티프로세서 환경에서 이점을 취할 수 있음.

오버헤드 적음:

    생성의 오버헤드가 작음  => 스택이랑 레지스터 값을 저장할 공간만 있으면 됨

    매우 적은 자원을 사용 => 새 주소 공간, 글로벌 데이터, 프로그램 코드, OS 리소스가 필요하지 않음    context switch가 빠름 => pc, sp, register만 저장/복구 하면 됨하지만..    thread간의 protection이 없음 (설명 필요함)

 

멀티 쓰레드에 사용하기 좋은 프로그램:

    여러 개의 독립적인 작업이 있는 프로그램,

    여러 요청을 동시에 처리해야 하는 서버,

    반복적인 수치 작업 (날씨 예측과 같은 큰 문제를 작은 조각으로 나누고 각 조각을 별도의 스레드에 할당)

 

멀티 쓰레드에 사용하기 안좋은 프로그램:

    멀티프로세싱이 필요 없는 프로그램->대부분의 프로그램이 이러함. (예시?)   

     여러 프로세스가 필요한 프로그램(루트로 실행해야 할 수도 있음) (예시?)

---

사용자 수준 스레드:

kernel-level 쓰레드를 하나만 받아서 user-level에서 돌림.

이젠 없어져서 공부 안해도 된다네,,

사용자 프로세스가 자신의 스레드를 생성하고 관리할 수 있도록 기능 라이브러리를 제공 

user-level에서 구현 됨 -> OS의 구조를 바꾸지 않아도 됨.

 

빠름:

    프로시져 콜보다 쓰레드 스위치가 쌈

유연성:

    CPU 스케줄링을 알고리즘의 요구에 맞게 사용자가 정의할 수 있습니다.

또한:

    각 스레드까지 해당 프로세스의 다른 스레드에 대한 제어를 포기합니다 (병렬수행이 안된다는 건가?)

 

non-blocking syscall(즉, 멀티 스레드 커널)이 필요합니다.

->그렇지 않으면 프로세스에 실행 가능한 스레드가 남아 있더라도 커널에서 전체 프로세스가 차단됨.

여러 개의 사용자 스레드 중 하나의 스레드가 시스템 호출 등으로 중단되면 나머지 모든 스레드 역시 중단됨.

->이는 커널이 프로세스 내부의 스레드를 인식하지 못하며 해당 프로세스를 대기 상태로 전환시키기 때문이다.

 

장점: 동일한 메모리 영역에서 스레드가 생성/관리되므로 속도가 빠름 

 

커널은 프로세스 내부의 스레드를 인식하지 못함:

    프로세스 전체는 쓰레드의 수와 무관하게 하나의 time slice만 얻게 됨

    (그 하나의 timeslice를 여러 쓰레드가 공유해서 동시적으로 수행하나? -> 쓰레드가 일정 수보다 많아지면 의미가 없어지는거 아닌가?)

커널 레벨 스레드 (Kernel-Level Thread):

커널은 쓰레드에 대한 정보를 전부 가짐 -> 쓰레드가 많은 프로세스에게 더 많은 시간을 줌 (user-level과의 차이점.)

 

자주 block되는 애플리케이션(예: 프로세스 간 통신이 빈번한 서버 프로세스)에 적합합니다. (i/o같은것도 맞나?)

 

상당한 오버헤드와 커널 복잡성 증가 -> 커널은 스레드와 프로세스를 관리 및 스케줄링해야함.

(쓰레드마다 TCB 필요, user-level보다 약100배 느림, 요새는 빠르다네,,)

 

다 좋음.

 

스레드가 시스템 호출 등으로 중단되더라도, 커널은 프로세스 내의 다른 스레드를 중단시키지 않고 계속 실행시켜준다. 

멀티프로세싱 환경에서 커널은 여러 개의 스레드를 각각 다른 프로세서에 할당할 수 있다.

다만, 사용자 스레드에 비해 생성 및 관리하는 것이 느리다.

 

하나의 커널 쓰레드 -> LWP(괸리중인 쓰레드 중 누구에게 줄지 분배) -> 하나 이상의 유저 쓰레드

user-level thread는 사용자가 정함. (하나의 LWP에 너무 많은 유저 쓰레드를 두면 의미가 없어짐)

 

권한 상 LWP의 수가 Kernel Thread보다 많아질 수 없음.