[ SNU 강의 ] 운영체제의 기초 | 쉽게 배우는 운영체제 4주차

 

0. Process Concepts

process는 OS 위에서 프로그램을 수행시키는 기본 주체.
= 런타임 시스템의 수행 주체
= CPU나 여러가지 자원의 할당을 받는 주체.

decomposition의 한 유닛이 process

 

why?

날로 복잡해지는 컴퓨터에 대응할 수 있는 무기

• Abstraction (추상화)
• Decomposition
  전체를 분석하기 어려울 때 여러 개로 쪼개는 것. 각각의 조각을 이용하기가 쉬워질때까지
  = 복잡한 문제를 단순한 여러 문제로 나누는 방법론
  이와 같이 나눠진 문제들이 process가 된다

 

what?

수행 중인 프로그램 == 프로세스.
특정 프로세스의 상태 위에서 수행되는 excution stream.

 

📌 질문
프로그램과 프로세스는 뭐가 다른가?

차이 1
프로그램은 저장매체에 저장된 수동적인 코드시퀀스.
그런데 이 프로그램을 PC에 깔아서 수행하면 프로세스가 된다.
이 때 OS는 cd rom에서 파일을 읽어
메인메모리에 로드한 후
CPU를 주고
수행하다 I/O디바이스도 사용하고, 여튼 이렇게 된다,

차이 2
프로그램은 storage에 저장된 수동적인 매체.
프로세스는 능동적인 존재 = excution을 가지고 있다
=> excution stream, excution thread

 

✍ 프로그램 스테이트?

프로그램이 수행되는데 기억해야 할 정보들을 저장하는 것 = program state
수행에 영향을 주거나 수행의 결과에 영향을 받을 수 있는 정보들을 뜻한다

 

자세한 설명
프로그램이 수행되려면 필요한 것

1. Memory
   • Code(기계어), Data(프로그램의 전역 변수 내용), Stack(function call, 지역변수)
2. Register Values
3. Per-Prosess kernal info (커널이 관리하는 프로세스의 정보)

 

✍ excution stream?

프로세스가 지금까지 수행한 모든 명령어들의 순서

결과적으로 프로세스는 수행중인 프로그램이고
프로그램을 수행시키기 위해서는 state가 필요하고
이 위에 excution stream이 존재한다.

 

 

0-1. 이 Process를 실제로 어떻게 구현하는가?

 

일단 멀티프로그래밍의 정의를 기억해보자.
여러 개의 active한 Process가 동시에 수행되는건데
이건 메모리의 관점.
main memory에 여러 개의 active한 process가 로드되었으면 하는 말임.

 

multy processing
CPU의 관점
CPU가 여러개의 process에 의해서 multy processing되는 것.

 

Swapping
메모리 부족 문제를 해결하기 위해 CPU를 사용하지 않는 프로세스의 데이터를 메모리에서 다른 저장 장치로 내보내고 CPU를 사용할 프로세스의 데이터를 메모리로 로드하는 것

지금은 사용하지 않는다
메인 메모리가 충분히 커서

 

 

📌 질문
multy processing은 multy programming이어야 할까?
지금은 yes
과거는 no
여러 개의 프로세스를 돌리지만 메인 메모리에는 현재 시행되는 process만 담고 있었다.
스케쥴링되며 메인 메모리에 들어오며 나가게 될 때,Swapping

0-2. Process가 유용한 이유?

Design-time entity & run-time entity

 

✍ run-time entity

OS가 관리하는 단위
수행의 주체
CPU나 memory나 IO device를 할당하는 주체이기 때문에

 

✍ Design-time entity

설명
SW system 개발할 때

1. 설계
   요구사항 명세서 => 설계(decomposition) => tasks(설계 결과로 나오게 됨)
2. 구현
   tasks => 구현 => programms
   이 프로그램이 OS에 의해 수행된다
   이 각각이 process가 되는 것.

 

결국 설계 단계에서 만든 tasks들이 OS process와 1:1로 mapping되어 수행된다
OS가 run-time entity로 process를 가지고 있기 때문에

 

 

 

 

 

 

1. Process 구현하기

1

process를 data structure로 구조화하려면
메모리 컨텍스트, 하드웨어 컨텍스트, 시스템 컨텍스트를 구현하면 된다.
가장 먼저 고려 : system context

커널이 process를 위해 뭘 유지해야 하나?

OS는 process의 정보를 유지한다
그리고 이 정보를 process control block(PCB)라고 부른다

process의 id와 자원 할당에 필요한 유용한 정보들을 가지고 있다.
PCB가 여러개 있으면 이를 또 잘 관리해야 한다 => array로

이렇게 분리된 array를 process 케이블이라고 부른다

