스레드와 스레드 풀

 

 

🎈 Hardware thread

코어(core)의 고민: 메모리에서 데이터를 기다리는 시간이 꽤 오래 걸린다. 

 

메모리를 기다리는 동안 다른 스레드를 실행하는건 어떨까?

 

core: compute → memory → compute → memory

메모리에 접근할 때마다 core는 쉬게 됨. 

 

하나의 core: compute → memory → compute → memory

                     memory → compute → memory → compute

각각을 하드웨어 스레드라고 칭함. 

 

인텔의 hyper-threading

: 물리적인 코어마다 하드웨어 스레드가 두 개

 

Hardware thread

: OS 관점에서는 가상의(logical) 코어

만약에 싱글 코어 CPU에 하드웨어 스레드가 두 개라면 OS는 이 CPU를 듀얼 코어로 인식하고 듀얼 코어에 맞춰서 OS 레벨의 스레드들을 스케줄링 한다. 

 

Q. 인텔 듀얼 코어 CPU에 hyper-threading이 적용됐다면 하드웨어 스레드는 총 몇 개 인가요?

4개. OS는 CPU를 4코어로 인식함. 

 

 

 

커널(kernel)

: 운영체제의 핵심

: 시스템의 전반을 관리/감독하는 역할

: 하드웨어와 관련된 작업을 직접 수행

 

🎈 OS Thread

: OS 커널 레벨에서 생성되고 관리되는 스레드

: CPU에서 실제로 실행되는 단위, CPU 스케줄링의 단위

: OS 스레드의 컨텍스트 스위칭은 커널이 개입 → 비용 발생

: 사용자 코드와 커널 코드 모두 OS 스레드에서 실행된다

 

OS 스레드는 아래와 같이 불리기도 함. 

- 네이티브 스레드, 커널 스레드*, 커널-레벨 스레드, OS-레벨 스레드

 

Q. OS 스레드 여덟 개가 하이퍼 스레딩이 적용된 인텔 듀얼코어 위에서 동작한다면 OS 스레드들을 어떻게 코어에 균등하게 할당할 수 있을까요?

 

 

다른 맥락에서 Kernel Thread

: OS 커널의 역할을 수행하는 스레드. 

  즉, 커널 코드를 수행하는 스레드를 커널 스레드라고 하기도 함. 

 

 

🎈 User Thread

: 스레드 개념을 프로그래밍 레벨에서 추상화 하나 것

유저-레벨 스레드라고 불리기도 함.

 

Thread thread = new Thread();

thread.start(); // OS 시스템 콜 호출함으로써 OS 레벨의 스레드 생성

 

유저 스레드가 CPU에서 실행되려면 OS 스레드와 반드시 연결돼야 한다. 

 

그렇다면 유저 스레드와 OS 스레드를 어떻게 연결시킬 것인가?

1. One-to-One model (자바가 채택)

유저 스레드와 OS 레벨의 스레드가 일대일로 연결됨. 

스레드 관리를 OS에 위임, 스케줄링도 커널이 수행.

유저 스레드가 멀티코어 환경을 잘 활용할 수 있음. 

한 스레드가 블락 상태여도 다른 스레드는 잘 동작함. 

일대일 매핑 관계이기 때문에 race condition이 발생할 수 있음. 

 

2. Many-to-One model

유저 스레드 여러개와 OS 레벨의 스레드 하나에 연결됨. 

컨텍스트 스위칭이 유저 레벨에서만 이루어지고 커널이 개입하지 않기 때문에 컨텍스트 스위칭이 더 빠름. 

유저 스레드 같의 스위칭이 one-to-one 모델보다 빠름. 

OS 레벨에서 race condition 가능성이 적다. 

OS 스레드 하나이므로 멀티코어 환경을 활용할 수 없음. 

한 스레드가 블락 → 모든 스레드들이 블락 => 이를 해결하기 위해 non block I/O 사용함.

 

3. Many-to-Many model

유저 스레드들이 적절한 개수의 OS 스레드에 연결됨. 

