Operating System Overview

OS의 주요 목적

1. Convenience 편리성

2. Efficiency 효율성

3. Avility to evolve 진화

 

 

OS의 역할

Mediator

프로그래머에게 시스템 사용을 위한 편리한 인터페이스 제공

- 응용프로그램의 실행을 제어하고 인터페이스 역할

- 프로그램 생성, 파일 관리 및 I/O 장치 제어, 라이브러리 또는 유틸리티 지원

- 프로그래머의 하드웨어 세부 정보를 숨김

 

👍Resource Manager

- 데이터의 이동, 저장, 처리를 위한 리소스들을 OS가 관리한다.

 

 

OS의 발전, 진화

OS의 요구사항의 핵심을 이해하기 위해

 

1) Serial Processing (1940-1950)

computer

- 컴퓨터가 진공관으로 이루어져 있었다.

- punched cards와 tape로 입력을 받았다.

- lights와 프린터로 display

 

⭐️OS

OS가 존재하지않았다. 그렇다면? Human operator가 OS 역할을 대신했다. (Job-to-Job transition)

사람이 카드를 로드하여 프로그램을 실행하였다.

 

소스코드는 punch card를 사용하여 어셈블리 또는 고급언어로 입력되엇다.

이 소스 코드를 해석하기 위해서 컴파일러가 필수적이었다.

이 때의 모든 컴퓨터 활동은 순차적이었다.

 

⭐️Problems

매우 비싼 자원(진공관 등)을 사용했기 때문에 매우 비효율적이었다.

Job-to-Job transition이 매우 느렸다.

 

1. Scheduling time 

- 시간 할당이 짧거나 긴데, 시간을 딱 맞추기가 어려웠다. -> 스케줄링 문제 !

- 결과적으로 낭비되는 컴퓨터의 처리 시간이 생겼다.

 

2. High Setup Time

- 컴파일러를 로드하고 언로드 할 때의 추가적인 오버헤드가 발생한다.

- 순차적으로만 처리가 가능했다.

-> Setup Time이 오래걸렸다 !

 

 

2) Simple Batch Systems

OS의 등장!

 

⭐️Goal 목표

- 속성이 유사한 작업을 batch 일괄 처리하여 Setup Time을 단축하는 것이 목표!

- Automatic job sequencing

 

⭐️Monitor

첫번째 batch OS

-  항상 메인 메모리에 상주하고 있어야했다. (Resident monitor)

-  tape boundary에서 한번에 하나씩 job을 읽을수 있다. (queue)

- Special 카드는 할일을 표시 ! (JCL: Job Control Language)

 

⭐️바람직한 기능

- 모니터를 위한 메모리 보호가 필요하다 !

왜냐, 다른 작업에 관여하는 버그가 발생했다. 따라서 프로그램이 실행되는 동안 다른 Job들이 모니터에 접근하지 못하게 하는 보호가 필요했다.

 

- System Timer가 필요하다 !

왜냐, 한 작업이 시스템을 독점하면 안되게 때문에

 

- 특권이 있는 명령어가 필요하다 ! = 레지스터가 필요하다.

사용자 프로그램이 I/O를 수행하고자 할 경우, 모니터가 이에 대한 작업을 수행하도록 요청할 수 있는 명령어가 필요하다.

I/O 명령어는 privileged instruction 이기 때문에

 

- I/O device controller 가 필요하다 !

I/O 디바이스는 굉장히 느리기 때문에 제어를 위해 컨트롤러를 만들어야했다.

I/O 디바이스 컨트롤러에도 프로세서가 있기 때문에 I/O 디바이스와 CPU 동시 실행이 가능하다.

각 컨트롤러에는 로컬 버퍼가 있기 때문에 컨트롤러가 CPU에 인터럽트를 발생시켜서 작동이 완료 되었음을 알린다.

 

- synchronous I/O : 동기식 I/O

다음 코드에 영향을 미치기 때문에 완료될 때까지 CPU가 기다려야 했다.

- asynchronous I/O : 비동기식 I/O

비동기식 I/O는 CPU가 완료를 기다리지 않고 실행 가능했기 때문에 문제가 없다 !

-> 동기식 I/O가 문제

 

⭐️Problems !!

1. Card reader very slow

- 자동으로 작업 순서를 지정해도 I/O 디바이스가 프로세서와 비교했을 때 매우 느렸다

2. Cpu is often idle 종종 쉰다..

- synchronous I/O와 CPU는 겹칠 수 없기 때문에 !

- 이때는 single job 처리만 가능했기 때문에 기다릴 수 밖에 없었다.

 

 

--> 해결을 위해 등장한것

 

3) Multiprogrammed Batch Systems

⭐️Goal 목표

CPU의 utilization을 높이자 !!!

-> 멀티프로그래밍을 하자

여러 Job들이 이제 메인 메모리에 동시에 저장된다. (왜? CPU의 idle을 피하기 위해서)

 

⭐️Uni-programming

- I/O 명령을 기다림 !

 

⭐️Multi-programming

- 다른 job으로 변경 가능 !

-> utilization 향상

 

⭐️Problems

1. Relocation

- 다수의 job들이 메모리에 올라와서 프로그램 시작위치가 바뀐다 !

- 우리는 실제로 어떤 다른 프로그램이 메인메모리에 상주할지 모르는데, 프로세서 활용을 극대화하려면 !

- swap-in, swap-out (swap area) 을 통해 프로세서의 utilization을 극대화한다 !

 

2. Memory Protection

- 모니터의 메모리를 침범하거나 다른 job들의 메모리를 침범하는 문제가 있었다.

 

⭐️바람직한 기능

- MMU (Memory Management Unit) : Relocation의 문제 해결

logical address를 pyhsical address로의 변환이 필요하다.

이를 가능하게 하는 레지스터가 Base register, Bound register (= limit resgister)

Base register가 시작주소, Bound register를 넘어가는지 비교해서 확인한다.

-> 주소 개념의 도입

 

⭐️example

utilization을 계산해보자!

CPU Usage: job1 70% 5min, job2 10%15min, job3 10% 10 min

- Uniprogramming

1/6 * 70% + 3/6 * 10% + 2/6 * 10% = 대략 20%

- Multiprogramming

1/3 * 70 + 1/3 * 10 + 1/3 * 10 = 대략 30%

 

 

4) Time Sharing Systems

IC회로의 속도가 오르고 가격이 싸졌다.

이제 여러 사용자에게 CPU를 switch 해주는게 목표 ! -> Time sharing

more productive

processor time을 multie user들이 공유하도록 !

Batch Multiprogramming 의 목적은 프로세서의 사용을 극대화하고 JCL 을 사용한다.

Time Sharing은 응답 시간을 줄이고 터미널 을 사용한다.

 

- 모든사람이 터미널을 사용할 수 있다.

- 여러 사용자가 한번에 같은 machine을 사용할 수 있도록한다.

switch가 자주 발생한다.

각 job에 Time slice 할당 (preemption 선점) : 시간이 지나면 CPU가 뺏어온다.

Time slice가 만료될 때마다 다음 job이 실행된다.

 

- data 를 지키기 위해서 file system이 등장하게 되었다.

 

평균 응답 시간

평균 종료 시간

 

ex) CTS, MULTICS, UNIX

 

 

Processes

Memory management

Information protection and security

Scheduling and resource management

System structure