thread
-
쓰레드의 개념
프로세스 : 운영체제로부터 자원을 할당받은 작업의 단위
스레드 : 프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위
즉, 스레드는 프로세서 활용의 기본 단위이다. -
스레드의 장점
자원을 공유하여 효율성과 경제성이 증가한다. 이때 context switching이 일어나는데 비용이 상당히 적다.
게임이 멀티스레드 프로세스라면 3개의 작업을 3개의 스레드로 각각 처리한다고 했을 때 일부 스레드가 block 되거나 wait 된다고 해도 다른 스레드는 계속해서 작업이 가능하다!
synchronization 동기화
멀티 프로세스 시스템에서 여러 프로세스(쓰레드)들이 같은 공유 자원을 사용할 때, 동시에 동일한 공유 자원에 접근하지 못하도록 하는 것
write와 read가 동시에 절대 수행될 수 없음!
- 동기화의 문제점
-
교착상태(Deadlock)
두 개 이상의 작업이 서로 상대방의 작업이 끝나기 만을 기다리고 있기 때문에 결과적으로 아무것도 완료되지 못하는 상태 -
기아(Starvation)
프로세스가 세마포터 큐에서 무한히 대기하는 상황 -
우선순위 역전(Priority inversion)
공유 자원에 대한 허가를 기다리는 동안, 낮은 우선순위 프로세스와 스케줄링 순서가 뒤바뀌는 상황
synchronization을 막는 방법
쓰레드 간 동기화를 하는 가장 단순한 방법은 한 쓰레드가 cpu를 사용할 때 일시적으로 cpu에 들어오는 인터럽트들을 막는 것이다.
"blocked" state vs "waiting" state
- "blocked" state : 차단된 상태
- "waiting" state : 대기 상태
Busy-wait vs Sleep-wakeup
일반적으론, CPU 소모를 줄일 수 있는 Block-Wakeup 방식을 사용
그러나 block-wakeup 방식은 오버헤드가 존재
따라서 critical section의 길이가 길면, block/wakeup이 적당
critical section 길이가 짧으면, busy-wait가 적당
cpu 스케줄링
- 수행 -> 대기 interrupt
- 수행 -> 준비 time-out
- 대기 -> 준비 wake-up
- 수행 -> 종료
Preemptive & Non-preemptive
preemptive : 선점형 스케줄링
Non-preemptive : 비선점형 스케줄링
-
선점형 스케줄링 (threads 에서 발생)
위의 결정 시점에서 1번~4번까지 모든 상황에서 발생 -
다른 프로세스에게 CPU 사용을 양보하게 되는 경우
- 어떤 프로세스가 실행되다 time slice를 모두 사용해 time-out 되는 경우
- IO가 발생하는 경우
- event를 기다려야하는 상황
- 이때 선점의 근거가 바로 우선순위이다.
FIFO vs Priority scheduling
- 스케줄링 알고리즘
: 준비 큐에 있는 프로세스 중 어느 프로세스에게 CPU를 할당 할 것 인지를 결정하는 문제
semaphore vs mutex
세마포어는 3가지 방식으로 이루어져 있다.
Semaphore(n)로 초기 설정을 한다. 이 때 n은 공유 가능한 자원의 수를 나타낸다.P()으로 임계구역에 들어가기 전에 사용중이라는 표시를 한다V()으로 임계구역에 나올 때 비었다고 표시한다.
- semaphore의 문제점
- busy-waiting 문제
프로세스가 락을 기다리는 동안 계속 순환됨
짧은 락을 기다리는 경우 문맥교환 비용을 절약할 수 있으나 일반적으로 CPU를 점유한 상태로 기다리므로 자원낭비
lock과 semaphore
lock
한 프로세스가 임계 영역에 해당하는 코드를 실행하고 있을 때 다른 프로세스가 임계 영역으로 진입하지 못하도록 하는 것
즉 하나의 공유자원에 여러 사용자가 접근하지 못하도록 lock을 설정하는 것
semaphore
동기화 도구로써, lock에 접근할 때 체계적으로 접근하기 위해 사용하는 도구
condition variable
동기화 도구 중 하나로 세마포어나 락보다 더 높은 레벨의 동기화이다.
어떤 실행 상태가 원하는 것과 다를 때 조건이 참이 되기를 기다리며 쓰레드가 대기할 수 있는 큐이다.
💡 Condvar는 공유 자원을 사용할 때까지 계속 loop를 도는 Busy waiting 방식을 개선하기 위해 등장
<aside>
💡 해 등장했다.
</aside>
```c
//pseudocode
while(!queue.empty())
{
sleep(1);
}Busy waiting 방식을 사용하면 매번 CPU가 체크해주어야 한다. 만약 그냥 잠들어 있고, 누군가가 준비가 되면 일어나라고 신호를 보내 주면 어떨까?
- busy-waiting 방식
//pseudocode
syncVar.lock.acquire();
while(!queue.empty())
{
syncVar.wait();
}- condvar 방식( wait()부분)
//pseudocode
syncVar.lock.acquire();
while(!queue.empty())
{
syncVar.wait();
}
//do stuff with queue
syncVar.lock.release();다른 스레드가 Queue를 비워주고 있다고 해 보자. 다 비워졌을 때 syncVar.signal()을 호출해 wait()에서 잠들어 있는 임의의 스레드를 깨워줄 수 있다.
Priority Inversion Problem
우선 순위가 높은 스레드가 우선순위가 낮은 스레드를 기다리는 현상
해결책
- Priority donation
- Multiple donation
- Nested donation
-
Priority donation
높은 우선순위를 가진 thread가 낮은 우선순위의 thread에게 우선순위 기부
-
Multiple donation
Priority donation이 여러번 발생한 경우
- Nested donation
마치 체인처럼 연결되어 우선순위를 기부하는 경우
ref) https://www.educative.io/answers/blocked-state-vs-waiting-state-of-a-thread
https://nostressdev.tistory.com/18
https://umbum.dev/60
https://velog.io/@dongvelop/%EC%8A%A4%EC%BC%80%EC%A4%84%EB%A7%81-%EC%95%8C%EA%B3%A0%EB%A6%AC%EC%A6%98
https://woonys.tistory.com/entry/PintOS-Project-123-Priority-Inversion-59%EC%9D%BC%EC%B0%A8
https://gyumgyum2.tistory.com/31
