[운영체제] 2-3. 프로세스 상태도

이번 글에서는 프로세스의 상태도 대표적인 5가지와, 추가적인 2가지까지 해서 총 7가지를 알아보겠습니다.

 

 

 

우선, 이전 글에서 첨부했던 사진을 다시 떠올려봅시다.

여기서 대표적으로 Not Running과 Running 상태를 나타냈었는데, 우선 먼저 Not Running의 세부 상태에 대해서 설명하겠습니다.

 

Not Running

Ready

- 실행되기를 기다리는 상태입니다. 뒤에 설명한 대기 큐에서 실행을 기다립니다

 

Blocked(= wait, sleep)

- 이벤트가 발생되기를 기다리는 상태입니다. 대표적으로 이 때, 사용자의 입력을 기다리는 상태를 Block이라고 할 수 있습니다.

 

대기큐(Ready Queue)라는 단어를 잠깐 꺼냈는데, dispatcher(이 개념은 전에 설명했습니다.)가 항상 대기 큐의 가장 위에 있는 프로세스를 선택하는 것은 아닙니다. 가령, blocked된 프로세스는 아직 이벤트가 발생하지 않았으므로 CPU에 할당되어도 작업을 진행할 수 없으므로, blocked인 상태는 dispatcher가 가려내고 ready인 상태의 프로세스만 CPU에 할당해줍니다.

 

-> 이 문구에 혼란이 있어 추가 설명을 드립니다. 추후에 Blocked Queue라는 개념을 배우겠지만, 아직 그러한 Block Queue가 없이 Ready Queue로만 구성된다면 이러한 문제점이 있다는 것을 시사한 것입니다.

 

 

 

5가지 프로세스 상태도

위 그림을 기준으로, 각 상태에 대한 설명을 해보겠습니다.

 

New

fork 명령어를 통해서, 새로운 프로세스가 create 됩니다. 이 때, 프로세스는 new 상태가 되어 프로세스 리스트에 들어가게 됩니다. 여기서 프로세스 리스트는 Job Queue라고도 불립니다.

 

만약 실행된 프로세스가 interactive 모드로 실행되었다면 바로 Admit되어서 Ready Queue에 들어가게 됩니다. 전에 설명했다시피 interactive 모드가 아닌(batch 모드) 프로세스는 CPU가 여유로울 때, Ready Queue로 가서 프로세스가 실행되게 됩니다.

 

 

Ready

여기에는 ready Queue가 존재하여 프로세스들이 순서대로 정렬됩니다. (이 때, Queue는 linkedlist로 구현되었기에, 가변으로 작동합니다.) 이후 프로세스 스케쥴러가 스케쥴링 정책에 따라 프로세스를 running으로 할당합니다. 이러한 과정을 Dispatch라고 합니다. 스케쥴링 정책은 나중에 다룹니다.

 

Running

프로세스가 CPU의 자원을 할당받아서 프로그램의 instruction을 수행하는 단계입니다. 만약 우리가 Time sharing 기법을 쓰고있다면, 한 프로세스당 정해진 time quantum만큼을 사용했을 때, Timeout이 되어 다시 Ready 상태가 되고, 마찬가지로 Ready Queue에 들어가게 됩니다.

 

Blocked

Not Running 부분에서 설명했던 상태입니다. 사용자의 입력을 기다리거나 하는 등의 특정 이벤트를 기다린다면, CPU가 이 이벤트가 발생하기까지 기다리는 것을 비효율적입니다. 따라서, Blocked 상태로 전환하여, 이벤트를 기다리게 됩니다.

 

만약, 이벤트가 발생하였다면, Ready 상태가 되고, Ready Queue에 들어가게 됩니다.

 

Terminated(Zombie)

프로세스가 끝났거나 kill, exit 등으로 프로세스가 종료되면 Terminated 상태가 됩니다. Zombie 라고도 부릅니다. 하지만 이렇게 종료되었다고 해서 프로세스가 메모리에서 아예 빠져나가는 것이 아닙니다. Zombie 프로세스는 자신이 얼만큼 자원을 사용했는지, 자신이 어떻게 종료됐는지 등의 정보를 가지고 있게 됩니다.

 

이 때, wait을 통해서 zombie 상태에서 가지고 있는 정보들을 모두 읽어왔다면 그 떄, 완전히 메모리 상에서 out되게 됩니다.

 

 

Single Blocked Queue vs. Multiple Blocked Queue

앞서 설명했던 blocked에 대해서 조금 더 다뤄봅시다. 우리는 이벤트가 발생하기를 기다리는 상태가 되면 blocked로 처리하고 이벤트가 발생할 때, ready Queue에 넣는다고 했습니다. 그렇다면 blocked 상태에서는 어떻게 프로세스를 관리하는 지 알아봅시다.

 

Single Blocked Queue

blocked 상태에서도 큐를 가지고 프로세스를 관리하게 됩니다. single blocked queue는 큐를 하나만 가지고 프로세스를 관리합니다. 만약 이렇게 된다면 각 기다리는 이벤트의 응답 시간이 다양한테, 효율적으로 처리할 수 없다는 단점이 있습니다.

Multiple Blocked Queue

이름에서도 알 수 있듯이 여러 개의 큐로 이벤트 wait를 관리합니다. 이 때, 이벤트의 종류마다 큐가 존재해서 이벤트마다 처리할 수 있도록 하게합니다.

Suspended Processes

방금 설명한 blocked 상태에 있는 이벤트들이 계속 발생하지 않는 경우에는 어떻게 될까요?? 위에서 말한 5가지 상태는 모두 메인 메모리에 있기 때문에, 메모리에 공간을 낭비하게 된다고 볼 수 있습니다.

 

앞서 말한 blocked 상태에 있는 프로세스들이 있는데, 메모리 공간이 부족해서 다른 프로세스가 들어오지 못한다거나, 메모리 위에 있는 모든 프로세스가 입출력을 기다릴 때는 blocked에 있는 프로세스를 suspended 상태로 만듭니다. suspended 상태는 메인 메모리에서 보조기억장치로 이동시킵니다.

 

우리는 메인 메모리에서 보조기억 장치로 옮기는 과정을 swap in, 보조기억장치에서 메인 메모리로 옮기는 과정을 swap out이라고 합니다.

 

기존에 사용했던 5가지 상태도에서 suspended 2개를 추가했습니다.

 

보시다시피, suspended 상태는 sleep과 ready로 나눕니다. 보조기억장치로 밀려난 프로세스는 suspended sleep은 이벤트를 기다리다가 이벤트가 발생했다면 suspended ready로 갑니다. 이 때, 만약 메모리가 여유롭다면 바로 ready 상태로 메인 메모리에 올라가게 되고, 만약 메모리가 포화상태라면 suspended ready에서 대기했다가, ready로 올라가게 됩니다.

 

 

Suspension 상태가 발생하는 이유

1. Swapping

   -> ready 상태인 프로세스를 실행하기 위한 메모리를 확보하기 위해 suspension 상태를 발생시킵니다.

 

2. Timing

   -> 소프트웨어 업데이트를 하루에 한번 서버에서 확인하는 프로세스와 같이 가끔 한 번씩 실행하는 프로그램들은 suspension 상태에

       있는 것이 메모리 측면에서 효율적일 것입니다.

 

3. Interactive user request

   -> 디버깅 모드와 같이, 사용자와 상호작용해야하는 과정에서는 강제로 suspension할 수 있습니다.