[OS] Threads, Concurrency

Concurrency, Parallelism

1 코어 단일 CPU에 4개의 스레드가 있다고 가정하자.

동시성은 4개의 스레드가 하나의 코어에 서로 interleaved 하면서 모든 작업이 진행되도록 하는 것이다.

병렬성은 1코어가 아닌 멀티코어라 생각하고, 여러개의 스레드가 동시에 실행되도록 하는 것 이다.

 

그러므로 병렬성을 가지지 않으면서 동시성을 가지는 것이 가능하다. (실제로 이전 싱글 프로세스 시절에는 병렬성을 가진것 처럼 보이는 동시성 프로그래밍이었다.)

 

Types of Parallelism

data parallelism -> 데이터를 여러개의 코어로 나눠 작업하도록 하는 것. (arr[N]의 합을 구할때 1번 코어에 [0:N/2], 2번 코어에 [N/2:N]을 주어 병렬적으로 합을 구하는거같은거)

task parallelism -> task, 즉 실행 단위인 thread를 여러개의 코어에 나누는 것.

data parallelism과 task parallelism은 상호 배타적이지 않다.

 

 

Multithreading Models

User threads -> user level에서 생성된 스레드

kernel threads -> kernel level에서 생성된 스레드

 

Many to One Model

 

여러개의 user threads 관리가 user space의 thread library에 의해 관리되기 때문에 효율적이지만, 동시의 하나의 스레드만 kernel에 접근할 수 있기 때문에, 멀티코어 시스템에서 병렬성을 가질 수 없다.

 

One to One Model

더 나은 동시성과, 병렬성을 가질 수 있지만 하나의 user thread에 대한 kernel thread가 무조건 생성됨에 따른 overhead가 있다.

Linux, Windows OS 가 one - to - one으로 되어있다.

 

Many to Many Model (and Two-level model)

User-level threads보다 더 적은 수의 kernel threads를 가진다.

상기에 서술한 두 모델과는 달리, 사용자는 user threads를 필요한 만큼 만들 수 있고, 그에 따른 kernel threads가 늘어남에 따른 overhead를 느끼지 않는다. 또한 kernel thread가 여러개 있기 때문에 병렬성도 가질 수 있다.

응용으로 Many to Many에 특정 user thread를 kernel thread와 대응시킬 수 있다. 이 모델은 Two-level model이라 불린다.

 

구현이 어렵고, kernel threads의 수를 정해놔야 한다는 점에서(제한된 kernel thread를 가짐) 현대 OS는 one to one 모델을 더 많이 사용하고 있다.

 

Implicit Threading

스레드의 생성 및 책임/관리를 프로그래머가 하는것이 아닌 컴파일러, 런타임 라이브러리에 넘겨주는 것 이다.

 

Thread Pools

Web server를 예시로, 요청이 들어오면 새로운 thread를 생성해서 이에 따른 응답을 만든다. 하지만 이러한 스레드 관리 기법은 여러가지 잠재적 문제가 있다.

 

1. thread 생성 시간 문제

2. thread 수 증가에 따른 성능저하

 

Thread Pool은 정해진 수의 스레드를 대기시켜두고, 요청이 들어왔을때 새로운 스레드를 만드는 대신 thread pool에 요청을 보내 이를 처리하도록 하는 것 이다.

Thread pool에 요청이 가면 대기중인 스레드가 요청을 즉시 처리하고, 만약 대기중인 스레드가 없다면 대기 스레드가 생길 때 까지 요청을 queued 한다.

 

Thread Pool을 사용한다면

1. 스레드 생성 시간을 없앤다. 고로 더 빨라진다.

2. 동시 가능 스레드수가 적은 시스템이 원활하게 작동할 수 있도록 한다.

3. task 별로 다른 전략으로 실행할 수 있도록 한다.

 

 

추후 작성...

 

 

Threading Issues

multithreading-program을 design할때 생기는 문제에 대해 알아보자.

 

Fork() and exec() System Call

fork

fork 는 프로세스를 복제하는 시스템 콜인데, 부모 프로세스가 다중 스레드 프로세스인 경우 모든 스레드를 복제할 것인지에 대한 문제가 발생한다. 이에 따라서 유닉스 시스템에서는 두가지 버전에 fork를 사용할 수 있다.

 

1. 모든 스레드를 복제하는 fork

부모 프로세스의 모든 스레드가 자식 프로세스로 복제된다. 

이 방법은 다중 스레드 간 메모리, FD, 락을 공유하기 때문에 제대로 복제되지 않는 경우 동작이 불명확해지며, 다중 스레드 프로세스 특성상 동기화 문제가 발생할 우려가 더욱 커진다는 점에서 현대 시스템에서 잘 사용하지 않는다.

 

