stride 구현에 앞서 어떻게 동작하는건지 정리해봤다.

• 모든 프로세스는 각자의 '보폭(stride)'을 가진다.
• 스케쥴러가 프로세스를 실행시키면 해당 프로세스는 'stride'만큼의 '거리(pass)'를 이동한다.
• 스케쥴러는 항상 가장 '짧은 거리를 이동한(pass가 가장 작은)' 프로세스를 실행시킨다.
• 결과적으로 보폭이 작을수록 더 자주 실행된다.

몇가지 고려해야 할 것들이 떠올랐다.

• stride로 바뀌면 lottery와는 달리 더 자주 실행되어야 할 프로세스에 작은 값을 부여해야한다. 사용자 입장에서 좋은 방식인가?
• 신규 프로세스 실행 비율에 대한 공정성이 지켜지는지?
• pass가 누적되면 overflow 될 가능성은 없나?
• 가장 작은 pass를 찾는 효율적인 방법

그리고 다음과 같이 결정했다.

• 우선순위를 정하는 API인 setticket은 그대로 유지하자.
• tickets의 반비례되는 수인 stride를 만들기 위해 max_tickets(교재의 L)를 정한다.
  • stride = L / tickets
• 신규 프로세스에는 현재 실행중인 프로세스중에서 가장 작은 pass를 부여하여 공정성을 유지한다.
• pass를 uin64로 지정하고 max_tickets를 2^32로만 잡아도 최대 42.9억번 정도의 tick이 지나야 overflow가 발생한다. 지금은 고려하지 말자.
• 초기 구현은 선형탐색으로 단순하게 구현하고 이후 최적화를 하자.