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

 

0. Process Scheduling

 

✍ Dispacher

유저 프로그램과 유저프로그램 사이에서 == 프로세서 A에서 B로

컨트롤을 넘겨주는 역할을 한다.

 

dispacher가 시행된다는 것은

1. 커널로 excution control이 진입하는 것.
2. 그리고 user process로 excution control이 넘어가는 것.

 

어떻게 user mode excution에서 커널모드 excution으로 컨트롤이 넘어갈까?

인터럽트

 

코드를 작성할 때 함수가 넘어가는 것 : function call

하지만 dispacher가 시행될 시 user mode 함수가 아닌 커널 모드 함수가 실행되어야 한다.

커널 모드 함수가 시행되려면 모드 체인지가 일어나야 하는데

모드 체인지가 일어나려면?
=> 인터럽트가 있어야 한다!!
=> 인터럽트가 발생하면 반드시 유저 모드에서 커널 모드로 넘어간다

 

 

OS는 우리가 사용하는 라이브러리 코드처럼 passive한 느낌.
그냥 커널 모드에서 실행되는 함수들의 집합체라고 생각하면 된다.
우리는 이 커널 함수들을 System Call 함수라고 부른다

System Call | 운영체제의 커널이 제공하는 서비스를 응용 프로그램에 요청하기 위한 인터페이스

이 커널에서 수행되는 함수 중 인터럽트 서비스 루틴이 존재한다
=> 커널 함수에는 system call을 구현하는 함수와 인터럽트 루틴이 들어있다

 

 

프로세서가 커널 모드와 유저 모드를 구분하는 방식

Process Status Word 레지스터 안의 특정 비트를 Mode Bit로 사용한다
다시 말해 인터럽트가 발생하면 하드웨어적으로 process mode bit가 무조건 0으로 세팅되게 되는것
=> 인터럽트의 하드웨어적인 동작.

그러면 dispacher가 수행된다고 하는 이야기는
커널 함수 중 하나인 dispacher가 불려지는 말.
== 인터럽트가 필요하다

 

 

dispatch 호출 방법

Non-preemptive Scheduling | 프로세스가 자발적으로 CPU를 양보하여 다른 프로세스를 수행하는 스케쥴링

1. cpu를 스스로 다른 process에게 넘겨주는 법
   언제? : io같은걸 요청했는데 준비가 안됐을 때. 다른곳에 넘겨준다
   구현방법 : trap을 사용하면 된다.
2. 스케쥴링 외에도 발생한다.
   만약 math 라이브러리가 필요하면 이를 호출함녀 된다.
   operating system이 제공해주는 서비스가 필요하면 커널 함수를 호출하는 것
   trap을 호출한다.

Preemptive Scheduling | 운영체제가 강제로 프로세스로부터 CPU를 빼앗아 다른 프로세스를 수행하는 스케쥴링

1. time sharing scheduling같은 것을 할 때 필요
   구현방법 : timer 로 인터럽트를 걸어주면 된다.
   촉발 : 하드웨어 interrupt에 의해 촉발된다

질문
현재 수행 중인 프로세스 id를 커널 함수가 수행 중일 때 얻어오면 뭐가 나올까?
=> 수행의 주체는 여전히 system call을 호출한 사용자 프로세스이다. 따라서 이 id값이 나온다
다시 말해
Kernel Mode Execution이 일어날 때 수행의 주체가 되는 프로세스는
system call을 호출한 사용자 프로세스이다.

Process

state(Context)

이 안에는 메모리에 들어가 있는 요소들,
data나 stack이나 code 세그먼트들이 포함된다

• 메모리 context
• 하드웨어 context
• 커널 context

thread of control

state 중에서 stack은 우리가 state에 포함시키지 않고 thread of control에 포함된다고 본다.
stack은 해당 프로세스의 run time context다

프로세스가 유저 모드에서 수행될 때는 유저 모드 스택을 사용하고
커널 모드에서 수행될 때는 커널 모드 스택을 사용한다.

context Switching

현재 수행 중인 프로세스의 state를 저장하고 다음 수행될 프로세스의 state를 불러오는 작업

dispatch는 현재 수행 중인 프로세스의 state를 안전한 곳에 대피시킨다.
그 후 스케쥴러가 골라준 다음 프로세스의 state를 가져와야 한다.
무슨 state를 골라서 대피시켜야 할까?
일단 cpu register은 대피시켜야 한다.
커널 context는 각 process별로 항목을 따로 두기 때문에 대피하지 않아도 된다

메모리리는? - 3가지 옵션

1. 전혀 대피시키지 않는다
   • batch시절에는 대피시키지 않아도 된다.
2. 몽땅 대피시킨다
   • unit 프로그래밍을 할 때 필요.
   • 굉~~장히 느리다
3. swapping
   • 모던 os

질문
CPU register은 disk로 대피시키는 것인가?
=> 일반적으로 한 단계 아래의 저장 장치로 데이터를 대피시키기 때문에 Cpu Register은 main memory로 대피시킨다

인터럽트가 걸리면
현재 수행중인 프로세스의 return주소를 stack에 저장한다
그런데 이 주소를 어디서 가져오나?
PC(프로그램카운터)에 있다.

인터럽트 서비스 루틴 초반에 뭘 해야 하나?
process의 cpu register값을 대피해야 한다
stack에 넣기
그 후 서비스 루틴이 수행된다.
만약 대피하지 않고 인터럽트 루틴의 매인 로직을 처리해보리면 cpu register값들이 덮어져버린다.

인터럽트가 발생했을 때

스택의 PSW값과 interrupted process의 return 주소를 넣는 일은 누가 할까?

1. 먼저 PSW를 stack에 하드웨어적으로 저장하고
2. 현재 수행 중인 instruction의 return주소를 기억한다.

인터럽트가 발생하면 micro process가 PSW를 stack에 넣고 PC register을 pop해버린다.
이게 하드웨어적인 처리

스토리라인
dispacher가 수행되려면, interrupt가 필요하다.
interrupt가 걸리면
stack에 PSW와 PC값이 저장된다
그 후 interrupt service routine이 수행된다.
수행되자마자 바로 현재 cpu register값을 다 stack에 대피시켜야 한다.
대피하지 않고 메인 로직을 처리하면 안됨,