[운영체제] 제한적 직접 실행(Limited Direct Execution)

본 내용은 [Operating Systems : Three Easy Pieces]를 참고하였습니다.

 

OS는 물리적인 CPU를 공유하고 싶어하는데 이 때 사용되는 개념이 time sharing이다.

 

Problem 1 : Restricted Operation

만약 프로세스가 disk의 정보를 받으려 하거나, CPU와 memroy와 같은 resource를 접근하려 한다면 보안과 안정성에 큰 문제가 생길 수 있다.

 

해결? --> User mode와 Kernel mode로 나눈다.

- User mode : Application들은 hardware resources에 완전한 접근을 할 수가 없다.(제한됨)

- Kernel mode : OS 는 모든 resource 들에 대해서 접근을 할 수가 있다.

 

이 때 나오는 개념이 바로 System Call 이다.

 

System Call

 

kernel로 하여금 user program에 주요 기능을 제공해 주는 것이다.(file system 접근, process 생성 및 소멸, 다른 process와의 communication, memory 할당 등)

 

- Trap instruction : 사용자 프로그램이 처리할 수 없는, OS가 처리해야 할 특정 이벤트가 발생했다는 것이다.

이 때, user mode에서 kernel mode로 진입을 하게 된다.

 

- Return-from-trap instruction : 해당 system call 을 하였던 user program으로 돌아오는 것이다. kernel mode 에서 user mode가 된다.

 

그렇다면 trap은 OS에서 어떤 code를 수행해야 할지 어떻게 알 수 있을까?

이 때, trap table과 trap handler, system-call number 라는 개념이 등장한다.

모든 system call 들은 각자 할당된 고유의 number가 있는데, 따라서 user code에서는 해당 system-call number를 register에 올려야 한다.

 

system call 과 관련된 내용은 후에 Project#1 이라는 내용으로 다시 정리하도록 한다.

 

 

Problem 2 :Switching Between Processes

 

두 번째 문제는 process간의 switch를 위해서 OS가 어떻게 CPU에 대한 통제를 하느냐이다. 

여기서 협조적인 방식(A cooperative Approach)와 비협조적인 방식(A Non-Cooperative Approach)가 있다.

전자는 system call을 기다리는 것이고, 후자는 OS가 이 과정을 control 해버리는 것이다.

 

먼저, cooperative approach를 먼저 살펴보자.

system call을 기다린다고 했는데, 이게 과연 무슨 의미일까?

 

Process들은 yield라는 system call을 통해 주기적으로 CPU에 대한 점유를 포기하게 된다.

하지만 이는 구식이고, 만약 process가 무한루프에 빠지게 되면 컴퓨터를 리부팅해야하는 문제점이 있다.

 

Non-cooperative approach를 살펴보자.

이 방식에서는 timer interrupt를 발생시킨다.

booting 과정에서 OS 는 timer를 시작하는데, 일정 시간(몇 밀리초에 이를 정도로 매우 짧음)마다 interrupt를 발생시킨다. 그래서 interrupt가 발생하면 현재 실행중인 process가 halt되고, interrupt handler가 실행된다.

현대 운영체제의 방식이기도 하다.

 

여기서 Scheduler라는 개념이 등장한다.

Scheduler는 현재의 process 를 계속 실행할지, 아니면 다른 process로의 context를 할지를 결정한다.

만약 scheduler의 decision이 switch를 한다는 것이면 OS 는 context switch를 한다.

 

 

Context Switch?

 

low-level의 어셈블리어로 이루어져 있다.

현재 process의 여러 정보들을 이 process의 kernel stack에 저장한다.

그 후 다음에 실행될 process의 kernel stack을 복구하고, switching이 일어난다.

//문제제기 및 피드백 언제든지 감사히 받겠습니다.