프로세스란?
실행 중인 프로그램이다. 디스크에 실행 파일 형태로 존재하던 프로그램이 메모리에 올라가 실해되기 시작하면 비로소 생명력을 갖는 프로세스가 된다.
프로세스의 문맥(Context)🏆
프로세스 문맥은 특정 시점에서 봤을 때 프로세스가 어디까지 실행했는지를 규명한다. 프로세스의 현재 상태를 나타내는 데 필요한 모든 요소들을 포함한다.
프로세스의 문맥은 그 프로세스의 주소 공간(code, data, stack)을 비롯해 레지스터에 저장된 값, 시스템 콜을 통해 커널에서 수행한 일의 상태, 그 프로세스에 관해 커널이 관리하고 있는 각종 정보 등을 포함한다.
프로세스 문맥이 중요한 이유는 프로세스가 CPU를 자주 빼앗기고 획득하면서 수행되기 때문이다. CPU를 다시 획득하여 명령의 수행을 재개하게 되면, 이전에 CPU를 보유했을 때 어느 부분까지 명령을 수행했는지 재현해야 한다. (아니면 처음부터 다시 작업해야 한다!) 이때 정확한 재현을 위해 필요한 정보가 바로 context이다.
프로세스 문맥은 크게 세가지로 나눌 수 있다.
하드웨어 문맥
CPU의 수행상태를 나타낸다. PC 값과 각종 레지스터에 저장하고 있는 값들을 의미한다. 현재 시점에 프로세스가 어디까지 수행했는지 판단하는 지표가 된다.
프로세스의 주소 공간
code, data, stack에 어떤 내용이 들어 있는지
프로세스 관련 커널 자료 구조(커널 상의 문맥)
PCB(process control block)
프로세스가 하나 실행될 때마다 프로세스를 관리하기 위해 운영체제에서 PCB라는 자료구조를 만든다.
PCB는 프로세스에게 메모리, CPU 얼마나 줘야 할지, 이상한 행동하고 있지 않은지 관리한다.
Kernel Stack
프로세스가 실행되다가 자신이 할 수 없는 일을 하기 위해 운영체제에게 시스템콜을 하고 시스템 콜을 하면 PC가 커널의 code를 가리키며 수행된다.
이때 커널은 여러 프로세스가 공유하기 때문에 어떤 프로세스의 부탁을 받고 실행하는지 구분하기 위해 커널에서 함수 호출이 일어나서 스택에 정보를 쌓을 때는 프로세스 별로 스택을 별도로 둔다.
⇒ 이런 것들을 알면 프로세스가 어떤 상태에 있는지 정확히 규명할 수 있다.
time sharing, multi tasking 이므로 문맥을 모르면 다음번 CPU를 잡았을 때 처음부터 다시 시작해야 한다.
프로세스의 상태
CPU가 하나밖에 없는 상황에서 CPU를 잡고있는 프로세스는 매순간 하나뿐이다.
위의 그림을 컴퓨터 시스템 입장에서 다시 그리면
위와 같다.
Running
CPU를 잡고 instruction을 수행 중인 상태
Ready
CPU를 기다리는 상태. 다른 조건은 모두 만족이 되고(메모리에 프로그램이 올라가 있음) CPU 할당만을 기다림
보통은 Ready 상태의 프로세스들이 CPU를 잡았다 놨다하면서 time sharing 구현
Blocked(wait, sleep)
CPU를 얻어도 당장 instruction을 수행할 수 없는 상태
ex) process 자신이 요청한 오래 걸리는 작업(ex.I/O)이 즉시 만족되지 않아 이를 기다리는 상태
ex) 디스크에서 file을 읽어와야 하는 경우(읽어온 내용을 보고 나서야 다음 instruction 수행하는 경우)
경우에 따라선 New, Terminated 도 추가
New : 프로세스가 생성 중인 상태
Terminated : 수행이 끝난 상태(프로세스가 정리할 게 남아있는 상태)
Suspended 상태가 추가로 있지만 하단에 스케줄러 설명 후 언급
⇒ 모든 자원들이 놀지 않고 일할 수 있게 하는 메커니즘이다.
예시 : running 상태의 프로세스가 사용자로부터 키보드 입력을 받아서 결과를 확인하고 실행한다고 가정해보자. 그럼 키보드 I/O 큐에 줄을 선다. 즉,
running상태에서blocked상태로 변경된다. 그동안 CPU는ready상태에 있는 다른 프로세스에게 CPU를 전달한다.
키보드 입력을 받으면 키보드 컨트롤러가 CPU에게 인터럽트를 걸어서 알려주고, CPU는 하던 일을 멈추고 운영체제에게 넘어가서 프로세스 상태를ready로 바꾼다. 즉, 키보드 I/O 작업이 완료되었기 때문에 CPU를 얻을 수 있는 권한이 생기며ready큐에 줄을 서게 된다.
이외에 프로세스는 공유 데이터에 접근하거나, 디스크/키보드/디스크 등 종류에 따라 그에 맞는 큐에 줄을 서게 된다.
PCB(Process Control Block)
- OS 가 프로세스를 관리하기 위해 사용하는 정보
- Process state : 위에서 말한 내용(running 등)
- Process Id : 사람들의 주민등록번호 같은 느낌
- scheduling information, priority : 프로세스에게 CPU를 주기 위한 우선순위 값(순서)
- CPU 수행 관련 하드웨어 값
- Program counter, registers
- 메모리 관련
- Code, data, stack의 위치 정보
- 파일 관련
- open file descriptors(프로세스가 오픈한 파일 정보)
문맥 교환(Context switch)
문맥교환이란 하나의 사용자 프로세스로부터 다른 사용자 프로세스로 CPU 제어권을 넘겨주는 과정을 말한다.
CPU는 굉장히 빠른 자원이기 때문에 프로세스가 CPU를 짧은 시간 간격으로 얻었다 뺏겼다 반복한다.
뺏기고 다시 시작할 때 처음부터 다시 시작하는 게 아니라 뺏겼을 때 수행한 시점부터 다시 시작할 수 있도록 해야 한다.
그러기 위해서
- 뺏길 땐, 그 프로세스의 PCB에 레지스터에 있던 값, PC값, 메모리 맵도 저장
- 얻을 땐, 그 프로세스의 PCB에서 문맥을 다시 실제 하드웨어에 복원한 다음에 CPU를 넘겨준다.
예를 들어 사용자 프로세스가 CPU를 할당 받고 실행되던 중에 타이머 인터럽트가 발생하면 CPU의 제어권은 운영체제에게 넘어가게 된다. 그러면 운영 체제는 타이머 인터럽트 처리 루틴으로 가서 직전까지 수행 중이던 프로세스의 문맥을 저장하고 새롭게 실행 시킬 프로세스에게 CPU의 제어권을 넘긴다. 이 과정에서 원래 수행 중이던 프로세스는 준비 상태로 바뀌고 새롭게 CPU를 할당 받은 프로세스는 실행 상태가 된다.
동작 과정
시스템 콜이나 인터럽트가 발생하면 항상 문맥 교환이 일어나는가?
그렇지 않다.
System call(프로세스가 발생시킴)이나 interrupt(hw interrupt, 외부에서 들어옴) 발생 시(CPU 제어권이 사용자 프로세스에서 운영체제 커널로 넘어간다) 반드시 문맥교환이 일어나는 것은 아니다.
문맥교환은 사용자 프로세스에서 또다른 사용자 프로세스로 넘어갈 때 발생한다.
1번 경우는 프로세스가 실행 상태일 때 시스템 콜이나 인터럽트가 발생하여 CPU의 제어권이 운영 체제로 넘어와 원래 실행 중이던 프로세스의 업무가 잠시 멈추고 운영체제 커널의 코드가 실행된 경우다.
이 경우에도 CPU의 실행 위치 등 프로세스의 문맥 중 일부를 PCB에 저장한다. 하지만, 하나의 프로세스의 실행 모드가 사용자 모드에서 커널 모드로 바뀌는 것이고 CPU를 점유하는 프로세스가 다른 사용자 프로세스로 변경되는 것이 아니므로 문맥 교환이 아니다.
2번 경우는 타이머 인터럽트가 발생하거나 프로세스가 입출력 요청 시스템 콜을 하여 봉쇄 상태(Blocked)에 들어간 경우다. 이 때는 다른 사용자 프로세스에게 CPU의 제어권을 전달하므로 문맥 교환이 발생한다.
- 문맥교환이 일어나는 경우
- timer interrupt : 다른 프로세스에게 넘기기 위해 의도된 interrupt
- 오래 걸리는 작업(I/O 요청)이 들어와 blocked된 경우
- 위 그림에서 (1)경우에도 CPU 수행 정보 등 context 일부를 PCB에 save해야 하지만, 문맥 교환을 하는 (2)의 경우 그 부담이 훨씬 크다.(예를 들어 Cache memory를 다 지워버리는 Cache memory flush가 필요하다)
프로세스를 스케줄링하기 위한 큐
Job queue
현재 시스템 내에 있는 모든 프로세스를 유지하고 있는 집합
Ready queue, Device queue에 있는 작업들이 포함된다.
Ready queue
CPU를 기다리는 큐
Device queue에 있는 작업과 배타적
Device queues
I/O device 의 처리를 기다리는 프로세스의 집합
Ready queue에 있는 작업과 배타적
이런 식으로 프로세스들이 다양한 큐에 줄 서서 서비스를 받게 되고 운영체제가 이를 관리한다.
프로세스 스케줄링 큐의 모습을 실제 자료 구조에 맞게 그려놓은 것이다.
스케줄러(Scheduler)
각각의 자원 별로 무슨 일을 할지, 얼마동안의 시간동안할지 순서를 정해주는 거
Long-term scheduler
- 장기 스케줄러, job scheduler
- short-term scheduler와 반대
어떤 프로세스에게 메모리를 줄지 안 줄지 결정한다. 시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정하는 것이다.
프로세스가 생성되고(new) 메모리에 올라가는 것을 admit하는데, 메모리에 올라간 것을 허락받아야 ready상태로 진입할 수 있다.
degree of multiprogramming(메모리에 여러 프로그램 동시에 올리는 것) = 메모리에 동시에 올리는 프로그램의 수를 제어한다.
time sharing system에는 보통 장기 스케줄러가 없다. (무조건 ready 상태로 감)
프로그램이 시작되면 곧바로 메모리에 올려 놓는다. (→degree of multiprogramming을 조절하기 위해 medium-term scheduler)
→장기 스케줄러는 애초부터 메모리에 올라갈 수 있는 프로세스의 개수를 정해두고 이를 제어했다.
Short-term scheduler
- 단기 스케줄러, CPU scheduler
굉장히 짧은 시간 단위로 스케줄이 이루어진다. 잦게(millisecond 단위) 스케줄링이 일어난다.
다음번에 어떤 프로세스에 CPU를 줘서 running 시킬지 결정한다.
Medium-Term Scheduler
- 중기 스케줄러, Swapper
지금의 시스템은 시작되면 무조건 메모리를 주는데, 메모리에 너무 많은 프로그램이 동시에 올라가 있으면 문제가 발생한다.
이를 조절하는 것이 medium-term scheduler. 메모리에 너무 많이 올라가 있으면 여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄으로써 degree of Multiprogramming을 제어한다.
→ 중기스케줄러는 일단 메모리에 프로세스를 다 올려두고 너무 많이 올라가 있는 경우에 메모리에서 쫓아낸다.
프로세스의 상태
Suspended(stopped)
중기스케줄러 때문에 프로세스의 상태(running, ready, blocked)에 Suspended(stopped)가 추가되었다.
중기스케줄러에 의해 메모리를 뺏기고 디스크로 쫓겨났을 때(=하던 일을 멈추고 정지된다)의 상황을 표현하기 위함이다.
외부적인 이유로 프로세스의 수행이 강제로 정지된 상태로, 프로세스는 통째로 디스크에 swap out 된다.
ex) 사용자가 프로그램을 일시 정지(break way), 시스템이 여러 이유로 프로세스를 잠시 중단시킴(메모리에 너무 많은 프로세스가 올라와 있을 때)
Blocked : 자신이 요청한 event를 만족되면 Ready로 다시 돌아감
Suspended : 외부에서 정지 시켰기 때문에 외부에서 resume 시켜주어야 active 상태로 넘어갈 수 있음(Suspended가 아닌 상태)
- Running을 두가지로 나눔
- user mode : 본인의 코드 실행
- monitor mode : 본인이 할 수 없어서 system call을 하여 운영체제 코드가 실행 중일 때도 사용자 프로세스가 monitor mode에서 Running 중이라고 표현(≠ 운영체제가 running)
- suspended을 두가지로 나눔 : 프로세스가 얼어붙어서 정지되어 있는 상태(inactive)
- Suspended Blocked : Blocked 상태에서 swap out
- Suspended Ready : Ready 상태에서 swap outsuspended 상태에서 suspended blocked에서 suspended ready로 넘어갈 수는 있음(중지 봉쇄 상태이던 프로세스가 봉쇄되었던 조건을 만족하게 되면 중지 준비 상태로 바뀐다.)