유저 스레드간의 스위칭이 빠르면서 멀티 코어를 활용, 

하나를 블럭해도 다른 스레드가 블럭 되지 않음. 

구현이 어렵다는 단점.

 

 

다른 의미의 User Thread

OS와는 독립적으로 유저 레벨에서 스케줄링되는 스레드를 유저 스레드라고 하기도 함. 

 

 

 

 

 

🎈 Green Thread

Java 초창기 버전은 Many-to-One 스레딩 모델을 사용. 이 때 이 유저 스레드들을 그린 스레드라고 칭함.

OS와는 독립적으로 유저 레벨에서 스케줄링되는 스레드.

맥락에 따라 유저 스레드 = 그린 스레드.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

🎈 스레드 풀

 

API 요청 방식 중 Thread per request model이 있음. 

: request마다 thread를 하나씩 할당해서 하나의 request를 하나의 thread가 처리하도록 하는 것. 

 

 

만약 thread per request 모델의 동작 방식이

서버에 들어오는 요청마다 스레드를 새로 만들어서 처리하고, 처리가 끝난 스레드는 버리는 식으로 동작

한다면 어떤 문제가 생기는가??

 

• 스레드 생성에 소요되는 시간 때문에 요청 처리가 더 오래 걸림.

 

• 처리 속도보다 더 빠르게 요청이 늘어나면

  → 스레드가 계속 생성(스레드 수 증가)

  →  컨텍스트 스위칭이 더 자주 발생

  →  CPU 오버헤드 증가로 CPU time 낭비→

  →  서버 전체가 응답 불가능 상태에 빠짐

 

• 처리 속도보다 더 빠르게 요청이 늘어나면

  →  스레드가 계속 생성(스레드 수 증가)

  →  메모리 고갈

 

 

 

미리 스레드를 여러 개 만들어 놓고 재사용 → 스레드 생성 시간 절약

제한된 개수의 스레드를 운용 → 스레드가 무제한 생성되는 것을 방지

 

Thread pool 사례: 여러 작업을 동시에 처리해야 할 때

•  thread per request 모델

•  task를 subtask로 나뉘어서 동시에 처리

•  순서 상관없이 동시 실행이 가능한 task 처리

 

 

Thread pool 사용 팁

1. 스레드 풀에 몇 개의 스레드를 만드는 것이 적절한가?

   CPU 코어 개수의 task의 성향에 따라 다름. 

   CPU-bound task라면 코어 개수 만큼 혹은 몇 개 더 많은 정도

   I/O-bound task라면 코어 개수보다 1.5배? 두 배? 세 배? 경험적으로 찾아야 함. 

2. 스레드 풀에서 실행될 task 개수에 제한이 없다면

   스레드 풀의 큐에 사이즈 제한을 확인할 것!

 

 

자바의 Executors 클래스

static 메서드로 다양한 형태의 스레드 풀을 제공

ExecuterService threadPool = Executors.newFixedThreadPool(10);

threadPool.submit(task1);

threadPool.submit(task2);

=> Queue size에 int max_val이 들어갔으므로 스레드 풀에 요청이 많아지면 큐에 계속 쌓일 수 있는 위험 요인이 있다. 

     사이즈 제한이 없는 큐는 상황에 따라서는 메모리를 고갈시키는 잠재적 위험 요인이 될 수 있다. 

     큐가 다 차면 이후의 요청을 버리더라도 전체 시스템에 영향을 주지 않도록 해야 함. 

 

 

pool이라는 개념이 스레드에만 쓰이는 것은 아님. 

connection pool, process pool, ...

CPU bound 프로세스를 관리할 때는 process pool을 사용해야 한다. 

 

 

 

 

 

 

 

 

 

 

 

 

출처: 스레드 종류가 참 많죠? 하드웨어 스레드, OS 스레드, 네이티브 스레드, 커널 스레드, 유저 스레드, 그린 스레드까지 한번에 정리해서 알려드립니다!! (youtube.com)