[OS] Mint64OS 20절 Process synchronization

이제 Task가 multilevel Queue 구조에 따라서 우선 순위가 결정되고 효율적으로 처리되는 것을 구현했는데, 다시 원론으로 돌아가 생각해볼 게 있다.

task를 수행하기 위해서는 시스템내의 resource를 점유한다. 그런데 이전 예제처럼 수백 수천개의 task가 수행될때 가끔 같은 resource를 사용해야 할 경우가 발생할 수 있을 것이다. 분명 자기 task를 수행하기 위해서 resource를 점유한 상태에서 다른 task의 요청을 받게 되면 어떻게 해야 되는지에 대해 고민할 필요가 있다. 물론 운이 좋게 resource를 넘겨줄 수 있을 수도 있겠지만, 운영체제 구동에 운을 개입시키기에는 너무 큰 개체다.

 이때 필요한 것이 Process synchronization( 동기화)라는 것이다. 즉 Resource의 사용에 있어서 규약을 정해놓자는 것이다. 간단히 말하자면 각각의 task가 톱니바퀴가 되어서 서로 톱니바퀴가 제대로 맞물릴때만 전체적으로 잘 동작하는 것을 추구하는 셈이다. 이전에 다룬 개념인 우선 순위를 적용하고난 다음의 task는 분명 우선 순위가 같은 task 들일 것이다. 딱히 우선 순위가 같은 것 들에 대한 규칙이 없기 때문에 같은 순위 task들끼리 한정된 resource를 사용하기 위해서 경쟁을 할 것이고, 이런 와중에는 꼭 거쳐야 할 과정을 그냥 넘어가는 경우가 발생할 수도 있다.

 이런 현상을 Race Condition이라고 하고,이런 현상을 막기 위한 방법 중 하나로 많은 task 들 중에서 하나만 resource를 점유하는 것을 보장한 방식인 Mutual Exclusion, 흔히 말하는 Mutex가 등장한다. 이걸 적용시키게 되면 코드 내부에는 Critical Section이란게 들어가서 관련 flag가 활성화됬을 때만 구동할 수 있는 구조로 형성되게 된다. 마치 이런 동작이 자물쇠와 비슷해서 인지 전체적인 동작도 Lock과 Unlock으로 구분하고 있다.이와 비슷한 개념 중에 semaphor 라는 것이 있는데 이에 대한 설명은 다른 블로그에 잘 되어 있는 듯 하다.

http://face.nmain.net/tc/202

책에서는 Mutex로 구현되어 있다.

 그런데 여기에도 맹점이 존재한다. 이렇게 Critical Section을 포함하는 task 2개가 동시에 동작할 때다. 앞에서 말한 것처럼 Critical Section은 해당 task에서 그 부분만 수행되는 부분인데 두개가 동시에 동작하면 서로가 Critical Section을 수행하기 위해서 필요한 Resource를 서로가 요구하는 순간이 발생하는 것이다. 이성적인 존재라면 양보라는 개념이 적용되어 Resource를 줄 수 있겠지만, 이 때는 서로가 원하는 걸 가지고 있으면서 자기것은 주지않으려는 task 이기 때문에 해결이 어렵다. 이같은 현상을 deadlock이라고 하며, 이때문에 Mutex와 같은 Synchronization 방법도 완벽한 답이 아니다. 그래서 꼭 필요한 순간에만 사용하고, 만약 동시에 수행해야 될 필요가 있으면 이에 대한 예외처리가 존재해야 된다.