반효경 교수님의 위대한 운영체제 - 3. 프로세스 관리

이석규·2024년 1월 12일

운영체제

운영체재 개요
컴퓨터 시스템의 구조
3. 프로세스 관리
CPU 스케줄링
병행 제어
데드락
메모리 관리
가상 메모리
파일 시스템
입출력 시스템
디스크 관리

프로세스의 개념

프로세스의 문맥 - context

프로세스는 다음과 같은 순서로 실행되곤 하는데,

프로세스가 실행이 됨
프로세스의 주소 공간이 만들어짐 > stack, data, code
프로그램 카운터(PC)라는 레지스터가 code 영역의 어느 부분을 가리키고 있음
매 순간 code 영역에서 기계어를 읽어서 지침(instruction)을 보냄
그것을 레지스터에서 받고, 산술 논리 연산 장치(ALU)에 넣고 연산
그 결과를 메모리나 레지스터에 저장함

이 과정들 중 현재 프로세스가 어디까지 와있나 알 수 있는 것이 바로 프로세스 문맥(context)이다.

이를 정확히 알기 위해서는 context는 다소 많은 의미를 담고 있는데,

CPU 수행 상태를 나타내는 하드웨어 문맥
- Program Counter(PC)
- 각종 register
프로세스의 주소 공간
- code, data, stack
프로세스 관련 커널 자료 구조
- PCB(Process Control Block)
- Kernal Stack

이러한 애매한 개념의 문맥은 안드로이드에서도 쓰이곤 한다.
내 생각에는 context를 activity 단위의 작업이 현재 이루어지고 있고, 현재 그 작업이 이루어지고 있는 프로젝트 내부의 해당 activity 그 자체를 의미하고 있는 것 같다고 생각이 든다.

이러한 프로세스의 문맥을 왜 알아야 하는걸까?
현대 컴퓨터 시스템은 time sharing, multi tasking 등으로 하나 이상의 프로세스들이 번갈아가며 실행된다.
CPU를 다른 프로세스에게 넘겨주고 나서 다시 돌아왔을 때, 마지막에 실행됐을 때를 알기 위해 이를 기억하고 있어야 한다.

프로세스의 상태

프로세스는 상태가 변경되며 수행된다.

Running
CPU를 잡고 instruction을 수행중인 상태
Ready
CPU만 얻으면 되는 상태 (메모리나 다른 상태들은 만족한 상태)
Blocked(wait, sleep)
CPU를 줘도 instruction을 수행하지 못하는 상태
Process 자신이 요청한 event(I/O)가 즉시 만족되지 않아 기다리는 상태

PCB - Process Control Block

운영체제가 각 프로세스를 관리하기 위해 프로세스 당 유지하는 정보

1) OS가 관리상 사용하는 정보
2) CPU 수행 관련 하드웨어 값
3) 메모리 관련
4) 파일 관련

문맥 교환 - Context Switch

CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 과정
다음과 같은 작업을 수행함

1. CPU를 내어주는 프로세스의 상태를 해당 프로세스의 PCB에 저장
2. CPU를 새롭게 얻는 프로세스의 상태를 PCB에서 얻어옴

System Call(프로세스가 본인이 OS에 무엇인가 요청할 때)이나 interrupt(controller 같은 장치가 CPU에 요청을 걸 때)가 발생한다고, 반드시 context switch가 일어나는 것은 아니다.

A Process에서 제어권이 OS로 넘어간다 한들, 다시 A Process로 돌아온다면 그것은 context switch가 아니다.
A Process에서 B Process로 넘어가야만 context switch다.

프로세스를 스케줄링 하기 위한 큐

Job Queue
현재 시스템에 있는 모든 프로세스

스케줄러

Long term scheduler(=job Scheduler)
프로세스에 메모리를 주는 문제
시작 프로세스 중 어떤 것들을 ready queue로 보낼지 결정

Short term scheduler(=CPU Scheduler)
충분히 빨라야한다.(millisecond 단위)
프로세스에 CPU를 주는 문제
어떤 프로세스를 다음에 running 할 지 결정

Medium term scheduler(=swapper)
여유 공간을 마련하기 위해 프로세스를 통째로 메모리에서 디스크로 쫓아냄
프로세스에게서 메모리를 뺏는 문제

