중간 내용 정리

중간 내용 정리

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

Process는 2가지 요소가 있음

1. State

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

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

1. Memory Context

2. Hardware Context

3. System Context

용어

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

   - 2개 이상의 프로그램을 주기억장치에 기억시키고, 중앙처리장치(CPU)를 번갈아 사용하면서 처리하여 컴퓨터 자원을 최대로 활용하는 처리기법

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

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

   - 하나의 컴퓨터 체계에 2개 이상의 중앙처리장치를 설치하여 이들 중앙처리장치에서 병렬로 작업을 처리하는 것을 의미하거나, 한 체계 내에서 여러 개의 프로세스가 동시에 수행되는 것을 말한다.

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

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

프로세스 구현하는 방법

1. System Context

# Process를 표현할 자료구조로써 PCB와 Process Table

PCB(Process Control Block): 각 프로세스들의 정보들

Process Table: OS내부에 시스템을 wild하게 존재하는 PCB들에 array

단, array 방식을 사용하면 프로세스 개수가 제한된다는 단점이 있음. 이럴 경우 linked-list로 구성하면 됨

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

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

프로세스가 생성되었을 때 부터 종료될 때 까지 발생하는 일련의 상태 변화 (New, Ready, Waiting, Running, Terminated)

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

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

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

A. 그렇다. 하지만 Waiting의 이유는 프로세스마다 다를 수 있다. OS는 Waiting 이유에 따라 별도의 큐를 사용한다.

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

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

Policy: 다음에 수행될 프로세스를 선택하는 기준 (Scheduling Policy)

Mechanism: CPU를 한 프로세스에서 다른 프로세스로 넘겨주는 방법 (Dispatcher)

Dispatcher: 유저프로그램과 유저프로그램이 수행되는 중간에 개입을 해서 CPU를 Process A에서 B로 넘겨주는 역할을 함

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

즉, OS는 Kernel mode에서 수행되는 라이브러리 함수들의 집합체다.

커널 함수라고 하는 것은 System Call을 구현하는 함수들과 interrupt service routine들로 구성되어있다.

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

Process Status Word(PSW) 레지스터 안의 특정 비트를 Mode Bit로 사용한다.

0: 커널모드,  1:유저모드

Dispatcher를 호출하는 방법 (2가지)

1. Non-preemptive(비선점) Scheduling: 프로세스가 자발적으로 CPU를 양보하여 다른 프로세스를 수행하는 스케줄링 (S/W interrupt(Trap)에서 촉발)

2. Preemptive(선점) Scheduling: 운영체제가 강제로 프로세스로부터 CPU를 빼앗아 다른 프로세스를 수행하는 스케줄링 (H/W interrupt에서 촉발-타이머하드웨어)

커널함수를 호출하기 위해서 S/W interrupt가 사용되면 system call 발생

Q, Kernel Mode Execution이 일어날 때 수행의 주체가 되는 프로세스는?

A. System Call을 호출한 사용자 프로세스이다.

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

Context saving: 지금 중단된 프로세스의 state들을 안전한 곳으로 대피시키는 것

1. 전혀 대피시키지 않는다 (ex: Multiprogrammed batch system)

   - CPU를 빼앗긴다 하더라도 메모리값은 유지되기 때문에 전혀 문제 안됨

   - 지금 당장 고민해야할 이슈는 아님

2. 전부 대피시키는 방법 (ex: unit programming할 때)

    - 메인 메모리에 하나의 프로세스만 올라가기 때문에 disk에서 나가고 새로운 프로세스가 들어옴

    - 속도 굉장히 느림

3. 메모리만 충분하다면 대피시킬 필요가 없지만, 가끔 over commit 됐을 때 (degree of multiprogramming 이 너무 큼)

    - 어쩔 수 없이 메모리 공간을 비우기 위해서 선택된 일부를 Disk로 보냄 (swap out)

3가지 중 H/W Context는 반드시 대피(CPU), 메모리는 필요한 경우 부분적으로 대패, 커널 Context는 냅둬도 된다

Q. CPU Register는 Disk로 대피시키는 것인가?

A. 일반적으로 한 단계 아래의 저장 장치로 데이터를 대피시키기 때문에 CPU Register는 Main Memory로 대피시킨다.

- OS 스케쥴러는 Policy부분과 공통적인 메커니즘 부분이 있다

- 메커니즘 부분이 바로 Context Switching을 담당하는 디스패쳐다

- 그 디스패쳐가 수행이 되려면 유저프로그램과 유저프로그램 사이에 mode change가 나서 수행이 되야 한다

API(Application Programming Interface): 계층(Layer)과 계층 사이의 통신을 위해 정의된 호출 규약

커널 안에 있는 함수를 호출하는 방법!을 System call

Layering Principle: 위의 계층은 아래 계층이 제공하는 기능만 사용할 수 있으며 반대의 경우는 발생하지 않아야 함

OS는 5조각으로 나눠져 있다

1. CPU를 관리하는 Process Scheduler

2. File System

3. Memory

4. I/O

5. Network

요약

한 프로세스에서 다른 프로세스로 넘어갈 때 커널이 개입한다고 했죠?

