sleep(0)와 sleep(1)의 차이점

Sleep(0)의 경우, 다른 Thread가 ready to run 되었다고 해서 자신이 쥐고 있던 CPU의 선점을 풀지 않습니다. 선점을 풀려면 조건이 있는데 그 ready to run 인 Thread가 지금 선점한 Thread와 우선순위가 equal이어야 한다고 하네요.

즉, 우선순위가 서로 같아야 A Thread에서 B Thread로 CPU사용주체가 넘어간다고 합니다.

 

그와 반대로 Sleep(1)의 경우, 그런 Thread간 우선순위 상관없이 다른 Thread가 ready to run 상태에 있다면 그 Thread를 위해 자신이 쥐고 있던 CPU를 놔주게 됩니다. 그럼 목적한 것처럼 A Thread에서 B Thread로 switching이 이뤄지겠죠.

 

 

명시적으로 context switch 를 발생시키려면...
SwitchToThread() 함수를 호출하면 되겠습니다.

 

Sleep은 남은쓰레드와 자신을 포함해 스레드 스케쥴링을 하고 SwitchToThread는 자신을 제외한 상태에서 스레드 스케쥴링을 합니다. Sleep은 인자로 넣은 시간동안 스케쥴링 되지 않게 하면서 자신의 현재 남은 퀀텀타임을 무효화 하기 때문에 만일 퀀텀타임이 짧으면서 엄청 빠른 머신에서는 그만큼 스케쥴링 되지 않는 문제가 생깁니다.

따라서, 프로그래머가 의도한 대로 Sleep 보다는 SwitchToThread를 써주는게 좋습니다.

 

 

1. Sleep(0)은 현재 ready 상태로 전환된 스레드중에 자신과 priority가 같은 thread가 없으면 스위칭 과정을 거지치 않고 그냥 Sleep(0)을 호출했던 스레드가 계속 진행(running)됩니다. Sleep(0)이 호출되는 시점에서 자기 자신보다 priority가 높은 ready 상태가 되어 있는 스레드가 존재 해도 그놈이 실행되지는 않습니다. 이 과정에서 스레드 스위칭은 없다고 봐야 겠죠.

2. 반면에 Sleep(n)은 자신 스레드가 아직 가지고 있는 남아 있는 time slice를 포기하겠다는 의미이고, OS에게 권한이 무조건 넘어 갑니다. ready 상태 thread가 한개도 없다고 하면 OS는 빈둥빈둥 태스크(Idle Process)한테 실행을 넘깁니다.

2번에서 OS가 다음에 실행될 스레드는 무엇인가를 결정하는 데 있어서는 이는 굉장히 골치가 아픕니다. thread priority가 높은 놈한테만 실행권한을 주면 priority가 낮은 놈은 한번도 실행되지 못하는 불상사가 발생하기 때문에 OS가 이를 적당히 조절을 해 주게 됩니다(불쌍한 놈한테도 가끔씩 떡고물 나눠 주기). 그런데 정확히 어떤 thread한테 실행권한이 넘어 가느냐 하는 것은 OS의 정책에 따라 다르며 Application차원에서는 추측하기가 힘듭니다. 아무튼 starvation 문제는 OS가 알아서 해 주려니...하고 믿을 수 밖에 없습니다.

1번도 마찬가지입니다. 같은 prority를 가지고 있는 다른 ready thread 들중에 과연 어떤 놈이 실행될 것이냐? 이것도 OS 마음대로입니다.

또 다른 얘기가 있는데 바로 특수한 thread입니다. 바로 priority가 TIME_CRITICAL한 thread인에, 이 thread가 block 상태에서 ready 상태로 전환이 되면, 전환이 되는 즉시 OS는 현재 running 상태의 스레드의 실행을 바로 뺏어서(time slice가 얼마 남아 있는지 상관없이) TIME_CRITICAL thread에게 권한을 넘겨 줍니다.

얘기가 좀 길어 졌는데, thread를 여러개 만들고 각각 thread의 우선 순위를 대충 설정한 다음에 threadProc 코드 중간중간에 Sleep 을 넣고 그 앞단과 뒷단에서 TRACE를 걸어 보면 확인할 수 있습니다

 

 

sleep(0)은 같은 우선순위의 쓰레드 끼리의 컨텍스트 스위칭!
sleep(1)은 같은 우선순위에 상관없이 전체 쓰레드 끼리의 컨텍스트 스위칭!