[OS] 3-1. Process 1
- IT/OS
- 2020. 12. 18.
4. Process Control Block (PCB)
1. 프로세스의 개념
-
프로세스는 실행중인 프로그램
-
프로세스의 문맥이란 프로세스가 태어나서 실행이 되다가 종료가 될텐데, 이 프로그램 중간 어느 시점을 잘라놓고 봤을 때 이 프로그램이 무엇을 어떻게 실행 했는 지, 현재 시점에 어떤 상태에 있는 지, 어디까지 작업을 수행했는지를 정확하게 나타내기 위해서 사용되는 개념
-
프로세스가 CPU를 점유하게 되면 CPU안의 Program Counter라는 레지스터가 이 프로세스의 code 어느 부분을 가리키게 되고, 매 순간 instruction을 읽으면서 레지스터에 값을 놓고, 연산을 하고, 결과를 레지스터에 저장하거나 메모리에 저장. 이런 식의 진행을 하다가 '어느 시점에는 과연 이 프로세스는 어디까지 와있는 것인가'를 규명하는 것이 이 프로세스의 문맥
-
현재 시점에 프로세스의 문맥을 나타내기 위해서는 PC는 어디를 가리키고 있는가(코드의 어느부분까지 실행을 했는가)
-
현재 무슨 내용이 어디까지 쌓여져있는가 (⇒ 만약 코드가 실행되면서 함수를 호출했다면 스택에 어떤 내용이 쌓여있을 것)
-
또한 데이터 영역의 값은(변수) 프로그램이 실행되면서 계속 바뀔 것(⇒ 지금 이 변수의 값은 얼마인가)
-
이 프로그램이 실행되면서 레지스터에 어떤 값을 넣었고 어떤 instruction까지 실행 했는가.
-
이 모든 요소를 알아야지만 이 프로세스의 현재 상태를 나타낼 수 있을 것
-
다시 말하면, 프로세스의 현재상태를 나타내는 데에 필요한 모든 요소를 프로세스 문맥이라고 함.
-
프로세스 문맥이 필요한 이유 : 프로세스들이 번갈아가면서 CPU를 점유하기 때문에 한 프로세스가 CPU를 사용하다가 CPU가 다른 프로세스에게 넘어갔을 때, 프로세스의 문맥을 알고 있지 않으면 다음 번에 CPU를 잡았을 때 어디서부터 실행해야할 지를 알 수 없을 것.
2. 프로세스의 상태 (Process State)
▣ Ready : 다른 조건들이 모두 만족한다는 말은 CPU를 얻었을 때 instruction을 바로 실행할 수 있는 상태 (프로그램 실행을 위해 필요한 부분들이 물리적인 메모리에 적어도 올라와있어야 함)
▣ Blocked(wait, sleep)
-
CPU를 줘봤자 instruction을 실행 못하는 상태
-
오래 걸리는 IO작업이 필요한 프로세스(디스크에서 무언가를 읽어와야만 작업이 가능한 프로세스가 있다면 CPU를 얻어와봤자 IO작업이 수행되기 전까지 그 결과를 기다려야 하기 때문에 아무 일도 하지 못함)
▣ New (경우에 따라 프로세스 상태에 포함)
-
이미 프로세스가 생성이 되었다면 위의 세 상태(Running, Ready, Blocked) 중 하나일 테지만 프로세스가 지금 막 생성이 되고 있는 중인 상태가 New
▣ Terminate (경우에 따라 프로세스 상태에 포함)
-
프로세스가 종료 중인 상태(이미 종료가 되었다면 더 이상 프로세스가 아님)
-
본인이 할 일을 다 마쳐서 instruction이 다 끝났지만 보통 끝나고나면 정리하는 작업이 남아있음. Terminate라는 것은 일을 다 마쳤지만 정리할 것이 남아있는 상태
3. 프로세스 상태도
1) New : 프로세스가 생성 중, 생성 되면 Ready로 넘어감
2) Ready : CPU만 얻으면 실행가능한 상태(최소한의 메모리는 가지고 있어야함) CPU에서 instruction을 실행하는데 필요한 부분은 메모리에 올라와있는 상태. 여기서 본인 차례가 되어서 CPU를 얻게 되면 Running 상태
3) Running : CPU를 얻어서 실행 중인 상태
-
Running상태에서 CPU를 내어놓는 화살표가 세 가지
(a) 자진해서 나감(I/O와 같은 작업 or wait)
⇒ CPU를 가지고 있어봐야 instruction이 불가하기 때문에 자진 반납. Block 상태로 넘어감
(b) 일이 아직 남았지만 할당된 시간이 다 된 경우(Timer interrupt)
⇒ 다시 CPU를 기다리며 줄을 서 있어야 함
-
CPU를 사용하고 있는 프로세스에 Timer interrupt가 발생하면 Ready queue 맨 뒤에 가서 줄을 섬
-
한 프로세스가 CPU를 사용하고 있다가 I/O가 필요한 작업이 발생 ⇒ 이 프로세스가 Running에서 Blocked로 바뀌면서 I/O서비스가 필요한 Queue에 이 프로세스가 줄을 섬. I/O 장치들은 요청이 들어온 서비스들을 컨트롤러의 지휘 하에 순서대로 처리. 요청된 작업이 끝나면 디바이스 컨트롤러가 CPU에게 인터럽트를 검('요청한 I/O 작업이 끝났습니다'). CPU는 지금 어떤 프로세스를 실행하고 있었겠지만 인터럽트가 들어왔기 때문에 하던 작업을 멈추고 제어권을 OS 커널에게 넘김. 그러면 OS 커널은 I/O 작업이 끝난 프로세스의 메모리영역에 해당 데이터를 넘겨주고, 프로세스의 상태를 Blocked에서 Ready로 넘겨 CPU를 얻을 수 있는 자격을 줌.(상태 변환 시킨 후 Ready queue에 대기)
-
하드웨어 자원의 큐에 들어가서 대기 할 때도 있지만 소프트웨어 자원의 큐에 대기할 때도 있음 ⇒ ex) 공유 데이터. 하나의 프로세스가 공유 데이터를 사용하고 있을 때, CPU를 뺏겨서 다른 프로세스가 또 공유 데이터에 접근한다면 일관성이 깨어지는 문제가 생길 수 있음. 공유 데이터를 한 프로세스가 이미 사용중이면 다른 프로세스는 접근을 막아주는 것이 경우에 따라 필요. ⇒ 프로세스들을 줄을 세움
-
CPU, 프로세스의 예) 놀이공원에서 롤러코스터를 탄다고 생각. 롤러코스터(CPU)는 굉장히 빠른데 정작 타기위해 줄을 서야하는 시간은 김.
4. Process Control Block (PCB)
(1) 프로세스의 상태(Running인지 등), ID(프로세스 마다 번호가 있음) 등. 프로세스 우선순위 정보(그림상에선 먼저 온 순서대로 CPU를 사용할 수 있는 것처럼 보이지만 꼭 그렇지는 않음. 정확한 스케줄링은 레디 큐에서 우선순위가 높은 프로세스에게 CPU를 넘겨주는 메커니즘 사용)
(2) 프로세스 문맥에 관련된 정보
(4) 이 프로세스가 오픈하고 있는 파일들이 어떤 것인가
5. 문맥 교환 (Context Switch) ⭐
-
CPU를 뺏겼다가 다시 얻을 때, 처음부터 실행을 하는 것이 아니라 뺏기던 시점의 문맥을 기억해놨다가 그 시점부터 계속해서 실행해 줄 수 있는 메커니즘이 필요.
-
PCB는 프로세스마다 OS 커널 (data 공간)에 저장 ⇒ 만약 한 프로세스가 CPU를 사용하다가 타이머 인터럽트가 걸렸다! 그 때, OS는 CPU를 내놓은 프로세스 정보를 세이브 해놓음
-
CPU를 내놓는 프로세스가 있으면 CPU를 다시 점유하는 프로세스가 있음. 그 프로세스 역시 이전까지 수행중이었던 위치부터 재개하기 위해 OS가 CPU를 넘겨줄 때 그 프로세스의 문맥을 PCB에서 찾아서 하드웨어에 다시 복원.
-
system call : 프로세스가 본인이 필요해서 OS에게 무언가를 요청
-
interrupt (여기선 하드웨어 인터럽트) : 컨트롤러 같은 장치가 CPU에게 정보를 전달할 목적으로 인터럽트를 검.
-
시스템 콜, 인터럽트가 발생하면 CPU 제어권이 사용자 프로세스로부터 OS 커널로 넘어감. 이 때 일반적으로는 결과를 받고 CPU는 다시 이전에 프로세스로⇒ 이걸 문맥교환이라고 하지 않음. 위 그림에서 (1)의 경우!
-
문맥 교환(Context Switch)은 CPU가 프로세스에서 다른 프로세스로 (CPU가 프로세스에서 OS커널로 넘어가는게 문맥교환이 아님!)
-
(2)의 경우. 인터럽트 중에서도 timer interrupt. timer interrupt는 특별히 CPU를 다른 프로세스에게 넘기기 위한 의도를 가지고 있음.
-
별표 설명 : (1)의 경우, 프로세스 A의 코드(stack, data, code 중 code)를 실행하다가 커널의 코드를 실행 하는 모습. 이 때 A에서 실행되던 것, 약간의 문맥을 save를 해놓긴 함. 그러나 A 에서 B로 문맥교환이 일어나게 되면 보통 A프로세스가 사용하던 캐시메모리를 다 지워버림. 반면 (1)의 상황에서는 그렇게까지 할 필요 X ⇒ 오버헤드가 적음
6. 큐 (Queue)
-
Job queue에는 Ready queue에 있거나 Device queue에 있는 프로세스들이 포함
-
But Ready queue에 있으면 Device queue에 없어야 하고 Device queue에 있으면 Ready queue에는 없어야 함
-
맨 위에 있는 그림이 ready queue이고 그 밑에 있는 사각형들이 디바이스 큐
-
큐가 줄세워진 것을 보면 OS가 프로세스를 관리하기 위한 자료구조, 즉 PCB를 줄 세움.
-
아까 봤던 PCB 자료구조를 다시 살펴보면 Pointer가 있음. PCB를 줄줄이 연결할 수 있는 pointer가 있고 그걸 이용해서 연결을 해놓은 것.
-
프로세스가 CPU를 점유하고 있다가 자식 프로세스를 만들 수 있음(다음 챕터에 나옴). 자식 프로세스가 실행 중인 동안엔 CPU를 놓고 Ready queue에서 기다림
-
맨 마지막 줄 (wait for an interrupt) 그림은 첫 번째 (I/O request) 그림을 다른 방식으로 표현한 것. I/O 작업 중엔 interrupt를 기다리면서 blocked. I/O가 끝나서 인터럽트가 발생하면 다시 Ready queue에서 CPU를 기다림.
7. 스케줄러(Scheduler)
1) Short-term scheduler (단기 스케줄러 or CPU scheduler)
-
굉장히 짧은 시간 단위로 스케줄이 이루어지기 때문에 short-term ~라고 이야기 함. (굉장히 잦은 스케줄)
-
다음 번에 어떤 프로세스에게 CPU를 줄 지를 결정
2) Long-term scheduler (장기 스케줄러 or job scheduler)
-
메모리를 어떤 프로세스에게 줄 지를 결정하는 문제(프로세스 상태도 그림 참조)
⇒ 프로세스가 시작이 될 때, (new에서 ready상태로 넘어갈 때) admitted 과정. 그렇다면 뭘 admitted를 하느냐. 메모리에 올라가는 것(in memory)을 admit 함. 처음 프로세스가 시작되고나서 이 프로세스가 메모리를 전혀 얻지 못한다면 아무 일도 못 할 것. 메모리에 올라가는 것을 허락하게 되면 비로소 ready 상태가 되고 CPU를 얻을 수 있게 됨.
-
다시 말하면, 롱텀스케줄러는 어떤 프로세스가 new 상태에 있는데 그 프로세스에게 메모리를 줄 지, 안 줄 지를 결정
-
multiprogramming 이란 메모리에 여러 프로그램이 동시에 올라가는 것. degree of multiprogramming은 메모리에 프로그램이 몇 개 올라가는 지를 나타내는 것. 메모리에 올라가는 프로세스 수를 제어하는 것이 롱텀 스케줄러 역할
-
ex) 10개의 프로그램이 시작되고 있는데 10개의 프로세스에 다 메모리를 준다면 degree of multiprogramming 은 10
-
사실 우리가 사용하는 pc에는 장기 스케줄러가 없음 (프로세스를 실행시키면 바로 메모리에 올라감) ⇒ 그렇다면 우리가 현재 사용하는 pc에선 degree of multiprogramming을 어떻게 조절할까? ⇒ medium-term scheduler
3) Medium-term scheduler(중기 스케줄러 or Swapper)
-
지금의 시스템들은 일단 프로그램이 시작되면 무조건 메모리를 줌.
-
메모리에 너무 많은 프로그램이 동시에 올라가 있으면 Swapper는 일부 프로그램을 골라서 메모리에서 통째로 쫓아냄
-
얘 때매 프로세스 상태(Running, Ready, Blocked)에서 추가된 것이 있음(기존의 프로세스 상태를 가지고는 메모리에서 통째로 빼앗긴 프로세스에 대한 상태가 표현이 안됨) ⇒ Suspended(stopped)
⇒ Blocekd은 자신이 요청한 IO작업이 끝나면 Ready 상태로 돌아 갈 수 있고 Suspended는 외부에서 정지를 시켰기 때문에 외부에서 다시 재개를 시켜줘야만 Active 상태로 바뀔 수 있음. ex) 동영상 일시정지 (사람(외부)이 정지시킨 것, 사람(외부)이 다시 실행시켜 줘야 위의 상태로 돌아감)
Running 두 가지로 나눠서 그린 그림.
user mode Running : 프로세스가 CPU를 가지고 있으면서 본인의 코드를 실행중인 상태
monitor mode Running : 본인이 어떤 일을 할 수 없어서 OS에게 대신 요청하여 OS의 코드를 실행 중인 상태(System call). 이 때 이 프로세스가 CPU를 잃고 OS가 CPU를 얻어서 OS 커널이 Running을 하고 있다고 표현하지 않음. (Running, Ready, Blocked 등의 상태는 OS가 관리상 사용자 프로세스 상태를 나누어 놓은 것. OS 본인의 상태가 Running이고 이런 얘기는 하지 않음)
⇒ 사용자 프로세스가 자신의 코드를 실행하다가 시스템 콜을 하여 OS 코드가 실행 중일 때, 이 때에도 그 사용자 프로세스가 (커널 모드에서) 러닝하고 있다 라고 하지 OS가 Running하고 있다고 하지 않는다는 것. 인터럽트가 들어온 경우도 같음. 프로세스가 실행되고 있다가 인터럽트가 들어오면 운영체제 커널의 코드(인터럽트 서비스 루틴)가 실행 될 것. 이 인터럽트는 그 프로세스 때문에 실행 되는 것이 아니라 외부의 어떤 다른 요인 때문에 인터럽트가 들어왔겠지만 이 상황에서 보통 이 프로그램이 여전히 running하고 있다고 간주. (다만, 커널 모드에서 러닝 중이라는 것)
(추가)
-
Suspended도 blocked 상태에서 suspend되었느냐, Ready 상태에서 Suspend 되었느냐에 따라 서로 다른 두 가지 상태(Suspended Blocked, Suspended Ready)로 표현
-
Suspended Blocked에서 Suspended Ready상태로는 이동 가능 ⇒ 기본적으로 메모리를 완전히 잃어버리게 되는 상황으로 CPU관점에서 아무 일도 할 수 없다 뿐이지 IO같은 작업이 진행 중이었다면 그것은 계속 진행이 되어서 Suspended Ready로 넘어갈 수는 있음
출처 : 반효경 교수님(이화여대) 강의
반효경 교수님의 강의를 들으며 정리한 것입니다.
'IT > OS' 카테고리의 다른 글
[OS] 4. Process Management (0) | 2020.12.24 |
---|---|
[OS] 3-2. Process 2 (0) | 2020.12.24 |
[OS] 2-2. System Structure & Program Execution 2 (0) | 2020.12.16 |
[OS] 2-1. System Structure & Program Execution 1 (0) | 2020.12.15 |
[OS] 1. Introduction to Operating Systems (0) | 2020.12.14 |