이야 하루에 TIL 4개????

아주 죽어보자~

알람시계 alarm-priority 통과 실패 한거 통과하게 코드 고칠거다

집 가고 싶다 우우…

emoji2

알람 시계

priority, 즉, 우선순위를 고려해줘야 한다

필요없는 놈보다 당장 급한애들 먼저 처리하는게 핵심이다

원래 이건 내일하고 집가려 했는데

으윽…

뭐부터 해야 하나…

GitBook 읽어보니 알람 클락에서 해결될 문제가 아닌 것 같다

우선순위 스케줄링까지 손대야 한다는 뜻 말이다

그러니 그냥 이에 대해서 정리하겠다

오늘 정리하고 대강 흐름 생각하다 보면

내일은 무난하게 구현할 거 같으니 말이다

emoji2

우선순위 스케줄링 (Priority Scheduling)

실행 준비 리스트(ready list)에 현재 실행 중인 스레드보다 더 높은 우선순위 스레드 추가시

현재 스레드는 바로 프로세스 양보(yield) 해야한다

블록되어 있다가 꺠어난 애들도 예외 없다

스레드 우선 순위 범위는 PRI_MIN(0) ~ PRI_MAX(63) 로 작을수록 낮은 우선순위다

높을수록 중요하다

초기 우선순위는 별 이유 없으면 PRI_DEFAULT(31) 쓰란다

threads/threads.h에 정의되어 있으며 값 변경 X

우선순위 역전과 기부 (Priority Inversion & Donation)

우선순위 역전(priority inversion) 이 문제다

그게 뭐냐?

lock이라는 자원에 접근 하는데 제한 거는 방식이 있는데 이는 한번에 하나만 접근 가능하다

누가 접근하려면 다른 누군가가 먼저 내려놔야 한다는 말이다

이때 문제 발생한다

가장 낮은 우선순위의 스레드가 이에 접근 가능하고

가장 높은 우선순위 스레드가 이에 접근하려해

낮은 스레드가 락을 내려놓아야 하는데

현재 실행 중 스레드가 그 중간의 우선 순위라

낮은 스레드가 접근 불가하게 되어

높은 스레드도 같이 발이 묶이는 상황을 말한다

이 끔찍한 상황을 막기 위해 우선순위 기부가 필요한 것이다

높은 우선순위 스레드가 낮은 스레드한테 우선순위 기부하고

낮은 스레드가 락을 해제한다 (이후 높은 스레드가 락 획듹)

그리고 다시 기부한거 회수해간다

그렇다.

줬다 뺏기다.

이러한 우선순위 기부 할 때 모든 상황 고려하란다

다중 기부 (여러 스레드의 우선순위가 하나의 스레드에 기부되는 경우)
중첩 기부 (높은게 중간 놈 락 기다리고 중간이 낮은 놈 락 기다릴때. 중간, 낮은 놈 둘다 높은 우선순위가 되어야함)
중첩 길이에 제한(예: 8단계) 둘 수 있음

우선순위 관련 함수 (API)

thread/thread.c에 뼈대 있으니 스레드가 자신의 우선순위 확인·변경할 수 있게 해주란다

void thread_set_priority (int new_priority);

현재 스레드의 우선순위를 new_priority로 설정

이 변경으로 인해 더 이상 우선순위가 최고가 아니게 되면 바로 양보

int thread_get_priority (void);

현재 스레드의 우선순위 반환

기부의 영향도 반영해서 우선순위 반환해야한다

…

일단 리스트에 넣고 뺴는 거 같은거 우선순위에 따라 정렬하게 하고

그 다음에 기부 구현해야 할 거 같다

그냥 우선순위 구현 자체는 그리 안어려울 거 같은데

기부 하는게 아마 난관일 듯 싶다

오늘은 그럼…