그 커널이 개입을 해서 수행되는 코드가 Dispatcher코드였고 이것은 Context Switching을 한다는 것이었습니다.

Dispatcher가 수행되기 위해서 하드웨어적 메커니즘인 interrupt가 필요함

그런데 interrupt 타입에는 두가지가 있습니다.

H/W interrupt와 S/W interrupt

H/W interrupt에 의해서 CPU를 빼앗기게 되면 그것을 우리가 preemptive Scheduling이라고 했음

자기의 의지와 상관없이 겸손하게 CPU를 빼앗기는 것 preemptive Scheduling이 발생하려면

OS 로직이 돌아야하기 때문에 asynchronous하게 H/W interrupt가 필요함

S/W interrupt에 의해서 발생하는 스케줄링은 Non-preemptive Scheduling임

어떻게 해야 발생하느냐? I/O를 기다리는데 I/O가 끝나려면 오래 걸릴 거 같다 

그렇다면 CPU를 양보해야 겠죠. 그럴때 오히려 OS에게 S/W interrupt를 걸어서 CPU를 가져와라라고 얘기하는 것

 

가장 중요한

Interrupt와 Interrupt service routine을 이용해서 Context가 교체되는 것을 배웠음

Parent Process: Process Cloning을 초래하는 기존의 Process

Child Process: Parent Process로부터 만들어지는 새로운 Process

Child Process가 생성되는 과정

- Parent Process가 Child Process를 만들기 위해서는 fork() system call을 호출함

- OS이 fork()를 호출한 Parent Process를 완전히 딱 중단시킴

- 그리고 걔가 가지고 있는 Context들을 snapshot(사진) 찍음

- 사진 찍은 Context를 그대로 copy함 

Shell 또는 CLI (Command Line Interpreter)

사용자가 입력한 명령어를 입력으로 받아들여 새로운 프로세스를 수행시키는 프로그램

COW (Copy on Write): Process Context를 fork()시점에서 복사하지 않고, Data Segment에 새 값이 쓰여질 때 복사하는 기법

프로세스 수행을 종료하는 방법 (2가지)

1. 정상적인 exit()을 호출해서 죽는 방법

2. 비정상적으로 자기가 뭔가 잘못했을 때 Parent가 kill 시키는 방법. abort() 하는 방법임

   아니면 signal을 보내서 죽이는 방법

시스템 전체를 설계하는데 사용하는 디자인 패턴을 'Architecture'라고 한다

Server Architecture

- Interative Server: 서버가 깨어나서 메세지큐에서 리퀘스트 받아다가 스스로 처리

- Concurrent Server: 메세지큐에서 리퀘스트를 받으면 그 일을 처리해주는 워커 프로세스(Child)를 생성하여 처리하게 함

Worker Process를 사용해 구현한 Concurrent Server의 단점

처리할 요청의 수 만큼 프로세스를 생성해야 하기 때문에 시스템에 큰 부담이 발생

 

Multithreading의 목적

Concurrency는 높이면서 Execution Unit을 생성하거나 수행시키는데 드는 부담을 줄임

Multithreading: 프로세스에게 부여된 자원을 이 여러개의 Thread들이 공유하는 형태

Thread의 구현을 위해 필요한 자료 구조

- Stack

- Thread ID (각 Thread를 명명할 수 있어야 함)

- Thread Control Block (TCB)

프로세스의 2가지 측면

- Design-time Process: 복잡한 시스템을 Decomposition하여 설계를 하게 되면 독립적으로 수행가능한 entity

- Run-time Process: OS가 자원을 할당하고 수행시키는 주체들

- Task: Design-time Process를 흔히 Task라고 부름 (설계의 결과물) - 프로세스에게 부여된 resource들 

Multithreading이 필요한 이유

1. 적은 비용으로 Concurrency(동시성)를 얻기 위해

   - response time을 줄이겠다 (응답의 Agility민첩을 높이겠다는 의미)

2. Massively Parallel Scientific Programming을 할 때 발생하는 오버헤드를 줄이기 위해

오버헤드가 적은 이유

- 프로세스는 놔두고 Thread만 여러개 생성

- 스택만 생성하기 때문에 메모리 요구량이 적다 (프로세스의 경우 여러 가지를 생성해야 함)

- 자기 자신 내부에 Thread만 추가 생성하면 된다 (fork할 필요 없음)

- Thread들이 프로세스 할당된 리소스들을 공유하는 장점 (그러나 동기화 문제 발생)

Multithreading의 장점 

1. 구현이 쉽고 경제적이다.

- 새로운 Thread 생성 시간도 적게 걸리고

- 메모리도 적게 차지하고

- Thread Context Switching이 훨씬 더 경제적인 Operation임

2. 반응시간을 빠르게 할 수 있다

Thread의 구현 형태 (3가지)

1. User-Level 구현: 커널이 전혀 모르게 살짝 구현하는 방법

2. Kernel-Level 구현: 커널이 100% 알고 구현하는 방법

3. Combined User-Level / Kernel-Level 구현: 두가지 섞어서 구현하는 방법