하지만 array 방식을 사용하면 지원할 수 있는 process가 제한될 수 있다.
linked list를 이용해서 구성하는 방식으로 해결할 수 있음.

 

2

state transition
state라는 것은 process가 수행하기 위해 기억해야 할 정보를 얘기한데 이 state는 그게 아니다.
어떤 상태에 있는지에 대한 내용임.

프로세스의 생명 주기(Process Life Cycle)
프로세스가 생성되었을 때 부터 종료될 때 까지 발생하는 일련의 상태 변화.

ready상태에 있는데 이런 애들이 여러개 있다면
queue를 구현
ready 상태에 있는 process를 묶어서 queue로 구성하고
ready queue, ready list라고 부른다,
이 queue 안의 노드에서는 process control block, 이를 linked-list로 연결하면 ready queue를 쉽게 구현할 수 있다.

 

Ready Queue
Ready 상태의 프로세스들을 관리하기 위한 queue 형태의 자료 구조
일반적으로 PCD들을 Linked List로 연결하여 구현

 

waiting 상태
이벤트가 발생하지 않아 CPU를 내주고 대기하고 있는 상태.
다시 원하는 이벤트가 발생하면 다시 Ready에 들어간다.
여러 개의 process가 있을 수가 있다.
여러 개의 process가 waiting하는 이유는 다 다를 수 있음.
따라서 OS는 waiting 이유에 따라 별도의 큐를 사용한다 => 이걸 OS가 algorithemic하게 해야 한다

ready 상태는 ready queue를 만들어야 되고
wait는 wait queue를 만들어야 한다

 

✍ 상태전이는 어떻게 발생하는가?

ready 상태에서 running상태로 가려면 OS 스케쥴러가 일을 수행해야함
running -> ready : 인터럽트가 발생해서 CPU를 빼앗기고 ready로 간다
waiting => ready :원하는 event가 발생하면 가게 된다.

 

내용 정리
state transition은 process를 여러 상태로 이동시키는 것
각 상태에서는 queue가 정리한다.
waiting 상태에서는 IO 디바이스별로 디바이스 큐가 따로 구현되어있다.

 

 

 

 

2. Process Scheduling

process들이 fair하게 CPU를 공유할 수 있도록 다음에 수행시켜야 할 process를 선택하는 작업

• fair해야 하고 : fair는 상대적. 여기서 fair은 모든 process들이 언젠가는 CPU를 할당받을 수 있을것! 이라고 정의함
• CPU protection을 시행해야 한다 : cpu를양보했기 때문에 문제가 발생하지 않게

결국 OS 스케쥴러는 어떤 상황이 발생해서 CPu를 넘겨줘야 할 때 어떤 process에 넘겨줄 것인가를 생각해야 한다

OS 스케쥴러를 구현할 때는 policy와 mechanism을 구분할 필요가 있다.
그 결과로 스케쥴러는 두 단계로 구성된다.

 

2-1. 운영체제의 스케쥴러를 구성하는 Policy와 Mechanism

Poiicy : 다음에 수행될 프로세스를 선택하는 기준(Scheduling Policy)
Mechanism : CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 방법(Dispacher)
Policy는 다음에 공부한다고 하심.

 

✍ Mechanism

dispacher을 생각하면, 다음에 어떤 놈이 올지은 모르겠지만 현재 process와 다른 새로운 process가 내려온다고 볼 수 있음

Dispacher
무한루프를 돈다
주어진 process를 어느 정도 돌린다
그만 돌리라는 명령이 오면 프로세스를 중단
그와 동시에 돌리던 process 상태를 안전한 곳으로 대피를 시킨다
그리고 나서 OS가 선택해둔 process를 수행시킨다.
그 때! 저번에 수행하다가 남겨둔 내용을 load하고 수행시킨다.

스케쥴링 policy와는 무관하게 기계적으로 돌아간다.
이게 cpu를 관리하는 가장 핵심적인 기능.

 

📌 질문
dispacher은 능동적일까 수동적일까?
user process가 CPU를 가지고 잘 돌다가 dispacher이 시행되고 다른 process가 돈다
user process, 여기서 OS로 여기서 다시 user process로 컨트롤된다
어떻게 유연하게 이렇게 옮기면서 기능할 수 있을까?
이 메커니즘은 하드웨어에서 가능하다.
control을 유저 -> 커널 -> 유저
이런식으로 넘기려면 저번에 배운 인터럽트를 이용하면 된다

 

mode change
유저 -> 커널 -> 커널 모드 함수인 dispatch가 돈다
이 사이 interrupt mechanism을 사용하면 됨,

따라서
어떻게 control이 user에서 dispatch로 넘어가는가 == 어떻게 커널로 들어가고 나오는가
와 같다. mode change와 interrupt mechanism이 결합된 것

 

 

어렵지만 너무너무 재밌구만🤩