Process

프로세스는 실행중인 프로그램을 얘기한다. 즉 하드 디스크에 실행파일로 존재했던 프로그램이 메모리에 올라와 실행중인 상태가 되면 비로서 프로세스가 된다. 프로세스에는 프로세스 문맥이라는 것이 존재하는데 프로세스 문맥은 프로세스 수행 상태 정보를 담고 있다.
왜 프로세스 문맥은 프로세스 수행 상태를 담는지 의문이 들 수 있다. 우리는 컴퓨터를 사용할때 하나의 프로세스만 사용하게 된다면 CPU는 해당 프로세스만 전담해서 처리하면 되기에 프로세스 상태 정보가 필요 없을 수 있다. 하지만 현재 우리는 컴퓨터를 사용할때 여러 프로그램을 실행시켜 사용하기에 많은 프로세스가 메모리에 존재할 수 밖에 없다.
프로세스들은 CPU를 Time sharing하면서 CPU 점유하여 명령어를 수행하게 되는데, 프로세스가 다음 프로세스에게 CPU를 넘길때 프로세스 문맥을 저장하고 넘겨 받은 프로세스는 저장된 문맥 정보를 통해 다음 수행할 명령어를 바로 수행할 수 있게 된다.
프로세스 문맥은 크게 세가지로 나타낼 수 있다.

• 하드웨어 문맥
• 프로세스의 주소 공간
• 프로세스 관련 커널 자료구조

하드웨어 문맥은 프로세스가 명령어를 수행하기 위해서는 CPU를 점유해서 명령어를 수행하게 되는데 이때 프로세스 명령어가 어디까지 수행되었는지(Program Counter) 어떤 값을 담고 있는지(Register)가 필요하다. 이러한 정보를 담고 있는것이 하드웨어 문맥이다.
프로세스 주소 공간은 메모리와 관련된 부분으로써 프로세스의 Stack, Data, Code에 어떤 내용이 담겨있는지 알아야 프로세스 수행 상태를 정확히 나타낼 수 있다.
프로세스 관련 커널 자료구조는 운영체제가 프로세스들을 관리하면서 프로세스에게 CPU를 얼마나 할당시킬 것인지 메모리를 얼마나 줄 것인지 그리고 프로세스가 어떤 상태를 수행하고 있는지에 대해 알아야 할 필요가 있다. 프로세스를 관리하기 위해 PCB(Process Control Block)라는 자료구조를 두게되며 프로세스 별로 PCB가 존재하게 된다. Kernel Stack의 경우 프로세스가 System Call을 호출하여 Kernel의 함수를 수행 할때가 있다. 이때 PC는 프로세스 Code부분에서 Kernel의 Code 가리키며 Kernel의 함수를 수행하게 되는데 이러한 함수 수행정보를 프로세스 별로 Kernel Stack에 담게 된다.

Process State

• Running
  • 프로세스가 CPU를 점유하여 명령어 처리가 되는 상태
• Ready
  • CPU는 하나뿐이기에 하나의 프로세스가 CPU를 점유하고 있다면 다른 프로세스는 CPU를 점유하기 위해 대기상태로 존재한다. CPU는 디스크에 직접 접근은 할 수 없기에 당장 필요한 부분은 물리적인 메모리에 올라와 있어야 한다.
• Block(wait, sleep)
  • CPU 주어도 당장 명령어 처리를 할 수 없는 프로세스 상태를 얘기한다. 프로세스가 System Call을 통해 I/O 요청을 하게 되면 해당 요청이 즉시 처리되지 않기에 Block 상태가 된다. I/O 요청이 즉시 될 수 없는 이유는 알다싶이 CPU 처리 속도와 I/O 처리 속도는 수 없이 차이 나기에 프로세스가 I/O 요청을 한다고해서 CPU가 I/O처리 다 될때까지 기다리면 매우 비효율적일 것이다. 그렇기에 프로세스는 I/O 요청시 block 상태가 된다. 또 다른 대표적인 이유로 프로세스 정보는 물리적인 메모리에 다 올라가지 않는데 이때 만약 CPU가 물리적인 메모리에 존재하지 않는 Code를 실행하려 한다면 디스크로 부터 Code 정보를 읽어와야 하기에 block 상태가 된다.

이렇게 크게 세가지로 프로세스 상태를 나타내며 경우에 따라 위 그림 아래의 두가지를 덧 붙여 설명하기도 한다.

