[운영체제/OS] 프로세스 모델의 한계과 멀티쓰레드의 필요성

0. 프로세스 모델의 한계

프로세스 기반 모델에서 애플리케이션은 동시에 요청되는 여러가지 상황에 대해 fork()를 통해 Child process를 만듭니다. 예를 들어 웹 서버는 각 클라이언트의 요청에 대해 서버가 Child process를 생성하여 클라이언트의 요구를 처리하죠. 하지만 요청이 많아질수록 서버가 생성해야 하는 Child 프로세스에 대한 메모리는 증가할 수밖에 없으며 주소 공간과 자원 역시 공유되어 효율성이 떨어지게 됩니다.

 

또한, 전통적인 프로세스 기반 모델은 Multiprocessor 아키텍쳐의 장점을 살리지 못했습니다. 각 프로세스는 오직 하나의 프로세서(CPU)에서 밖에 돌지 못했기 때문이죠. 따라서 N개의 CPU가 존재한다고 하더라도 각 프로세스는 오직 1개의 CPU에서밖에 돌지 못하기 때문에 1/N으로 나누어서 일을 처리할 수 없었고, 프로세스 간 Context Switching 오버헤드로 인한 비효율도 초래했죠.

 

이러한 프로세스 기반 모델의 특징 때문에 멀티쓰레딩(Multithreading)의 필요성이 제기되었습니다.

---

1. 멀티쓰레드(Multi-Thread)란?

이전에 배웠던 프로세스의 구조를 다시 한 번 살펴보겠습니다. 참고로 아래 그림은 프로세스의 이미지 영역을 나타낸 것이고, 이미지에 Program Context와 Kernel Context가 붙습니다. 여기서 Kernel Context는 이전 시간에 설명한 Within-User Process 기반 OS 디자인 방식을 가정합니다.

 

프로세스 이미지 구조

 

그렇다면 멀티쓰레딩이란 건 과연 어떤 개념일까요?

 

멀티쓰레딩이란 기본적으로 위의 프로세스 이미지를 공유 가능한 부분과 공유 가능하지 않은 부분으로 나누고 공유 가능한 부분을 Thread란 개념으로 사용하는 방식입니다.

 

다시 말해서 공유 가능한 Shared libraries, Runtime heap, Read/Write Data, Read-only Code/Data 등과 Kernel Context는 하나로 떼어두고, 특정 시점의 Program Counter(PC)에 따라 스택 영역의 메모리가 달라지기 때문에 스택 영역은 각 쓰레드가 개별적으로 가지는 것이죠.

쓰레드의 메모리 구조

  

 

2. 멀티쓰레드와 컨텍스트 스위칭(Context Swtiching)

컴퓨터에서 동시에 처리할 수 있는 최대 작업의 수는 CPU의 코어(core) 수와 같습니다.

만약 CPU의 코어 수보다 더 많은 스레드가 실행되면, 각 코어가 정해진 시간 동안 여러 작업을 번갈아가면서 수행하게 됩니다.

 

이 때, 각 쓰레드가 서로 교체될 때도 쓰레드 간의 Context Switching이 발생하는데요. 쓰레드는 코드, 데이터, 힙 영역 등을 공유하기 때문에 프로세스보다 Context Switching이 빠릅니다. Context Switching을 할 때 캐시 메모리를 비울 필요가 없고 메모리의 매핑도 공유하는 영역이 크기 때문에 크지 않기 때문이죠.

 

하지만, 이러한 Context Switching에 걸리는 시간이 0은 아니기 때문에 굉장히 잦은 Context Switching은 멀티쓰레드 환경에서도 비효율을 초래합니다. 따라서 오히려 많은 양의 단순한 계산은 싱글 스레드로 동작하는 것이 더 효율적일 수 있는 것이죠.

 

즉, 멀티쓰레드는 멀티프로세스보다 Context Switching 오버헤드에서 우위를 가지지만, 많은 수의 쓰레드를 실행하는 것이 항상 좋은 성능을 보장하는 것은 아님에 주의해야 한다는 것입니다.

 

 

 

---

 

 

다음 포스팅에서는 이제 멀티쓰레딩을 실제로 어떻게 구현할 것인지에 대해 공부해보겠습니다.

06. Implementing Threads