Thread(쓰레드)

미리 정리해가면 좋은 용어

concurrency- 병행성 (context switch로 동시에 진행되는 것처럼 보이게 만드는것) - (단일 코어 느낌)

parallelism - 병렬성 (실제로 동시에 진행하는것) -(멀티 코어 느낌)

 

0. 배경설명

컴퓨터에 있는 요소 중 CPU, RAM, memory중에

옛날에는 CPU가 느렸고, 상대적으로 RAM과 memory가 빨랐기때문에 concurrency같은걸 할필요가 없었다.

그러나 요즘에는 CPU가 되게 빨라졌고, 때문에 RAM과 memory가 상대적으로 느리다.

이 기다리는게 아쉬워진 사람들은 concurrency를 도입했다. 

 

그러나 여전히 느리다고 생각한 사람들은 multicore(CPU를 여러개 사용하는것)- 이제 concurrency를 넘어 parallelism을 하게 되었다.

 

이로인해 cpu내에서 노는 속도는 되게빨라졌는데, 이제 process와 관련된 속도가 느려보인다. (만들기, context switch등)

Amdahl's law에 의해서 느린놈을 잡아줘야 속도상승이 드라마틱하게 나므로 이 문제를 해결해야 하는데, 

이 프로세스 관련 issue를 해결한게 우리가 공부할 Thread란 놈이다.

 

1. Process와 Thread의 차이

Process 내에는 크게 code(우리의 코드), data(전역변수등), stack(지역변수류), heap(malloc 계열)이 존재한다. 

이중 Thread는 오직 stack만 개인적으로 가지고있고(CPU state포함), 그 외에 code, data, heap을 공유한다. 

(이로인해 두 thread가 동시에 전역변수에 접근할경우, 공유자원 문제가 발생하고 synchronization을 해줘야함)

 

따라서 switch 비용이 저렴하고(stack만 바꾸면 되니) 따로 프로세스를 만들 필요도 없다. 거기다 thread끼리 소통도 간편하다(process의 경우 소통하기 위해서 kernel과 OS를 거쳐야한다)

 

보통 thread에 대한 구현은 그냥 process의 virtual memory안에 stack을 여러개 둔다. 

 

2. Thread scheduling

우리가 이미 배웠던 process scheduling과 거의 동일하게 진행한다고 보면된다. (다만 context switch가 좀더 저렴하다)

 

3. kernel과 thread

User level에서는 모든 부분을 제어하지 못하기 때문에, kernel을 따로 만들고 거기서 protection을 해준다는 것은 알고 있을 것이다.

그렇다면, thread마다 kernel이 하나씩 있을까? 아니면 process마다 kernel이 하나씩 있을까?

둘다 가능하지만, 일반적으로는 전자가 좀더 많다. 

 

 

process마다 kernel이 하나씩 있을 경우

장점: kernel thread 개수가 적으므로, 시스템에 부담이 적다. 

문제점: 하나의 Thread가 I/O로 이 process에서 donation 해버리면(context switch 되면), 다른 작업도 멈춘다. 

 

thread마다 kernel이 하나씩 있을 경우

장점: 병렬성이 훨씬 자유도가 높다.

단점: 너무 많은 kernel thread는 문제를 일으킬 수 있다.

 

또한 이러한 문제점을 해결하기 위해서 다대다 모델등도 존재한다.