[OS] Process Description and Control III (Process State Models)

Intro

앞서서 Process Control Information에 Process의 State가 들어간다고 언급했다. 이 State는 Process가 어떤 상태에 있는지 알려주는 것이다. 예를 들어 Processor가 1개인데 처리해야 하는 Process가 다수라면, Process는 Uni-Programming을 하고 있다면 하나의 Process만 처리할 수 있기에 나머지 Process는 대기하거나 Block되어야 한다. 이 State를 정의해주는 것이 Process State Model이다. 우리는 가장 간단한 Two State Process Model부터 Five, Seven까지 순차적으로 알아볼 것이다. 

Two State Process Model

가장 단순한 Processing Model이다. 이는 정말 단순히 Process가 Execute되고 있는지, 아닌지만 판별한다. Processor에 Dispatch되면 Running State로, Pause되면 Not-Running State로 변화하게 된다. 물론 지금 가정하고 있는 것은 Processor가 하나일때를 가정하고 것이다. 아래의 그림은 단순하게 State로 나타낸 것이고 그 다음 그림은 실제 Queue로 구현되어 Process들이 기다리게 되는 상태를 그린 그림이다. Process는 Enter하게 되어 먼저 대기 Queue에 들어가게 된다. 이때 Process의 State는 Not Running이다. Scheduling Algorithm에 의해 Process가 Dispatch되면 Running State로 바뀌게 되고, Processor는 해당 Process를 처리하게 된다. 만약 이 Process가 Timeout, I/O Request 등으로 인해 Interrupt가 발생하게 된다면 다시 Queue로 돌아가게 되며, 처리가 다 끝난 경우에만 Exit한다. 

Processor가 처리할 수 있는 Process의 수를 N, Not Running, 즉 대기 Queue에 있는 Process들의 수를 M이라고 하자. 극단적으로 N <<<< M이면, 이는 매우 비효율적으로 동작할 것이다. Queue의 자료구조는 FIFO의 형태를 띄우고 있기 때문에 대기 Queue가 기하급수적으로 커질 수 있다. 또한 중요한 문제점 중 하나는 Process A, B가 있는데 A는 Timeout되어 정상적으로 Queue에 들어가서 다시 Dispatch될 수 있지만 B는 I/O Request가 와서 기다려야 한다고 하자. B는 해당 Response가 와야 다시 실행할 수 있지만 Queue에서 B를 Dispatch가 일어나게 된다면 해당 Process는 아직 Executable하지 않다. 즉 Process B의 수행을 보장할 수 없다는 것이다. 따라서 Scheduler가 해당 Event 발생 전에 Dispatch하게 된다면 수행이 불가능 하다. 

Five State Process Model

따라서 Two State Model의 개선안으로 나온것이 바로 Five State Process Model이다. Process가 Enter되면 Ready, Block, Running 이 세 상태 중 하나의 State를 가지게 된다. New Process가 Admit되면 Ready 상태로 간 후 Scheduler가 Running상태로 Dispatch하게 된다. 이때 Running 상태에서 Timeout되면 Ready상태로 돌아가게 된다. 즉 다시 Ready Queue에 들어가 Scheduler에게 선택받을 준비를 하면 된다. 그러나 Sys Call Interrupt, 즉 I/O Operation, event 등이 발생하면 Block상태로 들어가게 된다. Block 상태에서는 Blocked Status를 해제할 수 있는 event가 발생할 때까지 대기하며, 만약 해당 event가 발생해야 다시 Ready Queue에 Ready 상태로 들어갈 수 있다. 

Suspended Processes

Seven State Model에 들어가기 앞서서 Suspended Process를 위한 Swapping 기법을 이해해야 한다. 

출처: http://www.ezclean.info/tip/1486

가령 이와같은 에러를 본적이 있는가? 이 에러가 뜨는 이유는 Program을 너무 많이 실행해서 가상 메모리의 공간이 부족하거나 진짜 메모리의 가역공간이 부족해서 뜨는 에러이다. Process가 너무 많이 메모리에 올라가서 메모리의 가역공간이 부족한 경우가 몇몇 있다고 한다. 따라서 메모리에 공간을 확보하기 위해 OS는 Disk로 Process를 Kick Out하게된다. 이때 Kick Out된 Process를 Suspended 상태에 있다고 한다. Kick Out 말고도 Swap Out이라는 용어를 사용하기도 한다. Kick Out하는 상황은 두 가지 정도가 있는데 주로 Blocked상태에 있는 Process들을 내보낸다. 해당 Event가 언제 발생할지 모르기때문에 주로 Kick Out한다. 또한 Priority에 따라서 Running State의 Process나 Ready Queue의 낮을 Priority를 가진 Process들 역시 Suspended 상태로 쫓겨져 나갈 수 있다. 물론 이 기준은 OS마다 어떤 기준을 책정했는지에 따라서 다르다. Suspended 상태 역시 Ready Suspended, Blocked Suspended로 나뉜다. 이를 Blocked/Suspended, Ready/Suspended라고 지칭하기 하는데 맥락만 통한다면 어떤 용어를 사용해도 상관이 없다. 

Seven State Process Model

따라서 Seven State Process Model은 Five State Model에 Suspended Status를 달아놓은 것이다. Suspended Status를 잘 이해 했다면 그림만 봐도 충분히 이해가 가능할 것이다. 점선으로 그려진 부분은 예외적인 상황이긴 한데 잘 일어나지는 않는다고 한다. 

Process List Structures

이렇게 Process들은 적절한 List에 들어가서 Running되기를 기대한다. 사실 OS에게 가장 중요한 것은 Running State, 즉 current process가 가장 중요하다. PCB에는 *current_process인 포인터가 존재한다. 또한 Kernel에서는 Scheduling을 위해 Ready State를 관리해야 한다. Next State의 Condition을 위해서 누구를 선택할 것인지 결정해야 한다. LINUX에서는 List 자료구조로 관리가 된다. 물론 OS마다 이를 관리하는 형태는 다르다. 또한 거의 모든 컴퓨터는 Interrupt Driven System을 사용하고 있기 때문에 Blocked 상태 역시 중요하다. 다양한 이벤트들과 핸들러를 처리하고 기다리를 집합이기 때문이다. 따라서 OS 자체로서는 Ready, Running, Blocked상태가 제일 중요하다. 

Reference

William Stallings. (2018). Operating Systems: Internals and Design Principles (8th Edition): Pearson.