홀수인 경우 조금 더 경쟁이 치열하다
그래서 time_to_eat의 약 3배 정도의 time_to_sleep 시간이 필요한데,
철학자 수가 199, time_to_eat이 200이게 되면 최소 time_to_sleep이 600은 되어야 철학자가 생존 가능하다.
그러면 위와 같은 상황에서는 철학자가 600ms 경에 죽어야 하는데, 내 코드의 경우에는 계속해서 죽지않고 코드가 살아있는 것을 확인했다.
출력되는 time_stamp만 봐도, context switching으로 인해 스레드의 실행 타이밍이 밀리고 있는 것이 현저하게 보이는데 철학자가 죽지 않고 계속 프로그램이 진행된다는 것은 monitoring에서 철학자가 죽었다는 사실을 인지하지 못했기 때문이라고 생각했다.
-
5 599 200 200
-
61 599 200 200
위와 같이 철학자가 적은 경우에는 600ms 에 정상적으로 철학자가 죽고, 프로그램이 종료되는 것으로 보아 철학자가 많아지게 되는 경우 context switching으로 인하여 문제가 발생하는 것으로 보인다
시행착오
- monitoring script sleep하기
- 오히려 좋지 않은 방법
- monitor같은 경우에는 재우지 않고 계속 반복해서 체크를 진행해주어야 함.
- usleep이 끝나고 ready queue에 들어갔을 때, 대기 시간이 길어지게 되면 원하는 타이밍에 철학자의 죽음 여부를 확인할 수 없게 되기 때문
- yeju님의 조언 -> 데이터 레이스 때문에 제대로 체크가 안되는 것일 수도 있다.
fsanitize=pthread -g 옵션을 줘서 컴파일을 하면 data race를 체크할 수 있음
해당 옵션으로 컴파일을 하고 프로그램을 실행해보니 data race warning이 굉장히 많이 출력되었음.
이 에러문구들을 하나씩 체크해보는데,
- routine에서 last_eat time을 갱신하는 부분
- monitor에서 현재 시각과 last_eat time 시간을 비교하여 죽어야 하는 지 체크하는 부분
이 두 코드에서 data race가 발생한다는 문구가 반복됨을 확인하였다.
코드를 처음 짤 때 까지는 data race가 두 스레드에서 각각 데이터를 업데이트하려고 하는 상황에 정말 동시에 업데이트를 하게 되면 두 데이터가 모두 반영되지 않는? 상황에 국한되어서만 생각했는데, (write와 write)
(read와 write)의 경우에도 data race가 충분히 일어날 수 있다는 것을 깨닫게 되었다.
read와 write 중 어떤 것이 먼저 일어나는 지 여부에 따라서 프로그램의 결과가 달라지기 때문
philosopher 프로그램에서도 read를 먼저해서 철학자가 죽었음을 인지해야하는데, 죽었다고 인지를 하려고 read하는 순간 동시에 철학자가 밥을 먹어버리면 context switch 순서에 따라서 어떨 때는 죽고, 어떨 때는 살 수 있게 되는 것@!!!!
이 부분을 해결하면 될 듯 하다 ㅎㅎ
🦋 Philosophers repo address
https://github.com/kyj93790/42-cursus/tree/master/Philosophers
