[Operating System] 쓰레드

쓰레드란 무엇인가?

Definition of a thread

 

쓰레드가 쓰레드라고 불리는 이유는, 프로세스의 Instruction 을 수행할 때 그 위치를 점처럼 찍었다 생각하고 멀리서 보면 실처럼 보인다고 해서 쓰레드라고 불리게 되었다고합니다.

 

쓰레드의 정의는 프로세스에서 Instruction 을 실행하는 단위를 이야기한다고 합니다. 하지만 이보다 lightweight process 가 더 와닿는 표현 같습니다. 그 이유는 뒤에서 알 수 있습니다.

 

프로세스 vs 쓰레드

많이, 자주 헷갈리는 개념이 프로세스와 쓰레드입니다. 프로세스와 쓰레드의 차이점에 대해서 하나씩 짚어봅시다.

 

프로세스의 정의를 프로세스에서 Instruction 을 실행하는 단위라고 했습니다. 조금 바꿔 말하면, 프로세스의 Instruction 을 수행하는 것이 쓰레드입니다.

쓰레드는 프로세스의 User Context 의 code, data, files(Ex. stdin, stdout, stderr) 을 공유합니다.

그리고 쓰레드는 독자적인 stack 과 register context 를 갖습니다. -> 이것을 TCB 라고합니다.

프로세스는 여러 개의 쓰레드를 가질 수 있고, 이 쓰레드들을 감싸고 있는 껍질같은 개념입니다. VAS, 다른 프로세스로부터 접근 보호 드으이 기능은 프로세스 단위로 이루어집니다.

쓰레드는 이 프로세스의 Context 내에서 동작합니다. 프로세스가 점유하고 있는 Main Memory 의 공간에서 자원을 활용하고 활동할 수 있습니다.

 

프로세스와 쓰레드의 이해.

 

쓰레드를 이용할 때의 장점

쓰레드 사용의 장점

쓰레드를 사용하면 프로세스를 하나 생성하는 것보다 자원을 효율적으로 사용할 수 있습니다. 왜냐하면 프로세스를 생성하기 위해서는 메인 메모리에 code, data, files 등의 context 를 다올려야하는데 쓰레드를 이용하면 stack 과 register context 만 고려해주면 되기 때무입니다.

그리고 쓰레드 간에 통신은 IPC 와 달리 Kernel 을 거칠 필요가 없습니다. 그냥 Process 의 data 영역으로 통신하면 되기 때문입니다.

 

 

 

다음과 같은 상황을 가정해봅시다. Thread A 는 I/O 를 다루는 쓰레드입니다. Thread B 는 들어온 데이터를 처리하는 쓰레드입니다. 만약 단일 쓰레드로 구현됐다면 이 프로세스에 I/O Interrupt 가 발생한 경우 이 프로세스는 CPU 를 점유하더라도 Instruction 을 처리하지 못하는 Blocked State 지만 멀티 쓰레드로 구현함으로써 I/O 를 다루는 쓰레드에 I/O Interrupt 가 발생하더라도, Thread B 가 CPU 를 점유하고 쌓여있는 데이터를 처리할 수 있습니다.

멀티 쓰레딩의 이점

 

또 멀티쓰레드로 구현하는 것이 멀티 프로세스로 구현하는 것에 대해 이점을 갖는 경우를 살펴봅시다.

멀티 프로세스 - IPC 를 이용하므로 Kernel Mode Change 발생

멀티 프로세스의 경우 프로세스간 통신이므로 IPC, 즉 커널로의 모드체인지가 필수적입니다. 커널로 모드체인지 할 경우, 커널은 IPC 만을 위한 명령을 처리하는 것이 아니라 항상 Kernel 은 운영체제로서 수행해야할 루틴이 있습니다. IPC 처리하는 명령 + 정해진 루틴을 다 수행해야하므로 느립니다.

반면 멀티 스레드로 구현할 경우, 그냥 같은 Process Context 의 data 영역으로 통신하면 되므로 속도면에서 빠릅니다. 이는 마치 Kernel 에게 shared memory 를 요청하지 않고도 shared memory 를 얻은 것과 비슷한 효과입니다.

 

쓰레드의 구현방법

User-level Thread

유저 레벨의 쓰레드

유저 레벨 쓰레드란, 커널이 아닌 유저 레벨에서 만들어진 쓰레드를 의미합니다. 이것은 Threads Library 등을 통해 수행될 수 있습니다. 커널은 유저레벨 쓰레드는 쓰레드로 인지하지 못합니다. 만약 유저레벨 쓰레드 중  I/O Interrupt 같은 CPU 가 주어져도 인스트럭션이 수행될 수 없는 쓰레드가 존재하게 되면 커널은 이 프로세스가 Blocked 상태라고 인지하고, 이 프로세스는 CPU 가 주어져도 인스트럭션을 수행할 수 없습니다. 그리고 멀티 쓰레드 어플리케이션은 멀티 프로세싱의 이점을 누릴 수 없습니다.

 

그렇다면 이런 유저 레벨 프로세스를 왜 쓸까요?

 

커널 레벨 프로세스에 비해 스케쥴링 오버헤드가 적습니다. 아무래도 커널을 거치지 않으니 커널의 루틴한 일도 수행하는 횟수가 줄고 그래서 더 빠릅니다.

커널 레벨 프로세스에 비해 가볍습니다. 유저 레벨에서 관리되는 쓰레드는 커널 레벨의 그것보다 자원을 덜 소비합니다.

유저 레벨에서 관리되는 쓰레드는 프로그래머가 자기 마음대로 스케쥴링과 자원 할당을 수행할 수 있습니다.

유저 레벨에서 생성된 쓰레드는 OS 에 종속적이지 않게 동작합니다.

 

리눅스에서 커널 수준의 쓰레드

리눅스에서 커널 레벨 쓰레드

리눅스에서 커널 수준의 쓰레드를 lightweight process 라고 부릅니다. 리눅스에서는 커널 수준의 쓰레드가 생성되면 PCB 가 생성됩니다. 이 PCB 는 Memory Info 에 프로세스의 code, data, file context 를 가리키고 독자적인 stack, register context 를 갖습니다.