• New
  • 프로세스 생성중인 상태
• Terminated
  • 프로세스 명령어 수행이 끝난 상태

• New -> Ready
  • 프로세스가 생성되어 메모리에 프로세스 정보가 올라와 있는 상태. 즉 CPU 점유만 되면 명령어 처리될 수 있는 상태.
• Ready -> Running
  • 프로세스가 CPU 점유 차례가되어 명령어 처리하는 상태.
• Running -> Ready
  • 프로세스가 Timer에 의해 시간이 만료되어 Ready로 돌아가는 상태.
• Running -> Terminated
  • 프로세스 명령어 처리가 끝난 상태. 즉 더이상 수행할 것이 없는 상태를 얘기하며 Terminated 상택사 된다. 이때 Terminated 상태가 되어도 프로세스 정리하는 작업을 수행한다.
• Running -> Waiting
  • 키보드 입력이나 프로세스가 I/O event 발생시 wait 상태가 된다. (CPU가 I/O event 요청한 프로세스를 계속 점유해봤자 명령을 수행할 수 없어서.)
• Waiting -> Ready
  • 프로세스의 I/O 작업이 완료되면 Ready 상태로 돌아간다.

위 그림은 프로세스가 각 위치에 요청을 수행하기 위해 순차적으로 대기하는 것을 볼 수 있다. 물론 알기 쉽기 위해 순차적으로 프로세스가 대기하는것 처럼 설명되어 있으나 여러 알고리즘에 의해 우선순위가 바뀌어 처리 순서가 바뀌기도 한다. 각 Queue의 경우 하드웨어 별로 존재하는 Queue상태가 아닌 운영체제 Data 영역에 자료구조로 존재하는 Queue라 이해하면 된다.
Ready Queue에 프로세스가 CPU점유를 위해 대기하는 것을 볼 수 있으며 CPU에서 프로세스가 명령어를 수행하다 Timer가 끝나면 다시 Ready Queue로 돌아가 CPU 점유를 대기하게 된다.
다른 경우로는 CPU에서 명령어 수행중인 프로세스가 I/O 요청을 하게 된다면 해당 프로세스는 요청한 I/O queue로 이동하게 되며 block 상태가 된다. 해당 프로세스는 I/O Controller에 의해 요청이 순차 처리가 되며 처리가 완료되면 I/O Controller는 CPU에 Intrrupt를 걸어 요청 완료 됐다 알리게 된다. I/O 말고도 소프트웨어의 공유 데이터에 접근하려 할시 데이터 일관성을 보장하기 위해 block 상태로 두어 순차처리 하는 경우도 존재한다.

Context Swtich

문맥 교환(Context Switch)란 하나의 사용자 프로세스로 부터 다른 프로세스에게 CPU 제어권을 넘겨주는 과정을 말합니다.
CPU를 점유하여 명령어 처리 수행되던 프로세스가 Timer 및 I/O event에 의해 Inttrupt가 발생하게 되면 CPU의 제어권은 운영체제에 넘어가게 된다. 운영체제는 인터럽트 처리 루틴으로 가서 직전까지 수행하던 프로세스의 문맥을 저장하게 되며 CPU 제어권을 다른 프로세스에게 넘기게 된다.

문맥 정보에는 PC, Register, 메모리 맵등의 정보를 PCB에 저장하게 되며 CPU 제어권을 넘겨 받은 프로세스는 이전에 저장되어 있던 PCB안의 정보를 기반으로 하여 명령어를 수행하게 된다.

이때 우리가 알아야할 것은 System Call 이나 Hadware Intrrupt가 발생시 반드시 Context Switch가 발생하는 것은 아니다.

1번의 경우 프로세스가 명령어 처리 수행중 System Call을 요청해 운영체제의 함수를 실행하게 된다면 보통의 경우 CPU 제어권은 User Mode에서 Kernel Mode로 변경뒤 운영체제의 커널 함수 실행후 다시 같은 프로세스에게 제어권을 주게 된다. 이 경우는 같은 프로세스에게 제어권을 그대로 주기 때문에 문맥교환이 발생하지 않는다. 2번의 경우 Timer Intterupt나 I/O Intterupt가 발생했을 경우이다. Timer Intterupt는 수행중인 프로세스의 할당된 Timer가 만료되어 다른 프로세스에게 제어권을 넘겨줘야 할때는 문맥 교환이 발생한다. I/O Intterupt의 경우도 I/O 요청을 수행하기 위해서는 해당 프로세스 상태를 block으로 두고 다른 프로세스가 CPU 점유를 해야하기에 문맥교환이 발생한다.

