CS + 인프라/운영체제

[운영체제] : 쓰레드는 많으면 좋나요? - 3탄 : 정말 쓰레드는 많으면 좋나?

공대키메라 2025. 5. 18. 15:20

이번에는 쓰레드가 정말 많으면 좋은지, 다각면에서 알아보고 정리하려고 한다.

 

프로세스쓰레드에 대해 명확히 이해하느라 이 답에 대한 질문을 알기까지 오랜 시간이 걸렸다.

 

이번 장에서는 프로세스와 쓰레드에 대해 다시 복기하고

 

쓰레드가 많으면 좋은지 안좋은지에 대한 해답을 찾으려 한다.


0. 들어가기 전에

0.1 Context Switching(문맥 교환)

Switching the CPU to another process requires saving the state of the current process and restoring the state of a different process. This task is known as as context switch.

 

다른 프로세스에서 CPU를 switch하는건 현재 프로세스의 상태와 다른 프로세스의 상태를 저장해야한다.

 

이 작업이 context switch이다.

 

context switch가 일어나면 커널은 PCB에 오래된 프로시스의 context 를 저장하고 실행할 새로운 프로세스의 context 를 저장한다.

 

여기서 context 란 영어 단어로 문맥으로 해석될 수 있는데, 프로세스/스레드의 상태를 말한다.

 

context switch 가 일어나는 동안 시스템은 아무 일도 할 수 없어서 순수하게 overhead이다.

 

기계에 따라 이 속도는 다르며 이 또한 많은 요소에 따라 다르다.

 

0.2 필요한 이유

 

  • 현재 실행 중인 프로세스나 스레드에 할당된 시간이 종료되어, CPU를 해제하고 대기 중인 프로세스(또는 스레드) 중 하나에게 할당해야 하는 상황
  • 프로그램 실행 중 커널 함수가 호출되는 경우
  • 우선순위가 더 높은 태스크가 현재 실행 중인 태스크를 선점할 때

나중에 CPU 스케줄링에 대해서도 정리할 예정이다.

 

0.3 컨텍스트 스위칭의 흐름

 

https://afteracademy.com/blog/what-is-context-switching-in-operating-system/

 

해당 그림은 process인 p1, p2의 흐름에 대해 보여준다.

 

  1. 초기 상태: 프로세스 P1은 실행 중(Executing) 상태이고, 프로세스 P2는 대기(Idle) 상태에 있다.
  2. 첫 번째 컨텍스트 스위칭 : 다시 인터럽트나 시스템 콜이 발생 -> P2의 상태 정보를 PCB2에 저장 -> P1의 상태 정보를 PCB1에서 불러옴 -> P2는 대기 상태로 전환되고, P1은 다시 실행 상태로 전환
  3. 두 번째 컨텍스트 스위칭 : 다시 인터럽트나 시스템 콜이 발생 -> P2의 상태 정보를 PCB2에 저장 -> P1의 상태 정보를 PCB1에서 불러옴 -> P2는 대기 상태로 전환되고, P1은 다시 실행 상태로 전환

장점은 딱~봐도 CPU 활용을 극대화 할 수있는 방법으로 보인다.

 

단점은 딱~ 봐도 작업이 멈추는 공간이 자세히 생각해보면 분명 있다. CPU 의 작업이 context switching때문에 멈추는 것이다.

 

기존에 실행중인 정보를 저장하고, 새로운 프로세스의 정보를 받아와소 실행 좀 하고, 다시 새로운 프로세스의 정보를 저장하고 기존의 프로세스 정보를 불러오고....

 

그렇게 되면 너무 많은 context switching이 일어나면 실제로 필요한 작업보다는 context switching 을 하는데 시간을 더 쓰게 된다.

 

1. 프로세스와 쓰레드 리마인드

프로세스?

A process in computing is an instance of a computer program that is running on one or more threads. 

 

컴퓨팅에서 프로세스는 하나 이상의 스레드에서 실행 중인 컴퓨터 프로그램의 인스턴스입니다.

 

쓰레드?

A thread is a single sequence stream within a process

 

스레드는 프로세스 내에 하나의 순차 흐름이다. 스레드는 일반적으로 프로세스의 하위 그룹인 반면, 프로세스는 일반적으로 자율적입니다.

 

2. 프로세스와 쓰레드 간략 비교

프로그램은 기본적으로 여러 프로세스를 사용하는것 보다 여러 스레드를 사용해서 더 적은 자원을 사용할 수 있다.

 

