운영체제의 기초 - 4. Processes and Threads 1

Process Concept(1)

Process는 OS 위에서 프로그램을 수행시키는 기본 주체(run time system의 수행 주체)

run time system의 수행 주체는 CPU나 여러가지 자원을 할당 받는 주체

OS의 관점에서 Process 는 가장 중요한 단위다 

Decomposition: 복잡한 문제를 단순한 여러 개의 문제로 나누어 처리하는 방법론

이 Decomposition의 unit이 process임

OS를 만들 때 핵심기술 2가지

1. Abstraction(추상화)

2. Decomposition(분해)

Process: Program in execution 수행중인 프로그램

프로세스가 수행이 되려면 3가지 정보를 유지하고 있어야 함

이 정보들이 process state가 됨

1. Memory

- Code: 기계어

- Data: 프로그램의 전역 변수 내용 (global 변수)

- Stack: 프로그램의 지역 변수 내용과 함수 호출을 위해 필요한 내용 (local 변수)

2. CPU

- Register Value

3. Per-Process Kernel information

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

OS 내부에서 Process를 어떻게 구현해 내지? 하는 관점에서 살펴보면 공부에 도움이 많이 됨

Multiprogramming: 메인메모리에 여러개의 Active한 Process가 load되어 있는 것

Uniprogramming: 메인메모리에 Active한 Process가 1개 있는 것

Multiprocessing: CPU가 여러개의 Process에 의해서 multiplexing(다중화)되는 것

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

프로세스는 왜 유용한가? (2가지 측면)

1. run-time entity: OS 관리하는 단위고 수행의 주체이고 CPU나 메모리나 I/O device를 할당하는 주체기 때문

2. Design-time entity: 

SW system 개발

1. 설계: 요구사항 명세서 =(입력)=> 설계 =(출력)=> {Tasks}

            Task: 설계해야할 시스템의 한 부분을 독립적으로 구성하는 요소들

2. 구현: {Tasks} =(입력)=> 구현 =(출력)=> {Programs}

구현의 출력부분인 program이 process가 됨

즉, 프로그램을 할 때 각 task를 하나의 program으로 만들어서 process로 구현할 수 있게 됨

결국, 설계단계 결과물로 만든 Task들이 OS process와 1:1로 매핑이 되서 바로 수행이 된다는 것

이게 왜 가능하냐 OS이 이미 run-time entity로써 process를 갖고 있기 때문에 설계 결과로 나온 Task를 C로 코딩하여 컴파일하여 Process 매핑시키면 바로 구현이 된다는 말임

복잡한 SW system을 개발하는 일은 실제로 설계가 어려운 것이지 구현은 덜 어려운 것이다.

구현이 덜 어려운 이유는 OS이 decomposition이라는 방법론을 통해서 산출된 설계물들을 바로 run-time entity로 매핑시켜 수행시킬 수 있는 능력을 갖고 있기 때문

Process Concept(2)

Process를 OS이 어떻게 구현하는지 공부를 해보겠습니다.

프로그램을 구체화 시키는 방법

Program = Data Structure + Algorithm

Process state or Context: Collection of three types of contexts

- Memory context: Code segment, data segment, stack segment, heap

- Hardware context: CPU registers, I/O registers

- System context: Process table, open file table, page table

Process 개념을 Data Structure로 OS 안에서 어떻게 가지고 있나를 보면 됨

Process를 Data Structure로 구조화 시키려면

3가지context (memory, H/W, system)를 구현해 놓으면 됨

가장 먼저 고려해야할 점이 System Context

OS kernel이 Process를 위해서 어떤 정보를 유지해야 하나?

각 Process들의 정보들을 Process Control Block(PCB)이라고 함

- Process ID

- Process Scheduling (자원할당에 필요한 유용한 정보들)

우리가 얘기하고 있는 OS은 Multiprocessing되는 Time-sharing OS임.

당연히 한 OS 안에 Process가 여러개 있을 것이고 PCB도 여러개 있을 것임

PCB가 여러개 있으면 이것들을 잘 관리하기 위해서는 어떻게 만들면 될까요?

간단하게 말해보면 array로 만들면 됨

OS내부에 시스템을 wild하게 존재하는 PCB들에 array를 Process Table이라고 함

이 array방식을 사용하면 OS이 제공할 수 있는 Process의 개수가 제한된다는 단점이 있음

이 단점을 극복하려면 어떻게 하면 될까?