1번의 경우 User Mode에서 System Call이 발생하여 Kernel Mode로 변경될때 해당 프로세스 Context 일부를 PCB에 저장한다. 하지만 2번과 같이 다른 프로세스에게 제어권을 넘겨주는 경우와 달리 그 과정에 대한 비용은 확연히 낮다. 2번의 경우 프로세스가 변경되는 것이기에 Cache memory flush가 필요하기 때문이다.

Process Scheduler Queue

• Job Queue
  • 현재 컴퓨터 구조에서 볼 수 있는 프로세스의 집합. (Ready Queue + Device Queue)
• Ready Queue
  • 현재 메모리에 있으면서 CPU 점유를 하기 위해 대기하는 프로세스의 집합.
• Device Queue
  • I/O Device의 처리를 기다리는 프로세스의 집합.

Scheduler

스케줄러는 각각의 자원 별로 어떤 일을 할지 순서를 정해주고 시간을 얼만큼 잡을지 정해주는 것 스케줄러의 역할이다. 지금 우리가 알아야 할 스케줄러는 크게 세가지다.

• Long-term scheduler (장기 스케줄러 or Job Scheduler)

  • 시작 프로세스 중 어떤 것을 Ready Queue로 보낼지 결정
  • 프로세스에 memory(및 각종 자원)을 주는 문제
  • degree of Multiprogramming을 제어
  • time sharing system에는 보통 장기 스케줄러가 없음.(무조건 ready)

• Short-term schduler (단기 스케줄러 or CPU scheduler)

  • 어떤 프로세스를 다음번에 running 시킬지 결정
  • 프로세스에 CPU를 주는 문제
  • 충분히 빨라야 함.(millisecond) 단위

• Medium-term scheduler (중기 스케줄러 or Swapper)

  • 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
  • 프로세스에게서 memory를 뺏는 문제
  • degree of multiprogramming을 제어

여기서 degree of multiprogramming이 무엇인가 궁금할 수 있다. degree of multiprogramming은 메모리에 프로그램을 얼마나 올릴 것인지를 얘기한다. 메모리에 프로그램을 적게 올려도 비효율적이고 많이 올려도 비효율적이기 때문에 이를 제어한다고 보면 된다.
왜 메모리에 프로그램을 적게 올리면 비효율적일까? 메모리에 올라온 프로그램이 I/O 요청이 들어와 block 상태가 된다면 운영체제는 메모리에 올라온 ready 상태에 있는 프로세스에게 CPU 제어권을 넘겨줘야 하는데 메모리에 올라와 있는 즉 ready queue에 프로세스가 없어 CPU 제어권을 넘겨줄 수 없게되어 CPU는 놀 수 밖에 없다.
반대로 메모리에 많은 프로그램이 올라오면 왜 비효율적일까? 많은 프로그램이 올라올 수록 각 프로그램마다 할당된 메모리양은 적을것이다. 그렇기에 CPU는 해당 프로그램의 코드를 읽다가 분명 메모리에 없는 코드들이 많기에 매번 디스크에서 읽는 것이 빈번하게 발생하여 비효율적인 상태가 된다. 그렇기에 degree of multiprogramming을 제어하는 것은 중요한 역할이다.

Process State With Suspended

위 내용에서 Process State에 대한 설명을 이해했을거라 생각한다. 여기서 추가된 부분은 Suspended 부분이다. 외부 요인에 의해 프로세스가 메모리에서 디스크로 swap out된 상태를 얘기한다. Suspended는 결코 block 상태와 같지 않다. block 상태된 프로세스의 경우 event가 만족되면 ready 상태가 되지만 suspended는 외부에서 resume 해주어야 active 상태가 된다. suspended는 어떤 요인에 의해 발생하게 되는것일까??
사용자에 의해 의도적으로 중지 시켰을 때 그리고 메모리에 올라온 프로그램수를 조절하기 위해 Process Scheduler중 Medium-term scheduler에 의해 디스크로 swap out되었을때가 있다. 이렇게 해서 추가적인 프로세스 상태인 Suspended까지 알게 됐다.

참조

• 운영체제 - 반효경 교수님