[운영체제 스터디] 2주차(Ch.3, 4) 볼 만한 내용

3단원

4단원

• POSIX thread는 API에 불과하고, 결국 구현 방식은 OS마다 다 다르다.

• user-level thread vs kernel-level thread?

  • user-level thread
    • 구현이 전부 user-level에서 이루어짐. 정확한 구현 자체는 kernel에서 모르고, kernel 입장에서는 그냥 하나의 thread인 것 처럼 보인다. -> CPU scheduling 시에 그냥 하나의 task로 보고 스케줄링함.
    • kernel 입장에서는 하나의 task에 불과하므로, multiprocessor system의 경우 실제로 동시에 실행되지는 않는다.
    • 하나의 스레드에서 block 상태가 되는 행동을 했을 때 (I/O request 등) 요청한 스레드 뿐만 아니라 프로세스 전체가 Block 상태가 된다.
  • kernel-level thread
    • 구현 및 관리가 전부 kernel-level에서 이루어진다.
    • thread 마다 scheduling이 가능하고, multiprocessor system에서도 동시에 실행가능하다.
    • thread 관리 및 스케줄링(context switch)이 일어날 때 마다 kernel mode로 스위칭이 되어야 하고, 그로 인해 user-level에 비해 overhead가 많이 발생한다.
    • Blocking request가 발생하더라도 요청한 스레드만 Blocked 상태가 되고, 나머지는 정상적으로 실행 가능하다.

• LWP (Light Weight Process)

  • user-level thread와 kernel-level thread 사이를 이어주는 역할을 한다.
  • 사실상 many-to-many 모델과 two-level 모델에서 쓰인다.
  • CPU scheduling이 physical processor와 kernel thread를 연결해주는 역할을 한다면, 이와 마찬가지로 thread library는 LWP와 user thread를 연결해주는 역할을 한다. 그런 의미에서 LWP를 virtual processor라고도 부른다.
  • 다른 계층에서 일어나는 CPU scheduling이라고 생각하면 될 듯.
  • kernel에서는 interrupt를 통해 스케줄링 되듯이, LWP는 upcall을 이용해서 스케줄링을 한다.
  • ex) kernel에서 해당 스레드가 block이 될 것이라고 upcall 날려줌 & 새로운 LWP 제공 -> thread library는 새로운 LWP에서 upcall handler를 실행, 여기서 block되던 스레드의 context를 저장 후 다른 준비된 thread에다가 기존 block되는 스레드가 실행되던 LWP를 제공해 준다. (사실상 CPU scheduling과 다를 게 없다.)
    

  이 사진이 굉장히 많은 것을 말해준다.
  

리눅스의 경우, user-level thread와 kernel-level thread는 1-1 correspondence를 가진다.
thread가 생성될 때, mmap 함수에 의해 thread의 stack 영역, TLS 영역을 포함한 여러 정보들에 대한 메모리 할당이 이루어진다.