프로세스, 프로그램. Scheduling, 이를 위한 자료구조 등을 알아보자
프로세스란 실행 중이거나 디스크에서 실행 가능한 프로그램을 의미한다.
프로세스는 instruction의 sequence와 프로세스를 위한 하드웨어(레지스터)의 상태(정보), 자원(procedure call을 위한 stack)등으로 표현된다.
프로그램이란 디스크에 존재하는 명령어와 데이터로 이루어진 실행가능한 파일이다. 현재 실행 중이지 않은 것이다. 프로그램이 메모리에 로드되어야 프로세스가 된다.
(Execution Sequence)
참고
Exection of sequence of instruction이란 명령어의 연속(순서에 따라)의 실행을 의미한다. 명령어는 함수호출(call inst)도 포함할 수 있으며 명령어가 수행되며 바뀌는 메모리의 상태(context)가 어떻게 다른지 확인해보자.
(CALL Proc2가 두 번 불리는데, 이 둘의 context는 다르다, 스택의 리턴 주소를 확인해보자.)
call stack의 구현을 위한 값은 다음과 같다.
- Stack Pointer: stack의 top을 가리키는 포인터
- Stack Base: bottom을 가리키는 포인터
- Stack limit: 프로세스의 스택 공간의 경계(최대로 저장 가능한 선)를 가리킨다.
call stack은 stack frame으로 구성되어 있으며, stack frame이란 하나의 함수 호출에 대한 정보를 담고 있는 자료구조이다. 정보는 다음과 같다.
- 반환 주소
- 매개변수
OS에서 가장 중요한 자료구조 중 하나이다.
process의 모든 정보를 모아놓은 자료구조로 위의 이미지에 있는 중요한 영역들의 역할을 알아보자.
- identifier: 프로세스를 식별하는 숫자
e.g. 프로세스의 식별자, 부모 프로세스의 식별자, 프로그램을 만든 유저 식별자- state: 프로세스의 상태 정보
e.g. 지금 실행할 수 있음(ready) or zombie state- priority: 프로세스의 우선순위, scheduling에 사용된다.
- Context data: process switch가 일어났을 때, 프로세스 정보를 save하는 장소이다.
e.g. processor의 state, 즉 regsiter의 정보이다.
이의 주요 역할은 프로세스가 중단 되었을 때 process의 정보들, register의 정보들(register context or hardware context)을 저장하는 자료구조이다.
참고: PCB는 OS가 읽어오거나 수정할 수 있다.
Scheduling이란 프로세스 하나가 CPU를 독점하는 상황을 막고, CPU 이용률을 높히기 위한 프로세스를 상황에 따라 바꿔주는 기법을 의미한다.
만약 하나의 process가 I/O 요청으로 중단된다면 CPU는 아무것도 안하고 자원은 낭비될 것이다.
이 때 중단된 프로세스의 CPU의 제어를 빼앗고 다른 프로세스를 수행할 수 있을 것이다.
이를 위한 process의 상태정보(process state)가 필요하며 이 상태정보를 토대로 프로세스를 분류하여 자료구조에 저장할 수 있다.
상태에 따라서 PCB를 연결한 형태의 linked-list로 구현할 수도 있으며 위의 이미지에서 확인할 수 있다.
- Running: CPU가 수행하고 있는 프로세스이다.
- Ready: 바로 수행할 수 있는, 대기 중인 프로세스들이다.
- Blocked: 현재 특정 이유로 수행이 중단된 프로세스들이다. e.g. I/O request
지금까지 program이 메모리에 로드되어 process가 되어 실행되기 위한 정보들과 자원들을 확인하였다. 한 번 정리하여 쉽게 알아보자.
- User program, data, and stack
유저레벨의 소스코드, 데이터, 그리고 stack이 필요하다.(User level context)- PCB
프로세스를 OS가 관리하기 위한 프로세스의 정보(Hardware or system level context)를 담은 자료구조가 필요하다.
프로세스를 실행하기 위해서 위의 모든 것들이 메모리에 로드되어야 한다.(virtual memory를 다루지 않았기 때문에 이렇게까지만 알아두자.)
메모리에 로드된 process의 모습이다.
process context는 프로세스 문맥이다. 이는 PCB에 저장된 정보라고 생각하자. Hardware 또는 Regsiter context는 하나의 프로세스를 위한 하드웨어 정보라고 생각하자. process context는 Register/Hardware context를 포함**한다.
게다가 Summary에서 본 유저 레벨의 소스코드, 데이터, 그리고 stack, PCB 이 모든 것들은 시스템 레벨의 context이다.
아직 virtual memory를 배우지 않았으니, 프로세스가 메모리에 올라갔을 때의 모습이라 생각하자.
shared address space는 다른 프로세스와 통신하기 위한 정보를 담은 영역이다.
다양한 프로세스가 실행되며 상태가 어떻게 변화하는지 이해하자.
가상 메모리를 제외한 부분이다.(프로세스 정보가 전부 메모리에 올라간다.)
Dispatcher는 scheduler라 이해하자.(process switch를 발생한다.)
time slice가 존재하며 time-out이 된다면, context swtich가 발생한다.
process B는 I/O request가 발생한다고 가정한다. time-slice는 instruction이 6개라고 가정한다.
파란색 부분의 inst는 Scheduler의 것이라고 가정한다.
process switch는 Timer(Clock) Interrupt, System (Supervisor, e.g. I/O request) Call, Exception 등에 의해 발생한다.
하나의 프로세스가 수행되고 나머지는 기다리는 상태의 예시이다.
기다리는 프로세스들은 Queue에 존재한다.(ready list or run queue)
Not running state에 있는 동기화 I/O 작업을 하는 상태의 프로세스와 바로 수행될 수 있는 프로세스를 분류해줄 필요가 있다.(효율성)
New 상태는 fork() 직후라 생각하자.
Event는 I/O request라 생각하자.
그냥 blocked, event에 따른 blocekd queue를 나눌 수 있다.
특정 이유로 프로세스를 가용 메모리가 부족할 때, 디스크에 잠시 저장하는 것을 의미한다.(swap-out)
다시 실행해야할 때, 메모리에 올린다.(swap-in)
e.g. block process 또는 우선순위가 낮은 process를 swap-out 한다.
이를 위해서 두 가지 state가 필요하다
- Blocked/Suspended: block->suspend, 디스크에 있고 이벤트를 기다리고 있음
- Ready/Suspended: ready->suspend, 디스크에 있지만 바로 실행 가능함.
Runnig -> Ready/suspend는 어떻게 일어날까? 만약 process A을 진행하다. 우선순위가 굉장히 높은 process B가 나타났을 때 바로 CPU 사용을 빼앗고 B에게 줄 수 있다.