2. fork() 호출 스레드만 복제. (단일 스레드 복사)

자식 프로세스는 부모 프로세스의 상태 중 호출 스레드의 상태만을 가지고 새로운 독립적인 프로세스로 실행된다.

 

상기에 서술한 내용을 exec()와 결합해서 살펴보자.

exec()는 새로운 프로세스로 현재 프로세스를 덮어 쓴다. 그러므로 fork()후에 exec()를 바로 사용하는 패턴을 가지면 모든 스레드를 복제할 필요 자체가 없어진다.

그러므로 fork() 이후 exec()를 바로 사용하지 않는 경우는 모든 스레드를 복제하는 것이 좋으며, 아니면 단일 스레드 복사를 하는 것이 좋다. (왠만하면 fork()이후 exec()를 사용하므로 단일 스레드 복사는 사용을 잘 안한다고 한다.)

 

Signal Handling

시그널은

1. 특정 이벤트에 의해 생성

2. 프로세스로 전달

3. 전달된다면, 시그널에 따른 행동을 해야만 한다

라는 과정을 거친다. 그리고 시그널은 동기적/비동기 시그널로 나뉜다.

 

Synchronous signal

Out of bound, Segfault, division by zero와 같은 시그널은 synchronous signal이다.

 

Asynchronous signal

실행중인 프로세스 외부에서 이벤트가 발생할 경우 프로세스는 시그널은 비동기적으로 받는다.

Ctrl C, time expired와 같은 경우가 있다.

 

그리고 이러한 시그널은 기본 핸들러, 사용자 생성 핸들러에 의해 프로세스 내에서 처리가 된다.

 

하지만 프로세스가 다중 스레드로 구성되어 있다면, 어디에 시그널이 전달되어야 하는 지가 쟁점이 된다.

 

동기 시그널의 경우는 시그널이 발생한 주체가 된 스레드에 전달하면된다.

하지만 비동기 시그널의 경우 전달해야할 스레드가 분명하지 않다.

그러므로 시그널 처리 방식이 존재한다.

 

시그널 처리 방식

1. 스레드별 시그널 마스크

각 스레드는 자신의 시그널 마스크를 가지고 있고, 어떤 시그널을 처리할지 또는 무시할지 결정하는 역할을 한다. 이를 통해 특정 스레드에서만 시그널을 처리하도록 제어한다.

 

2. 시그널을 처리할 스레드의 선택규칙.

 

2-1. 시그널이 전달될 수 있는 스레드중 한 스레드.

 

2-2. 프로세스 전체 시그널

프로세스에 전달되는 시그널일 경우, 각 스레드는 시그널을 수신할 자격이 있으며 시그널 마스크가 허용하는 스레드가 시그널을 처리하게 된다.

 

2-3. 스레드 전용 시그널

pthread_kill() 과 같은 함수로 특정 스레드에만 시그널을 보낼 수 있다.

 

시그널 처리의 문제점

 

시그널 처리를 통해서는 두가지 문제점이 발생할 수 있다.

1. 동기화 문제

시그널 도착 시점에 따라 시그널을 처리하는 스레드와 다른 스레드 간 동기화 문제가 발생할 수 있다. 

 

2. 스레드 안전성

특정 함수(malloc(), ~~~)는 스레드 안전성을 보장하지 않으므로, 시그널 핸들러에서 호출할 경우 문제가 발생할 수 있다.

 

 

 

Thread Cancellation

종료 될 스레드는 target thread라 불리고, 두개의 시나리오에 따른다

1. Asynchronous cancellation : target thread를 즉시 종료한다

2. Deferred cancellation : target thread가 스스로 종료할 수 있도록 스스로 주기적으로 체크한다.

 

1. 과 같이 즉시 종료할 경우, 할당되어있는 메모리를 반환하지 못하는 문제가 생길 수 있다. 스스로 체크하고 종료할 수 있는 2. 와 같은 경우에는 이러한 문제가 발생하지 않는다.

 

Thread-Local Storage

프로세스에 딸린 스레드는 프로세스의 데이터를 공유하지만, 몇가지 상황에서는 스레드 각각에 데이터를 가지고 있어야 하는 경우가 발생한다.

예를 들어 transaction-processing system에서, 분리된 스레드가 각각의 다른 transaction을 처리해야되는 경우가 생긴다. 그리고 각각의 transaction은 식별자가 있어야 한다. 이런경우에 Thread local storage를 사용할 수 있다.

 

스레드 내 지역변수와 헷갈릴 수 있는데, 지역변수는 오직 하나의 함수 처리 흐름에만 할당/제거 되는 데이터이다. TLS는 함수처리와 상관 없이 특정 스레드 내의 모든 흐름에 사용할 수 있다.