link-list같은 형태로 구성하면 됨. 이런것들을 우리가 생각해 볼 수 있음

Process를 표현할 자료구조로써 PCB과 Process Table을 공부했음

State Transition을 배워보겠음

Process를 어떻게 정의했죠? 어떤 State 위에서 수행되는 execution stream이라고 했잖아요? 

그때 state라는 것은 그 process가 수행하기 위해서 기억해야 할 정보들을 말함

그러나 여기서 State는 다름. 어떤 Process가 어떤 상황에 있는가?를 의미함

 

프로세스의 생명 주기 (Process Life Cycle)

프로세스가 생성되었을 때 부터 종료될 때 까지 발생하는 일련의 상태 변화

내가 Ready 상태에 있는데 나 말고 여러개가 있으면 Data Structure관점에서 볼 때 어떻게 구현해야 할까?

어떤 동일한 element(요소)가 여러개 있으면 무슨 Structure를 이용하나요? 큐를 구현해야죠?

Ready 상태에 있는 Process들을 묶어서 우리가 큐로 구성을 하고 그 큐를 Ready queue(Ready list)라고 함

Ready queue의 각 node들로는 뭘로 하면 될까? 무슨 Data Structure를 쓰면 될까?

아까 우리가 만들어 놨던 PCB을 link list block으로 연결하면 Ready queue를 쉽게 구현할 수 있음

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

Ready 상태에서 CPU를 받게되면 Running상태가 됨

Q. Waiting 상태의 프로세스가 여러 개 있을 수 있는가?

A. 그렇다. 하지만 Waiting의 이유는 프로세스마다 다를 수 있다.

    OS는 Waiting 이유에 따라 별도의 큐를 사용한다.

결국 OS은 무엇이냐? 프로세스가 생성이 되면 PCB를 하나 할당하고 (물론 다른자원도 할당함) 

그 프로세스를 일련의 조건에 따라 다른 상태로 전이 시키는 것 (이것이 OS가 알고리즘학에 해야 하는 일)

상태 전이를 구현하기 위해서는 Ready에서는 Ready queue를 Waitng에서는 Waiting queue를 만들어야 함

조금 더 구체적으로 상태 전이가 어떻게 나타나는지 보겠음

Ready --> Running: OS Scheduler가 수행을 해야 함

Running --> Read: 잘 수행이 되다가 어떤 interrupt가 발생해서 cpu를 빼앗기는 상황

Running --> waiting: 어떤 프로세스가 I/O나 waiting하는 함수를 호출

waiting --> Ready: 자기가 원하는 이벤트가 발생하면 돌아감

이와같이 OS은 state별로 Data Structure를 만들어 놓고 여러 프로세스에 대해서 해당하는 이벤트가 발생하면 state transition을 drive하는 것

이것이 OS의 Process management라고 할 수 있음

내용 정리

State Transition: 프로세스들을 여러가지 상태로 이동시키는 것

각 state에는 queue가 존재

waiting process위에서는 각 I/O device별로 device 큐가 별도로 존재하는 형태가 됨

Process Scheduling(1)

Process Scheduling 행위의 목적: 각 프로세스들이 fair하게 CPU를 share할 수 있도록 다음에 수행시켜야 할 프로세스를 선택하는 작업

fair하게 Scheduling한다는 것은 무엇일까?

fairness: 각 프로세스들이 언젠가는 CPU를 할당받아 수행할 수 있게 한다

protection(보호): 내가 CPU를 사용하다가 다른 프로세스에 양보했을 때 내 프로그램에 문제가 생기면 안되겠죠?

운영체제의 스케줄러를 구성하는 Policy와 Mechanism

Policy: 다음에 수행될 프로세스를 선택하는 기준 (Scheduling Policy - 교체가능함)

Mechanism: CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 방법 (Dispatcher - 공통부분, policy와 무관)

Dispatcher: 무한반복{

한동안 프로세스를 실행하다가

중단하고 그 때 상태를 저장한 후

다른 프로세스의 상태를 로드한다 }

Dispatcher: 유저 프로세스가 CPU로 프로그램을 잘 돌다가 갑자기 Dispatcher코드가 프로세스 수행을 중단시키고

Dispatcher코드가 돌아야 됨. 그리고 나서 다른 프로세스가 돌아야 함

CPU의 Control이 유저 프로세스에서 -> Dispatcher(OS)로 -> 유저 프로세스로 넘어가야함

---

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=634

출처 - http://snui.snu.ac.kr/ocw/index.php?mode=view&id=635