Process 1

뚝딱이·2023년 10월 13일

목록 보기

5/15

개념

프로세스는 실행중인 프로그램이다.

context

프로세스의 문맥을 이해하는 것이 중요하다. 특정 시점을 봤을 때 어디까지 수행 했고 어디까지 와 있는지 규명하는 것이다. 이는 PC가 어디를 가리키고 있는가, 프로세스의 주소공간에 어떤 데이터들이 쌓여있는가, register에 어떤값을 넣어놓고 어떤 instruction 까지 실행했는가를 알아야한다.

CPU 수행 상태를 나타내는 하드웨어 문맥
- Program Counter
- 각종 register!
프로세스의 주소 공간
- code
- data
- stack (자신의 함수 호출, 반환 시)
프로세스 관련 커널 자료 구조
- PCB (Process Control Block)
- Kernel stack (시스템 콜을 했을 때 커널의 코드를 실행 -> 함수 호출 -> 스택에 정보 저장)

프로세스가 하나 실행될 때 마다 프로세스를 관리 하기 위해 커널 주소 공간의 data에 프로세스의 PCB, stack에 프로세스의 커널스택을 각각 저장한다. 프로세스의 현재 상태를 알려면 운영체제의 값도 알아야한다.

커널은 모든 프로세스가 공유하므로 어떤 프로세스의 것인지 알아야 하므로 프로세스별로 데이터를 저장한다. 프로세스 A,B가 있으면 A의 PCB, B의 PCB 따로 저장한다.

CPU가 실행중이던 프로그램을 멈추고 다른 프로그램을 실행한다면, 기존의 프로그램을 다시 실행하기 위해 어떤 instruction을 어디까지 실행중이었는지 등을 알아야한다. 따라서 문맥을 알고 이를 저장해놓는 것이 중요하다.

프로세스의 상태

처음 프로세스가 생성되면 ready 상태로 간다. 이때는 최소한의 메모리는 가지고 있어야한다. 본인 차례가 되어 CPU를 얻으면 running 상태가 된다. 이때 I/O 작업을 해야하면 waiting 상태로 넘어가고, CPU를 계속 쓰고 싶으나 timer interrupt 가 오면 중단하고 ready로 돌아간다.

Running

CPU를 잡고 instruction을 수행중인 상태

Ready

CPU를 기다리고 있는 상태 (메모리 등 다른 조건을 모두 만족하고 -> 당장 이 프로그램이 실행되려면 물리메모리에 적재되어야한다.)

Block (wait, sleep)

CPu를 주어도 당장 instruction을 수행할 수 없는 상태, 예로 오래걸리는 I/O 작업을 진행중인 경우이다.
Process 자신이 요청한 event 가 즉시 만족되지 않아 이를 기다리는 상태
예시로 디스크에서 file을 읽어와야 하는 경우가 있다.

new : 프로세스가 생성중인 상태
terminated : 수행이 끝난 상태

CPU를 기다리는 Ready queue 뿐만 아니라 공유 데이터, I/O 작업을 위한 queue도 존재한다. 이러한 queue는 운영체제 커널이 자료구조로 queue를 만들어 놓고 이를 data에 저장해놓고 운영한다.

PCB (Process Control Block)

운영체제가 관리상 사용하는 정보
- Process state, Process Id
- scheduling information, priority
CPU 수행 관련 하드웨어 값
- Program counter, register
메모리 관련
- Code, data, stack의 위치 정보
파일 관련
- Open file descriptors

Context Switch

CPU가 굉장히 빠른 자원이므로 독점하는 것이 아닌 짧은 시간 간격으로 번갈아 사용한다. CPU를 뺏겼다가 실행하게 되면 뺏긴 시점의 문맥을 기억했다가 이어서 실행한다. 따라서 CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정이다.

CPU가 다른 프로세스에게 넘어갈 때 운영체제는 다음을 수행한다.

CPU를 내어주는 프로세스의 상태를 그 프로세스의 PCB에 저장
CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 읽어옴

