Operating System: Threads (Chapter 5)

Threads란

• CPU utilization의 기본 단위.
• 하나의 process에는 여러개의 thread가 존재하고, 이 thread들은 동일한 data를 공유한다. 
• thread의 정체성은 register, stack이 결정한다.
  • 각 thread가 실행하고 있는 function은 서로 다르다 = register가 서로 다르다 (= program counter가 서로 다르다)
  • 각 thread가 실행하는 function call의 인자는 서로 다르다 = stack도 서로 다르다 

Benefit of Threads

1. Responsiveness: muti-threaded process(P0)에서 thread0가 I/O exception 발생시, 나머지 thread들이 일을 수행하기 때문에, P0는 time quantum 동안 CPU를 빼앗기지 않는다
2. Resource Sharing: thread는 서로 자원 (code, data, file) 공유가 가능하다
3. Economy: process 간의 context switch에 비해서 thread 간의 CPU switching은 매우 가볍다
4. Scalability: 여러 다른 CPU에서 단위 시간당 처리하는 Process의 수(throughput)가 증가한다 

 

User Threads

• 장점: Thread의 생성과 삭제에 kernel이 관여하지 않기 때문에, 생성과 삭제가 쉽다
• 단점: Blocking System Call 문제 >> OS 입장에서 process 안에 있는 user thread들은 보이지 않는다. 따라서 user thread가 I/O exception을 발생시키면, OS는 해당 process 전체가 일을 멈춘다고 생각하여, CPU를 빼앗는다. 이로 인해 thread의 효과가 사라진다. 

Kernel Threads

• 장점: thread가 I/O exception을 발생시켜도, 다른 thread들이 CPU를 잡고 일하기 때문에 blocking system call 문제를 피할 수 있다
• 단점: thread 생성과 삭제, 스케줄링과 관리가 kernel에 의해 이뤄지기 때문에, mode switch가 발생하는데, 이로 인해 user threads에 비해 overhead가 크다
• 요즘 대부분의 OS들은 kernel thread를 지원한다

Thread Issue 1: Semantics of fork() and exec() system calls

• Fork해서 생긴 child process에도 parent process와 동일하게 thread를 만들어 줘야 할까?
• P0에 4개의 thread가 있었고, P0가 fork에 의해 자식 process P1을 생성한다. 이때 P1에도 thread 4개를 동일하게 만들어 줘야할지에 관한 design option이다. 
  • 이 문제가 생기는 이유는 fork 이후 바로 exec을 호출하면, 애써 생성한 P1의 thread가 무용지물이기 때문이다
  • 이 부분에 관해서는 OS designer의 선택사항인데, UNIX의 경우, fork 이후 exec이 호출되지 않은 경우에만 부모와 동일하게 자식에도 thread를 생성한다. 

Thread Issue 2: Signal Handling 

• Thread에 signal이 전달되었을 경우, 그 처리를 process 전체에 대해서 하는 것이 아니라 해당 thread에 대해서만 하는 것
  • 예시 시나리오: kill signal이 thread0에 올 경우, process 전체를 kill하는 것이 아니라 thread0만 kill할 수 있어야한다

Thread Issue 3: Thread Cancellation

• Process가 죽을 때 사후처리는 부모 process가 담당한다. Thread가 죽으면 그 처리는 누가, 어떻게 할까?
• Asynchronous cancellation
  • 사후처리 없이 즉시 죽는 것
  • thread의 작업 내용을 날아간다
• Deffered cancellation
  • thread 스스로가 사후처리 (data save 등)를 마무리하고 exit
  • 시간이 좀 걸린다

Thread Issue 4: Thread Pools

• 처음 kernel booting 시, 당연히 연달아 여러개의 thread를 만들게 된다.
• 이런 초기 thread creation에 의한 kernel mode switch 때문에 생긴 overhead를 줄이기 위해서, kernel booting 단계에서 몇 개의 thread를 미리 만들고, thread 생성 요청이 들어오면, 미리 만들어 둔 것의 pointer만 넘겨준다 

Thread Issue 5: Thread Specific Data

• thread가 사용하는 data에 대한 local copy를 만들지 않는 것이 원칙이다
• 그러나 data base system에 관한 시나리오에서는 예외적으로 thread0가 data A에 read/write할 경우, thread0를 위한 local copy를 만들고, copy에서 read/write 작업을 하도록 하는데, 이러한 local copy를 thread specific data라고 한다
• 이걸 만드는 이유는 DB에서는 데이터에는 한 순간에 한 사람만 접근할 수 있도록 하는 것이 concurrentcy problem 을 해결하는 방침인데, 이걸 지키면서 thread의 data 작업을 진행하면 병렬성이 너무 떨어지기 때문이다

 

Multicore Programming

• Thread programming이 필요한 경우가 multicore prgramming인데, 크게 두가지 측면에서 이 작업은 매우 어렵다
  • Algorithm적 측면
    • Dividing activities balance: Thread 별로 어떻게 program을 나눌지 결정하는 것이 매우 어렵다. 
      • 전체 program의 종료는 마지막에 끝난 thread를 기점으로 한다
      • 따라서 thread별로 load balancing을 고려하면서 일을 나눠야한다
    • Data splitting: Thread 별로 data를 나눠 주는 것이 어렵다. 
  • Coding의 어려움
    • Data dependency: thread0이 만든 data에 thread2가 접근하는 일이 없도록, thread 간의 dependency가 없도록 일을 나눠야한다.
    • Testing and debugging: 공유된 data에 대해서 각 thread가 값을 변화시키는데, 이 값이 항상 옳은지에 대한 보장이 어렵다.