이번주 FK 트러블 슈팅이다

그 FK 약자 아니고 𝑭𝒊𝒙 𝑲𝒆𝒚의 약자다

아무튼, 트러블 슈팅 해야 하는데

안타깝게도 기억이 흐릿해져 세세한거랑 우선순위 쪽은 잘 기억 안난다

그렇기에 mlfqs의 기억이 흐릿해지기 전에 관련 트러블 적기 시작한다

첫번째 트러블

전역 함수 선언하고 하는 거랑

그 기능 뽑아서 쓰는 거 결과가 다름…

동작은 무조건 똑같은 간단한 로직

원소 리스트에서 제거 후 정렬 삽입 ```c /* 통과한 케이스 */ if (th->status == THREAD_READY) { list_remove(&th->elem); list_insert_ordered(&ready_list, &th->elem, prio_greater, NULL); }

/* 실패 케이스 */ resort_ready_if_ready(th); // 이걸 위에껄로 대체하면 통과됨

// resort 어쩌구 함수 void resort_ready_if_ready (struct thread *t) { if (t->status == THREAD_READY) { list_remove (&t->elem); list_insert_ordered (&ready_list, &t->elem, prio_greater, NULL); } } ```

보다시피 로직 똑같다

3줄 밖에 안되는데 다를 수가 없다

처음에는 컴파일러가 전역 함수 싫어해서 그런건가 했는데

그건 아니고

인터럽트 비활성화가 없다 보니까

중간에 끼어들 수도 있는데

바로 붙여서 쓰는 거랑 전역함수 불러서 쓰는거랑 약간의 차이가 있어서

그 사이에 인터럽트가 끼는 경우가 전역함수 부를떄가 더 많아 발생하는 거였다…

그렇다.

사실상 사람의 눈으로는 보고 파악하기 매우 어려운,

인터럽트까지 실시간으로 계산해가며 시뮬하는 두뇌를 가져야만 바로 알 수 있는 상당히 골때리는 문제였다

이거 땜에 통과못하다 속도 높일겸 저리 바꾸니 통과되었는데…

ㄹㅇ 소 뒷걸음질치다 쥐잡은 격으로 통과된 사례였다…

취소 그거 문제 아니다

thread_tick 함수는 타이머 인터럽트 핸들러가 호출한다

즉, 인터럽트 컨텍스트에서 실행되기에 처음부터 인터럽트 off인 상태다

그럼 뭐가 문제냐?

진짜 호출이 문제였다

매 틱마다 실시간 계산이 중요한 지금 같은 경우에 함수 호출을 쓸 경우 실행시간이 늘어나고 이에 따라 오차가 더욱 늘어나는 문제였다

그렇기에 호출 대신 인라인 코드가 오차가 적어 통과되었고 말이다

어지간해서는 이렇게 짜도 문제 없었지만

매 틱, 4틱마다, 매 초마다 계산한다는 특이성 때문에 생긴 이슈였다

문제를 알았기에 해결은 금방했다

시간이 중요한 거 기에 중첩되는 거 삭제하고

전역 변수로 선언해 쓰던 것들 inline 붙여서 속도 저하 없앴다

두번째 트러블

mlfqs 부등 소수점 계산하고

스레드 현재인지 어디인지 확인하고

어디 리스트의 누군지 검사하고

이것저것 잔뜩 하느라 애먹었다

정수랑 부동소수점 잘못 섞으면 자꾸 죽어서 어려운데

코드도 더럽게 짜놔서 고문이 따로 없었다

다시 봐도 더러워서 전역함수 가지고 이쁘게 단장해주었다

위의 문제와 연계해서 전역 함수들 빼낸 거 앞에 inline붙여 속도와 가독성 모두 챙겼다 emoji

세번째 트러블

우선순위 스케줄링 하며 생긴

수많은 트러블 중 유독 기억이 남아 적는 트러블이다

사소하지만 중한 실수 였는데

thread_create()에서 만들고 우선순위 해놓고

즉시 재선점 로직 안넣어서 다른 거 다 만들고 수정하고 해도

테스트는 늘 fail이었다

심기일전 하여 천천히 코드 적어가며 흐름 정리하다가 겨우 발견했다;;

어디 오류 뜨거나 어디 코드에서 문제인지만 알았어도 하루는 커녕 10분안에 해결될 문제였다

확실히 이제부터는 디버깅 까지 고려해 printf()같은 함수 적극 채용 고려해야겠다

적을라면 더 적겠지만

일단 이 3개가 인상깊어서 적었다

사실, 실제 코드 이슈는 하나 정도고 두 개는 그냥 코딩 방식에 관한 이슈라 볼 수 있다