1탄에서의 기억을 더듬어보면 프로세스에서 우리가 논의한 IPC(Inter Process Communication의 경우에는 메시지 전송 혹은 메모리 공유 방식을 통해서 서로 communicate했다.

 

반면에 쓰레드는 전송 메커니즘이 필요없고 같은 프로세스 내의 메모리와 자원을 공유하기에 효율적이다. 

 

 

문맥 교환(context switching)도 프로세스 그룹보다 스레드 그룹에서 사용하면 더 성능이 좋다.

 

왜냐하면 위에 언급했듯이 전송 메커니즘이 필요없고 같은 프로세스 내의 메모리와 자원을 공유하기 때문이며,

 

프로세스의 경우에는 PCB를 사용해서 프로세스를 전환하는데 PCB는 커널모드로의 전환이 필요하다.

 

쓰레드의 경우에는 커널의 개입이 없이 전환이 가능하다.

 

 

3. 너무 많은 쓰레드를 생성한 경우?

너무 많은 쓰레드를 생성한 경우 context간에 스위칭을 하는데 너무 많은 시간을 써야 한다. 

 

CPU 의 코어 수는 코정되어 있는데 스레드 수를 계속 늘리면 각 코어에서 경헙하는 스레드의 수가 점점 많아질 것이고,

 

자연스럽게 overhead 도 많아질 것이다. 

 

이를 다시 말하면 각각의 쓰레드가 초기화와 멈추는 작업을 하는데 실제로 일을 하는 시간보다 많아지게 된다는 점이다. 

 

또한, 하드웨어의 자원도 제한되어 있기에 과도한 쓰레드는 자원을 두고 경쟁을 유발하며 오버헤드가 발생한다.

 

그렇기에 thread수를 제안해야한다. 매번 thread를 생성하기보다는 쓰레드풀을 이용하면 쓰레드의 이상적인 수를 유지할 수 있다.

 

 

4. CPU Bound vs I/O Bound

 

CPU Bound

작업 또는 프로그램의 실행이 CPU에 크게 의존하는 시나리오를 말한다.

 

이러한 작업에는 CPU를 많이 사용하는 복잡한 계산, 데이터 처리 및 알고리즘 연산을 포함한다.

 

CPU Bound 는 긴 CPU Burst 를 가지는 경향이 있는데 CPU Burst란 CPU 작업을 실행하는데 걸리는 시간의 양을 말한다. 

 

 

 

I/O Bound

I/O bound 작업은 입출력 작업이 완료될 때까지 상당한 시간을 대기하는 작업이다.

 

데이터베이스, 파일 시스템, 네트워크 요청 등과 같은 외부 리소스와의 상호 작용을 포함한다.

 

 

 

I/O bound 작업에서는 CPU 가 놀고 있는 시간이 많으니 코어 수보다 배 이상의 스레드 수를 늘려주는 것이

오버헤드가 증가해도 코어들을 효율적으로 쓸 수 있기에 성능면에서 이점이 크다.

 

즉, CPU 가 놀지 않도록 다른 스레드들이 CPU를 사용할 수 있도록 하는 것이다.

 

 

5. 최적의 쓰레드 수는?

CPU Bound 프로그램에서 적절한 쓰레드 수는 CPU 갯수에 1을 추가한 수를 추천한다.

 

기본적으로 하나의 코어에서는 하나의 쓰레드만 실행이 가능하다.

 

고로 CPU Bound 작업을 하는 경우에는 thread 수를 많이 가지고 있을 필요가 없다.

 

 

그러면 IO Bound 프로그램은 스레드 몇 개로 구현이 적절한가?

 

일반적으로 코어 보다 많은 쓰레드를 사용하는 것이 합리적이다.

 

 

6. 내가 할 답변은?

면접관 : 정말 스레드가 많으면 좋을까요? 쓰레드는 항상 많으면 빠를텐데... 정말 그런가요?

키메라 :
CPU 바운드 작업의 경우, 코어 수 + 1 정도의 스레드가 적합합니다. 이는 물리적 코어 하나에서 한 번에 하나의 스레드만 실행 가능하기 때문입니다. 따라서 CPU 연산이 많은 작업에서는 과도한 스레드 생성이 오히려 컨텍스트 스위칭으로 인한 오버헤드만 증가시킵니다.

I/O 바운드 작업의 경우에는 코어 수보다 많은 스레드를 사용하는 것이 유리합니다. I/O 작업이 진행되는 동안 CPU가 대기하게 되므로, 다른 스레드가 그 시간에 CPU를 활용할 수 있기 때문입니다. 그러나 이 경우에도 무한정 스레드를 늘리는 것은 문제가 됩니다.

따라서 최적의 스레드 수는 작업 특성(CPU/I/O 바운드)과 시스템 환경을 고려하여 결정해야 합니다. 일반적으로 스레드 풀을 사용하여 적절한 스레드 수를 관리하는 것이 좋은 방법입니다

 


 

후... 그래... 이렇게 대답하면 된다.

 

이를 위해서 생각보다 기초부터 공부하고 찾다보니 많은 시간이 걸렸다.

 

 

 

출처:

https://www.techtarget.com/whatis/definition/context-switch

https://www.baeldung.com/cs/servers-threads-number

https://www.geeksforgeeks.org/context-switch-in-operating-system/

https://afteracademy.com/blog/what-is-context-switching-in-operating-system/

https://www.baeldung.com/cs/os-cpu-context-switch

https://www.youtube.com/watch?v=jSaBkvtHhrM

https://www.baeldung.com/cs/cpu-io-bound

https://www.youtube.com/watch?v=qnVKEwjG_gM&list=PLcXyemr8ZeoQOtSUjwaer0VMJSMfa-9G-&index=4

https://www.baeldung.com/cs/cpu-io-bound