suspended
메모리를 뺏는 중기 스케줄러 때문에 생긴 프로세스의 새로운 상태

외부적인 이유로 프로세스의 수행이 정지된 상태
프로세스는 통째로 디스크에 swap out 된다.

blocked vs suspended
blocked는 자신이 요청한 일을 기다리기에, event가 만족되면 Ready
suspended는 외부에서 resume 해줘야만 active 된다.

이로 인해 바뀐 상태도이다.

Thread (light weight process)

프로세스 내부의 CPU 실행 단위
프로세스 내부에 Program Counter(code 부분의 어느 곳을 실행하는 지 알기 위해)를 여러개 두는 것
stack, register, PC를 제외한 모든 것을 같은 프로세스 안의 다른 스레드와 공유한다.

single / multi thread

benefits

thread의 사용 이유
-다중 스레드로 구성된 테스크 구조에서는 하나의 스레드가 blocked 상태인 동안에도 동일한 다른 스레드는 여향을 안 받고 처리할 수 있다.
-동일한 일을 수행하는 다중 스레드가 협력하여 높은 처리율과 성능 향상을 얻을 수 있다.
-스레드를 사용하면 병렬성을 높일 수 있다.

응답성 : I/O 결과를 불러오는 도중에는 해당 스레드만을 block 하고 나머지 스레드를 통해 다른 작업의 결과를 보여줄 수 있다.
자원 공유 : 별도의 프로세스를 여러 개 두는 것보다 별도의 스레드를 둠으로써 자원을 공유할 수 있다.
경제성 : 프로세스 하나를 추가로 생성하고, CPU switching을 하는 것은 오버헤드가 크다.
multi process 구조의 유틸성 : CPU가 여러개이면 해당하는 장점으로, 프로세스 내부의 다른 스레드들이 훨씬 빠른 작업이 가능하다.

프로세스의 생성

copy-on-write(cow) : write가 발생했을 때, copy를 하겠다.

부모 프로세스가 자식 프로세스를 생성
프로세스의 트리(계층 구조) 형성
프로세스는 자원을 필요로 함
자원의 공유 (모델에 따라 다르지만, 원칙적으로는 공유하지 않음)
수행 (부모와 자식이 함께 수행되거나, 자식의 수행을 기다리거나 함)
주소 공간 : 자식은 부모의 공간을 복사함, 그 공간에 새 프로그램을 올림
유닉스를 예로 들면 다음과 같은 시스템 콜이 호출된다.
fork() : 새로운 프로세스를 생성하고 부모를 복사한다.
exec() : 새로운 프로그램을 메모리에 올린다.

프로세스 종료

exit : 프로세스가 마지막 명령을 수행한 후 운영체제에 알려줌
종료 후 자식이 부모에게 output data를 보내고 프로세스의 자원들이 운영체제에 반납됨

abort : 강제종료/부모가 자식의 수행을 종료시킴
자식이 할당 자원의 한계치를 넘어서거나, 할당된 태스크가 더 이상 필요하지 않거나, 부모가 종료된 경우에 이루어진다.

프로세스와 관련된 시스템 콜 4 가지

fork()

부모 프로세스에서 완전히 같은 프로세스를 하나 더 생성하고, 이는 플로우 상으로는 달리 나아갈 수 있다.

exec()

자식인 경우, execlp() 로 인해 새로운 코드로 덮어쓴다.
자식인 경우, 프린트 문을 출력하고, execlp 내부의 date 코드를 실행한다.

위 코드의 경우는 현재 프로그램을 버리고, date 코드로 실행된다.

wait()

프로세스 A가 시스템 콜을 호출하면
커널은 child가 종료될 때까지 프로세스 A를 sleep 시킨다. (block 상태)
child process가 종료되면 커널은 프로세스 A를 깨운다.(ready 상태)
간단히 말해, 자식 프로세스가 종료될 때까지 기다리는 콜

exit()

프로세스의 종료

자발적 종료
마지막 statement 수행 후 exit() 시스템 콜을 통해 수행함.
프로그램에 명시적으로 적어주지 않아도 main 함수가 리턴 되는 위치에 컴파일러가 넣어줌
비자발적 종료
부모 프로세스가 자식을 강제로 종료시킴
키보드로 kill,break 등을 친 경우
부모가 종료하는 경우