System call 이나 interrupt 발생시 반드시 context switch가 일어나는 것은 아니다.

(1) user mode에서 자신의 코드를 실행하다가 interrupt나 system call 을 발생하면 CPU의 제어권이 운영체제로 넘어가게 된다. 커널 함수가 실행된 다음 보통은 커널 모드로 들어가기 전의 프로세스로 돌아간다. 따라서 프로세스가 동일하게 유지되므로 Context switch가 일어나지 않는다.

(2) user mode에서 코드를 실행하다가 time sharing을 위한 timer interrupt가 발생하거나 시간이 오래걸리는 I/O 요청 system call 이 발생했다면 당장 CPU만 주면 실행가능한 ready 상태의 프로세스로 간다. 따라서 context switch가 발생한다.

1번의 경우에도 context switch는 일어나지 않지만 해당 프로세스의 주소 공간에서 커널 주소공간으로 가기 때문에 문맥을 저장해야하긴 하지만 2의 경우 보다 부담이 훨씬 적다. 2의 경우엔 cache memory를 다 지워야 하기 때문에 상당항 오버헤드를 발생시킨다. 하지만 1번 상황에선 cache memory를 지울 필요 까진 없고 저장했던 문맥을 복원하기만 하면 된다.

큐

Job queue : 현재 시스템 내에 있는 모든 프로세스의 집합
Ready queue : 현재 메모리 내에 있으면서 CPU를 잡아 실행되기를 기다리는 프로세스의 집합
Device queue : I/O device의 처리를 기다리는 프로세스의 집합

프로세스 스케줄링 큐의 모습

스케줄러

Long-term scheduler

job scheduler라고도 한다.
시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정한다.
프로세스에 memory를 주는 문제이다.
프로세스가 new가 되어 있다가 ready 상태로 넘어갈 때 메모리에 올라가게 된다. 따라서 이를 결정한다.

degree of Multiprogramming(메모리에 프로그램이 몇개 올라가있는가를 나타냄, 메모리에 올라가있는 프로세스의 수)을 제어한다.
메모리에 너무 많은 프로그램이 동시에 올라가도 성능이 안좋고, 메모리에 너무 적은 프로그램이 올라가도 성능이 안좋다. 따라서 메모리에 프로그램을 몇개 올려야하는지 정하는 것이 중요하다. 너무 많은 프로그램이 올라간다면 각 프로그램에 할당된 메모리가 작아 CPU가 필요한 메모리 조차도 없을 수 있다.

time sharing system에는 보통 장기 스케줄러가 없다. 무조건 ready이다.

Short-term scheduler

CPU sheduler라고도 한다. 짧은 간격으로, 충분히 빠르게 이루어진다.
어떤 프로세스를 다음에 running 시킬지 결정한다. 프로세스에 CPU를 주는 문제이다.

Medium-Term Scheduler

다른 말로는 Swapper라고도 한다.
여유 공간 마련을 위해 프로세스를 통째로 메모리에서 디스크로 쫓아낸다. 이러한 방식을 통해 degree of Multiprogramming을 제어한다.

초기엔 장기 스케줄러를 통해 메모리에 올라가는 프로그램의 수를 제어했지만, 이제는 모든 프로그램을 메모리에 올려놓고 중기 스케줄러를 통해 메모리에 올라가있는 프로그램의 수를 제어한다.

중기스케줄러로 인해 추가된 프로세스의 상태가 있다. 이가 Suspended (stopped)이다. 이는

외부적인 이유로 프로세스의 수행이 정지된 상태
프로세스는 통째로 디스크에 swap out 된다.
예
- 사용자가 프로그램을 일시 정지 시킨 경우 (사람이 재개시켜줘야지 다시 돌아갈 수 있다.)
- 시스템이 여러 이유로 프로세스를 잠시 중단시킨다. (메모리에 너무 많은 프로세스가 올라와 있을 때 중기 스케줄러가 프로세스를 디스크로 쫓아내는 경우)

Blocked는 자신이 요청한 event가 만족되면 Ready, Suspended는 외부에서 resume해 주어야 active