[Dae-Hwa]: os 4.5~4.5.3

Author: Dae-Hwa

OS/Ch04-Threads&Concurrency.md

@@ -235,3 +235,56 @@ Pthread는 스레드 생성 및 동기화를 위한 API를 정의하는 POSIX 
 -> 메모리 관점보다는 논리적인 관점에서 보는게 맞을 거 같다.
 
 </details>
+
+> ### THE JVM AND THE HOST OPERATING SYSTEM
+>
+> JVM은 보통 host OS 위에 구현된다. 이러한 설정은 JVM이 아래에 있는 OS 구현을 숨기고, JVM만 지원된다면 어떤 플랫폼에서든 Java프로그램을 실행할 수 있는 일관성 있고 추상화된 환경을 제공해준다. JVM의 사양(specification)은 Java의 스레드가 아래에 있는 OS와 어떻게 매핑할지 정하지 않고, 각 구현체에서 결정한다. 예를 들어 윈도우 OS는 one-to-one 모델을 사용한다. 따라서 윈도우 환경에서 돌아가는 JVM은 각 스레드를 커널 스레드와 매핑시킨다. 또한, Java 스레드 라이브러리와 host OS 사이에도 관계가 있을 것이다. 예를 들어, 윈도우 패밀리 OS에서는 Java 스레드를 만들 때 윈도우 API를 사용할 것이고, 리눅스나 맥OS에서는 PthreadAPI를 사용할 것이다.
+
+
+
+## 4.5 Implicit Threading
+
+멀티코어 프로세싱이 발전하면서 수백, 수천 개에 달할 정도로 아주 많은 스레드를 포함하는 애플리케이션들이 등장하고 있다. 이런 애플리케이션을 설계하는 것은 여간 힘든 일이 아니다. [섹션 4.2에 나왔던 문제점](#421-programming-challenges) 뿐만 아니라, 다른 문제들도 해결해야 한다. 이는 프로그램 정확성(correctness)과 관련돼있는데, 나중에 챕터 6과 챕터 8에서 살펴볼 것이다.
+
+이런 문제들을 다루고 애플리케이션의 동시성과 병렬성에 더 나은 지원을 해주기 위한 방법 중 하나는, 생성과 관리를 애플리케이션 개발자가 하는 대신, 컴파일러와 런타임 라이브러리가 하도록 하는 것이다. 이런 전략을 암묵적 스레딩(implicit threading)이라 부르며, 점점 인기가 많아지는 추세다. 암묵적 스레딩의 전략으로 크게 다섯 가지가 있다.
+
+- Thread Pools
+- Fork Join
+- OpenMP
+- Grand Central Dispatch
+- Intel Threading Building Blocks
+
+위 전략들은 보통 개발자에게 태스크(task)를 구현하게 하고 해당 태스크를 병렬적으로 실행시키는 것이다. 태스크는 보통 함수로 만들어지는데 이는 런타임 라이브러리에서 스레드로 매핑해준다. 보통 섹션 4.3에서 살펴봤던 many-to-many 모델을 사용한다. 이런 접근의 장점은 개발자가 병렬적으로 실행시킬 태스크만 정의해주면 된다는 점이고 라이브러리가 스레드 생성 및 관리에 대한 구체적인 상세내용들을 결정해준다는 것이다.
+
+
+
+### 4.5.1 Thread Pools
+
+섹션 4.1에서 우리는 멀티스레드 웹 서버를 예로 들었다(책에는 있는데 내용이 없는듯?). 이런 상황에서 서버가 요청을 받을 때마다 요청을 처리할 새로운 스레드를 생성한다. 여러 개의 프로세스를 생성하는 것보다 여러 개의 스레드를 생성하는 것이 더 유리하지만, 멀티 스레드 서버는 잠재적인 문제가 있다. 첫째로 스레드를 만드는 데 시간이 걸리고, 해당 작업이 끝나면 스레드는 사라진다. 둘째로 각각의 동시 요청(concurrent request)을 새로운 스레드에서 처리하면 스레드가 끝없이 생성되고 시스템 자원이 고갈될 수 있다. 해결 방법 중 하나는 스레드 풀을 사용하는 것이다.
+
+스레드 풀의 기본적인 개념은 풀(pool)에 특정 개수의 스레드를 생성해놓고 작업을 위해 기다리도록 하는 것이다. 서버가 요청을 받으면 스레드를 만드는 대신 스레드 풀에 요청을 전달하고 다음 요청을 기다린다. 스레드 풀에 가용 스레드가 있으면 요청이 즉시 처리된다. 만약 가용 스레드가 없으면 빈자리가 날 때까지 큐에 대기한다. 스레드가 작업을 완료하면, 풀에 돌아간 뒤 다음 작업을 기다린다. 스레드 풀은 풀에 전달된 작업이 비동기적으로 실행될 때 잘 동작한다.
+
+스레드 풀의 장점
+
+- 이미 존재하는 스레드를 사용하기 때문에 새로 생성하는 것보다 빠르다.
+- 스레드 풀은 스레드 수를 제한한다. 시스템이 많은 수의 동시 스레드(concurrent threads)를 지원할 수 없을 때 중요하다.
+- 작업의 생성과 수행을 분리시키면 각 태스크마다 다른 실행 전략을 사용할 수 있다. 예를 들어, 어떤 작업은 특정 시간만큼 기다렸다 실행하고 어떤 작업은 즉시 실행할 수 있다.
+
+스레드 풀의 스레드 개수는 cpu개수 메모리 용량, 예상 동시 요청 등을 기반으로 하여 휴리스틱 적으로 적용할 수 있다. 좀 더 복잡한 아키텍처에서는 사용 패턴에 따라 동적으로 조정할 수도 있다. 이러면 시스템의 로드율이 낮을 때는 더 작은 풀을 가져 메모리 소모를 줄인다. 이 중 하나는 애플의 GCD라는 건데 나중 세션에서 다룬다.
+
+### 4.5.2 Fork Join
+
+4.4에서 살펴봤던 스레드 생성 전략은 흔히 포크-조인 모델이라 불리는 것이다. 메인 부모 스레드가 여러 개의 자식 스레드를 생성(fork)하고 자식 스레드가 종료되길 기다렸다가 join하는 것이다. 이러한 동기적 모델은 보통 명시적 스레드 생성으로 특정되기는 하지만, 암묵적 스레딩의 훌륭한 후보이기도 하다. 후자의 상황에서는 아래의 그림처럼 스레드들은 병렬 작업으로 지정되고, 포크 단계(fork stage)에서 직접 구성되지 않는다. 라이브러리는 여러 개의 스레드를 관리한다. 또한 스레드 생성과 작업 할당의 책임도 가진다. 라이브러리가 실제 스레드 수를 결정한다는 점에서 포크-조인 모델은 스레드 풀의 동기적 버전으로 볼 수도 있다. 
+
+![fork-join-1](https://user-images.githubusercontent.com/24666330/125182291-d344f800-e247-11eb-995a-fbb7ff7125c9.png)
+
+![fork-join-2](https://user-images.githubusercontent.com/24666330/125182325-1a32ed80-e248-11eb-9dad-56f2269f9046.png)
+
+### 4.5.3 OpenMP
+
+OpenMP는 C, C 또는 FORTAN으로 작성된 프로그램의 API이자 컴파일러 지시어(directives)의 집합으로, 공유 메모리 환경에서 병렬 프로그래밍을 지원한다. OpenMP는 병렬로 실행될 수 있는 코드 블록을 병렬 영역(parallel regions)으로 정의한다. 개발자는 컴파일러 지시어를 자신의 코드 내부에 있는 공유 병렬 영역에 삽입한다. 그리고 이러한 명령어는 OpenMP 런타임 라이브러리가 병렬 영역을 실행시키도록 지시한다.
+
+OpenMP가 지시문을 만나면 프로세서 코어의 개수만큼 스레드를 생성한다. 듀얼코어면 두 개, 쿼드코어면 네 개 와 같은 식으로. 모든 스레드는 동시에(simutaneously) 병렬 영역을 실행한다. 각 스레드가 병렬 영역을 벗어나면 종료된다.
+
+OpenMP는 병렬 루프 같은 추가적인 명령어를 지원한다. 이외에도 수동으로 스레드 개수를 조절한다던가, 데이터의 공유 여부를 설정할 수 있다. OpenMP는 리눅스 윈도우, 맥os를 위한 여러 가지 오픈소스 및 상용 컴파일러에서 사용할 수 있다.
+