- 좌절
- 스레드와 함께 필요한 동기화를 끼워 넣다 보면 성능 향상이 반드시 보장되는건 아님
- 시스템 부하나 하드웨어 구성에 따라 최적의 스레드 수가 달라지기 때문에 신뢰성 있게 스레드 관리 매우 어려움
- 그불구! 대부분의 동시적 애플리케이션은 다중 스레드를 채용
- 또한 이들 스레드가 작성된 프밍 언어 그대로 동작 안함;
- 런타임 환경은 이들 프밍 언어 구조를 실제 스레드에 배정해야됨
- 이런 과정 구현하는데 프레임워크와 프밍 언어에서 채용되는 패턴이 바로 스레드 풀(thread pool)
- 이름에 나오지만
- 프로그램 실행 시 상당 시간 활용될 워커 스레드를 정해진 수만큼 만들어서 풀에 담아두는 패턴
- 장점
- 스레드 재사용으로 스레드 생성, 종료 오버헤드 줄임
- 예기치 않은 작업 실패(예외 발생 등)가 스레드에 미치는 영향도 줄임
- 스레드 생성보다 수행 시간 짧은 작업이라면 이 재사용효과 극대화
- 시나리오
- 패스워드 후보 집합 잘게 나누어 서로 다른 스레드에 배정
- 이거 하려면 백그라운드에서 동작하며 작업을 만들어낸는 주 스레드가 필요
- 이렇게 백그라운드에서 동작하는 주 스레드와 워커 스레드의 통신 구현하려면 스레드 간의 연결처럼 동작하는 저장 수단 필요!
- 스레드간 통신 HOW?
- 메시지 큐
- 작업 목록이 담긴 메시지 큐 있고
- 풀에 담긴 스레드가 이 메시지 큐에서 작업을 하나씩 꺼내 동시적으로 처리
- 스레드 풀은 대부분의 동시적 애플리케이션에서 가정 고려할 만한 기법
- 단, 다음의 몇가지 상황에선 풀 대신 직접 관리하는게 나음
- 스레드에 여러 기준을 가진 우선순위 적용해야 할 상황
- 스레드가 오랫동안 블록 상태에 놓이는 상황
- 대부분 스레드 풀 구현은 최대 스레드 제한이 있기에 블록 상태의 스레드 너무 많아지면 새로운 작업 못함
- 스레드에 정적으로 지정한 식별자 부여해야 할 상황
- 특정 작업을 전담 시킬 스레드 따로 지정해야 할 상황