잠시 짬을 내어서 김광태님께서 보여주신 application에 대해 생각을 해보았습니다.
다음과 같은 문제가 발생할수 있을것 같습니다.


- ISR에서 interrupt 처리를 위해 handler task를 ready 상태로 만들어버릴수 있다.
- 그렇게 되지 않는다면 interrupt 처리 task가 수행되지 못해 interrupt 관련 문제가 생길수 있다.
- Multi-core에서는 다른 core에서 event를 발생 시켜버릴수 있다.
++ 각 core의 ready queue가 틀릴때 한쪽 core에 있는 task만 처리했을 경우
++ 두 core를 동시에 정지 못시키고 suspend 상태로 만들 경우
- Multi-core에서 다른 core에서 어떠한 task가 interrupt disable 상태에서 spin lock 안에 spin을 돌고 있을 경우에는 어떻게 처리할것인가??? (다른 core를 멈추게 하는 방법에 따라 이것도 문제가 있을수 있을듯)


모두를 한꺼번에 빼고 넣는다는 걸 가정하고
일단 지금 생각 나는것은 이정도인것 같습니다.
2가지 문제로 요약될것 같습니다.

- interrupt 처리와 관련된 문제
- multi-core와 관련된 문제


OS를 만드는데 있어서 정말 심각하게 고민해봐야 되는 문제중에 하나가
suspend state를 넣느냐 마냐 입니다.


전제 :
"OS는 한치의 모호성도 용납 안되며 발생할수 있는 모든 가능성에 대해 정해진 순서대로 동작해야 한다."


완벽하게 동작하는 OS에 있어서 suspend state는 전혀 필요하지 않습니다.
미리 정해진 순서에 따라 동작하는 OS 내부에 있어서 suspend state는
그 자체로써 예외를 만들어 OS 내부의 state를 모호하게 바꾸어 버릴수 있습니다.

특히나 suspend state를 user가 변경 가능하게 제공된다면
심각한 위험성을 내포하고 있는거나 마찬가지입니다.

윈도우즈에서 user가 suspend state로 변경 가능한지 모르겠는데
그걸 떠나 전 윈도우즈에 왜 suspend state가 들어가 있는지 잘 모르겠네요.

어떻게 발생할수 있는 여러 문제들을 땜빵으로 넘어간다고 할지라도
잠재된 모든 문제들을 파악하고 해결하는건 무척 어려울것 같습니다.