---
# System prepended metadata

title: Untitled

---

## 암묵적 스레딩



멀티코어 프로세싱이 지속적으로 성장하면서 수백, 수천개에 달할 정도로 아주 많은 스레드들을 포함하는 애플리케이션들이 등장하고 있다. 이런 애플리케이션을 설계하는 것은 여간 힘든 일이 아니다. 섹션 4.2에 나왔던 문제점(뭔지 찾아봐야함) 뿐만 아니라, 다른 문제들도 해결해야 한다. 이는 프로그램 정확성(correctness - 어떻게 번역되는지?)과 관련돼있는데, 이는 챕터 6과 챕터 8에서 살펴본다.

이런 문제들을 다루고 애플리케이션의 동시성과 병렬성에 더 나은 지원을 해주기 위한 방법중 하나는 생성과 관리를 개발자에서 컴파일러와 런타임 라이브러리로 옮기는 것이다. 이런 전략을 암묵적 스레딩(implicit threading)이라 부른다. 이는 점점 인기가 많아지는 추세다. 암묵적 스레딩의 전략으로 크게 네 가지가 있다. 이 전략들은 보통 개발자에게 태스크(task, 스레드가 아니다)를 구현하게 하고 해당 태스크를 병렬적으로 실행시키는 것이다. 태스크는 보통 함수로 만들어지는데 이는 런타임 라이브러리에서 스레드로 매핑해준다. 보통 섹션 4.3에서 살펴봤던 many-to-many 모델을 사용한다. 이런 접근의 장점은 개발자가 병렬적으로 실행시킬 태스크만 정의해주면 된다는 점이고 라이브러리가 스레드 생성 및 관리에 대한 구체적인 상세내용들을 결정해준다는 것이다.



### 4.5.1 스레드풀

섹션 4.1에서 우리는 멀티스레드 웹 서버를 예로 들었다. 이런 상황에서 서버가 요청을 받을때마다 요청을 처리할 새로운 스레드를 생성한다. 여러개의 프로세스를 생성하는 것 보다 여러개의 스레드를 생성하는 것이 더 유리하지만 멀티 스레드 서버는 잠재적인 문제가 있다. 첫째로 스레드를 만드는데 시간이 걸리고, 해당 작업이 끝나면 스레드는 사라진다. 둘째로 각각의 동시 요청(concurrent request)을 새로운 스레드에서 처리할 경우 스레드가 끝없이 생성되고 시스템 자원을 고갈시킨다. 해결방법 중 하나는 스레드 풀을 사용하는 것이다.

스레드 풀의 기본적인 개념은 풀(pool)에 특정 개수의 스레드를 생성해놓고 작업을 위해 기다리도록 하는 것이다. 서버가 요청을 받으면 스레드를 만드는 대신 스레드 풀에 요청을 전달하고 다음 요청을 기다린다. 스레드 풀에 가용 스레드가 있으면 요청이 즉시 처리된다. 만약 가용 스레드가 없으면 빈 자리가 날 때 까지 큐에 대기한다. 스레드가 작업을 완료하면, 풀에 돌아간 뒤 다음 작업을 기다린다. 스레드 풀은 풀에 전달 된 작업이 비동기적으로 실행될 경우에 잘 동작한다.

스레드 풀의 장점

- 이미 존재하는 스레드를 사용하기때문에 새로 생성하는 것 보다 빠르다.
- 스레드 풀은 스레드 수를 제한한다. 시스템이 많은 수의 동시 스레드(concurrent threads)를 지원할 수 없을 경우 중요하다.
- 작업의 생성과 수행을 분리시키면 각 테스크마다 다른 실행 전략을 사용할 수 있다. 예를 들어, 어떤 작업은 특정 시간만큼 기다렸다 실행하고 어떤 작업은 즉시 실행할 수 있다.

스레드 풀의 스레드 개수는 cpu개수 메모리 용량, 예상 동시 요청 등을 기반으로 하여 휴리스틱 적으로 적용할 수 있다. 좀 더 복잡한 아키텍쳐에서는 사용 패턴에 따라 동적으로 조정할 수도 있다. 이러면 시스템의 로드율이 낮을 때는 더 작은 풀을 가져 메모리 소모를 줄인다. 이 중 하나는 애플의 GCD라는 건데 나중 세션에서 다룬다.

### 4.5.2 포크조인

4.4에서 살펴봤던 스레드 생성 전략은 흔히 포크-조인 모델이라 불리는 것이다. 메인 부모 스레드가 여러개의 자식 스레드를 생성(fork)하고 자식 스레드가 종료되길 기다렸다가 join하는 것이다. 이러한 동기적 모델은 보통 명시적 스레드 생성으로 특정되기는 하지만, 암묵적 스레딩의 훌륭한 후보이기도 하다. 후자의 상황에서 스레드들은 병렬 작업으로 지정되지, 포크 단계(fork stage?)에서 직접 구성되지 않는다. 이런 모델은 그림 4.16에 표현된다. 라이브러리는 여러개의 스레드를 관리한다. 또한 스레드 생성과 작업 할당의 책임도 가진다. 라이브러리가 실제 스레드 수를 결정한다는 점에서 포크-조인 모델은 스레드 풀의 동기적 버전으로 볼 수도 있다. 



### 4.5.3 OpenMP

OpenMP는 C, C 또는 FORTAN으로 작성된 프로그램의 API이자 컴파일러 명령어(directives)의 집합으로, 공유 메모리 환경에서 병렬 프로그래밍을 지원한다. OpenMP는 병렬로 실행 될 수 있는 코드 블록을 병렬 영역(parallel regions)으로 정의한다. 개발자는 컴파일러 명령어를 자신의 코드 내부에 있는 공유 병렬 영역에 삽입한다. 그리고 이러한 명령어는 OpenMP 런타임 라이브러리가 병렬 영역을 실행시키도록 지시한다.

OpenMP가 지시문을 만나면 프로세서 코어의 개수만큼 스레드를 생성한다. 듀얼코어면 두 개, 쿼드코어면 네개 와 같은 식으로. 모든 스레드는 동시에(simutaneously) 병렬 영역을 실행한다. 각 스레드가 병렬 영역을 벗어나면 종료된다.

OpenMP는 병렬 루프같은 추가적인 명령어를 지원한다. 이외에도 수동으로 스레드 개수를 조절한다던가, 데이터의 공유 여부를 설정할 수 있다. OpenMP는 리눅스 윈도우, 맥os를 위한 여러가지 오픈소스 및 상용 컴파일러에서 사용할 수 있다.

