<프로세스의 개념>
1. 프로세스란
실행 중인 프로그램을 뜻한다.
2. 프로세스의 문맥
프로세스가 실행이 시작되면, 프로세스만의 독자적인 주소 공간을 형성한다. 이 프로세스가 CPU를 얻게 되면 PC(Program Counter)라는 레지스터가 이 프로세스의 code 어느 한 부분을 가리키게 되고, 매 순간 instruction을 하나씩 읽어서 CPU 안으로 불러들인다.
레지스터에 어떤 값을 넣은 뒤 ALU(산술논리 연산장치)에서 어떤 연산을 하고 그 결과를 레지스터에 저장하거나 바깥의 메모리에 저장하는 과정이 발생한다.
이 과정이 반복되는 중, 어느 시점에 프로세스가 어디까지 와 있는가를 규명하는데 필요한 요소를 '프로세스의 문맥' 이라 한다.
이러한 프로세스의 문맥을 나타내기 위해서는 Program Counter가 어디를 가리키고 있는가, 즉 code의 어느 부분까지 실행했는가를 알아야 하며, 이 프로세스의 메모리에 어떤 내용을 담고 있는가를 알아야 하고, 프로그램이 실행되면서 레지스터에 어떤 값을 넣어놓고 어떤 instruction까지 실행했는가를 모두 알아야 한다.
프로세스의 문맥은 크게 3가지로 설명할 수 있다.
1. CPU와 관련된 하드웨어 문맥
현재 시점의 프로세스가 instruction을 어디까지 실행했는가를 알기 위해서 레지스터에 지금 어떤 값을 넣고 있었는지와 Program Counter가 어디를 가리키고 있었는지를 알아야 한다.
2. 메모리와 관련된 프로세스 주소 공간
현재 시점의 프로세스의 주소 공간에 어떤 내용이 들어있는가를 알아야 한다.
3. 프로세스 관련 커널 자료구조
운영체제는 지금 돌아가고 있는 프로세스들을 관리하는 역할을 하고 있다.
프로세스가 하나 실행될 때마다 운영체제는 그 프로세스를 관리하기 위해서 자신의 data 영역에 PCB라는 자료구조를 두고 있다. 그래서 이 PCB에게 CPU나 메모리를 얼마나 줘야 할지 등을 관리한다.
각 프로세스가 자신의 code를 실행 중일 때는 만약 함수 호출이 이루어진다면 본인의 stack에 함수를 호출하고 return 해서 관련된 정보를 쌓아놓는다.
근데 프로세스가 실행이 되다가 본인이 할 수 없는 일을 운영체제한테 대신해달라고 요청을 할 수 있는데(System Call), 이때 Program Counter가 커널 주소 공간의 code 부분 어딘가를 가르키며 커널의 code를 실행한다. 커널도 함수들로 구성이 되어 있으므로 커널에서 함수 호출이 이루어지면 stack에 또 다시 관련된 정보를 쌓아놓는다.
그런데 커널이란 여러 프로세스들이 공유하는 code라고 말할 수 있다. 따라서 이 때 커널이 누구의 부탁을 받고 실행하는지가 매 번 다를 수밖에 없다. 그러므로 stack에 정보를 쌓을 때 프로세스 별로 stack을 별도로 두어야 한다.
결론적으로, 프로세스의 현재 상태를 규명하기 위해서는 커널 stack의 정보 또한 알아야 한다.
위 3가지 정보를 가지고 있다면, 프로세스가 현재 어떤 상태에 있는지 정확히 규명할 수 있다.
3. 프로세스의 문맥을 알아야 하는 이유
현대의 컴퓨터 시스템은 time sharing, multi tasking을 하며 프로세스들이 번갈아 실행이 되기 때문에 하나의 프로세스가 CPU를 잡고 실행을 하다가, CPU를 놓고 다른 프로세스에게 CPU가 넘어간다.
그러면 현재 프로세스가 CPU의 레지스터 값에 어떤 것을 넣고 실행하고 있었다고 할 때, 이 내용을 백업해놓지 않으면(프로세스의 문맥을 알고 있지 않으면) 다음번 CPU를 잡았을 때 앞부분부터 다시 실행해야 하므로 프로세스의 문맥을 아는 것은 중요하다.
<프로세스의 상태>
컴퓨터의 CPU는 하나뿐이다.
그러므로 CPU를 잡고 있는 프로세스 또한 매 순간 하나뿐이다.
이러한 프로세스는 크게 5개의 상태로 구분할 수 있다.
1. Running
지금 CPU를 잡고 instruction을 실행하고 있는 프로세스의 상태.
2. Ready
CPU가 하나이기에 여러 프로세스들이 CPU를 기다리고 있는 상태.
이때, 프로세스는 다른 모든 준비가 끝나 있으며 CPU만 얻으면 바로 instruction을 실행할 수 있는 상태이다.
3. Blocked (wait, sleep)
CPU를 줘도 instruction을 실행하지 못하는 상태.
예를 들어 오래 걸리는 I/O 작업을 하고 있거나, 디스크에서 무언가 읽어 와야 하는데 그 읽어 온 내용을 다 보고 나서야 다음 instruction을 실행할 수 있거나, 어떤 프로그램의 code를 실행하려 했는데 이 부분이 메모리에 올라와 있지 않고 디스크에 내려가 있는 프로세스들이 Blocked 된 상태이다.
4. New
프로세스가 생성 중인 상태.
5. Terminated
프로세스가 할 일(execution)을 마치고 종료되고 있는 상태.
이미 종료된 프로세스는 더 이상 프로세스가 아니다.
<Process Control Block(PCB)>
PCB는 운영체제가 각 프로세스를 관리하기 위해 프로세스당 유지하는 정보를 담는 자료구조이다.
PCB는 총 4개의 구성 요소를 갖는다.
1) OS가 관리상 사용하는 정보
- Process state, Process ID, scheduling information, priority(CPU 우선순위 값을 유지하기 위한 것들)가 포함된다.
2) CPU 수행 관련 하드웨어 값
- 프로세스의 문맥을 표시하기 위한 정보들
- Program counter, registers가 포함된다.
3) 메모리 관련
- code, data, stack의 위치 정보가 포함된다.
4) 파일 관련
<문맥 교환(Context Switch)>
- CPU를 뺏겼다가 나중에 다시 얻으면 처음부터 실행하는 것이 아닌, 뺏기던 시점의 문맥을 기억했다가 그 시점부터 실행할 수 있게 한다.
프로세스가 CPU 제어권을 뺏기면 CPU의 레지스터에 저장되어 있던 값과 Program Counter 값, memory map을 PCB에 저장해둔다.
System Call(프로세스가 본인이 필요해서 운영체제에게 무언가를 요청)이나 Interrupt(누군가 CPU한테 정보를 전달하기 위한 목적) 발생 시 CPU 제어권이 사용자 프로세스로부터 운영체제 커널에게로 넘어간다.
이때, 반드시 문맥 교환이 일어나는 것이 아니다.
System Call이나 Interrupt가 발생한 이후에 운영체제가 CPU를 다른 프로세스에게 넘겨주는 경우에 문맥 교환이 일어난다.
위 사진은 두 가지 예시를 나타내고 있다.
(1) 프로세스 A가 실행 중에 본인이 system call을 발생시켰거나 외부에서 interrupt가 들어왔을 때 CPU 제어권이 운영체제에게 넘어간다. 그러면 운영체제는 interrupt가 들어온 경우엔 interrupt service routine을, system call이 들어온 경우엔 관련된 커널 함수를 실행한다. 이후에 문맥 교환 없이 다시 user mode로 복귀한다.
(2) 프로세스 A가 실행 중에 timer interrupt(CPU를 다른 프로세스에게 넘기기 위한 의도를 가진 interrupt)가 들어오거나, 시간이 오래 걸리는 I/O 요청이 들어오면 운영체제 커널은 또 다른 프로세스에게 CPU를 넘기기 때문에 이 경우엔 문맥 교환이 일어난다.
<프로세스를 스케줄링하기 위한 큐>
프로세스를 스케줄링 하기 위한 큐는 총 3가지가 있다.
1) Job queue
: 현재 시스템에 있는 모든 프로세스를 유지하고 있는 queue
2) Ready queue
: CPU를 기다리기 위한 queue
3) Device queue
: I/O 디바이스마다 서비스를 기다리면서 줄 서 있는 queue
프로그램이 시작되면 먼저 ready queue에 와서 줄을 선다. 자기 차례가 되면 CPU를 얻고, CPU를 얻은 상황에서 본인의 할당 시간이 끝나면 다시 ready queue의 뒤에 와서 줄을 선다. 또다시 CPU를 얻어서 오래 걸리는 작업(I/O 요청)을 수행하면, 해당 작업의 queue에서 줄을 서 있다가 그 작업이 끝나면 다시 ready queue로 간다. 그러다 본인의 역할이 모두 끝나면 종료가 돼서 빠져나간다.
interrupt가 걸린 상태에서는 정확히 말하면 ready queue로 다시 넘어가는 것은 아니다.
<스케줄러>
- 각각의 자원별로 해야 하는 일들을 정하는 것
1) 단기 스케줄러 (= CPU scheduler)
- millisecond 단위
- 다음번에 어떤 프로세스에게 CPU를 줄지 결정한다.
2) 장기 스케줄러 (= Job scheduler)
- 어떤 프로세스에게 메모리를 줄 지 결정한다.
- 시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정한다.
- degree of multiprogramming(메모리 위에 올라가 있는 프로세스의 수)을 제어한다.
- time sharing system(우리가 현재 사용하는 시스템)에는 장기 스케줄러가 없다.
3) 중기 스케줄러 (= Swapper)
- 장기 스케줄러는 프로그램이 시작될 때 메모리를 줄지 말지 결정하는데, 현재의 시스템들은 모두 시작함과 동시에 메모리를 준다. 그렇기 때문에 메모리에 동시에 너무 많은 프로그램들이 올라가 있으면 문제가 되므로 중기 스케줄러가 사용된다.
- 중기 스케줄러는 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄으로써 degree of multiprogramming을 제어한다. 즉, 시스템의 성능이 좋아진다.
- 중기 스케줄러가 생김으로서 프로세스의 상태가 한 가지 더 추가된다.
- Suspended(Stopped) 상태 : 외부적인 이유로 프로세스의 수행이 정지된 상태
* Blocked 상태와 Suspended 상태의 차이
- Blocked : 자신이 요청한 일을 하면서 오래 기다리고 있는 상태
- Suspended : 외부에서 정지시켜놓은 상태
* 본 글은 이화여자대학교 반효경 교수님 강의와 '운영체제와 정보기술의 원리(반효경 지음)' 서적에 기반하여 작성하였습니다.
'Computer Science > OS' 카테고리의 다른 글
| [OS] 프로세스 관리 (1) (0) | 2021.12.02 |
|---|---|
| [OS] 프로세스 (2) (0) | 2021.12.01 |
| [OS] 프로그램의 구조와 실행 (0) | 2021.11.18 |
| [OS] 컴퓨터 시스템의 동작 원리(컴퓨터 시스템 구조 & 입출력 수행) (0) | 2021.11.05 |
| [OS] 운영체제 개요 (0) | 2021.11.04 |
