쓰레드들은 쓰레드 스케줄러에 의해 CPU 자원을 할당 받는다.
CPU 자원을 할당 받아서 실행중이면 Running 상태이며 CPU 자원을 다른 쓰레드에게 뺏기면 Blocked 상태가 된다.
스케줄러에 의해 CPU 자원이 다른 쓰레드로 이동 할때마다 Context Switching이 발생한다.
잠시간의 대기를 위해 쓰레드에 Sleep을 주는 경우가 있는데 이때는 CPU 자원을 반납하고 Blocked 상태로 빠진다.
Sleep 대신 Spin을 거는 경우도 있는데 이는 Blocked가 아닌 Running 상태로 대기를 하게 된다.
불필요하게 CPU 자원을 소모하는것 같아 나쁜것 같지만 잠깐 대기 후 작업을 이어나갈때는 Sleep으로 Context Switching을 발생 시키는 것 보다는 Spin으로 Context Switching을 발생하지 않도록 하는것이 성능면에서 좋다고 생각 하는 것이다.
Spin Lock이라는 개념 역시 마찬가지이다.
개인적으로 Spin 을 이용하여 성능을 개선할 경험이 없어서 유용하다고 권하지는 못하겠다.
주의할 점은 Spin 이라고 하여서 무조건 CPU 자원을 독점 하는 것이 아니며 다른 쓰레드에게 CPU 소유권을 넘긴다. 대신 넘기고 나서는 Block 상태가 아닌 Ready 상태가 되어 바로 다음 CPU 점유를 받을 준비를 한다.
그래서 우선 순위가 높은 다른 쓰레드가 있을 경우에는 CPU 점유를 많이 할 수 없다.
위 코드에서 Spin이 아닌 Sleep으로 처리 하였다면 출력을 공평하게 나누어 하였을 것이다. 둘다 10초씩 준다면 정확하게 10초 쉬고 출력을 하게 된다. 이는 쓰레드 스케줄러가 쓰레드 우선 순위와 상관 없이 보장 할 것이다. 하지만 시간으로 대기를 하는게 아닌 Spin을 통해서 대기를 하면 for 10000 10000 을 할때 몇시간 동안 이 코드를 실행할 지는 오직 쓰레드 스케줄러 재량이다 따라서 쓰레드 우선순위에 따라 어떤 쓰레드의 for 10000 10000를 빨리 처리 할지는 결정한 쓰레드 스케줄러의 결정이 출력 빈도를 통해 나타나게 된다.
위 코드에서는 프로세스 우선 순위를 조절 하였는데 결국 우선 순위 높은 프로세스의 쓰레드에서 많은 CPU 자원 할당을 받을 수 있다.
프로세스 우선 순위를 변경 하는것이 아닌 쓰레드 우선 순위를 변경하는 API 역시 있다.
