일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- Google Cloud Platorm
- Cloud Spanner
- AWS Certificate
- container
- AWS Database
- Google Cloud Platform
- 아마존웹서비스
- kubernetes
- AWS Solution Architect
- Google Cloud Platrofm
- Google Cloud
- AWS 자격증
- Compute Engine
- AWS
- playbook
- gcp
- Cloud Bigtable
- Kubernetes Engine
- Cloud Storage
- 앤서블
- Solution Architect
- ansible
- Cloud SQL
- VPC
- 리버스 프록시
- Reverse Proxy
- GKE
- Cloud Datastore
- Amazon Web Service
- Solution Architect Certificate
- Today
- Total
sungwony
[운영체제의 기초] Evolution of OS (1) 본문
이 포스트는 SNU에서 제공하는 운영체제의 기초 강의를 개인 학습용으로 정리한 포스트입니다
강의 목표
- 주요한 OS 기능을 배우고 실습한다
- OS 내부의 상호작용을 이해한다
- 더 나은 소프트웨어 개발 혹은 새로운 OS 디자인에 지식을 접목한다
1. OS의 발전 과정
- 50년대 초반 ~ 60년대 중반
- 60년대 중반 ~ 90년대 중반
- 90년대 중반 ~ 현재
Phase1 : 50년대 초반 ~ 60년대 중반
최초의 OS 등장의 배경
하드웨어는 매우 고가의 장비이고 인건비는 상대적으로 저렴하였다 (대표적인 컴퓨터로 팬실베니아의 애니악이 존재)
값 비싼 하드웨어를 효과적으로 활용할 필요가 있었다
Operator(사람)는 다음과 같은 역할을 수행하였다
1. 사용자로부터 카드 덱을 수령
2. 카드 덱을 컴퓨터 시스템에 로딩하고 수행
3. 수행 결과를 프린터로 출력
4. 출력된 결과물을 사용자에게 전달
현대의 OS가 수행하는 역할을 Operator가 직접 수행 => CPU 관점에서 굉장한 비효율
OS는 최초 Operator의 느린 Job-to-Job 전환 속도로 인한 컴퓨터 시스템의 비효율성을 해결하려는 필요성을 가지고 등장
CPU의 Utilization을 높이기 위한 노력의 일환으로 I/O Channel이 등장
기존에는 I/O Operation을 수행하는 동안 CPU는 대기해야 함
I/O Channel의 등장으로 CPU는 I/O의 시작과 종료에만 관심을 두개 함
이렇게 CPU에 I/O의 시작과 종료를 전달하기 위한 매커니즘이 인터럽트(Interrupt)이다
Synchronous I/O
: I/O의 결과가 다음 연산에 반드시 필요한 경우 (대체로 In 연산이 해당함)
Asynchronous I/O
: I/O의 결과가 다음 연산에 불필요 하여 다음 연산을 바로 수행할 수 있는 경우 (대체로 Out 연산이 해당함)
멀티 프로그래밍 Batch Monitoring
Active한 Job이 동시에 여러개 존재하는 것
Degree of Multiprogramming : 현재 메인 메로리에 존재하고 있는 Active한 Job의 개수
이를 구현하는 과정에서 다음과 같은 문제가 발생
- Memory Protection
: 하나의 Job이 다른 Job의 메모리 영역 또는 OS 메모리 영역을 침범하여 다른 프로그램에 영향을 미치는 오류를 개선하기 위함
- Momery Relocation
: Job의 시작 위치가 다양해 짐에 따라 임의의 주소에서도 문제없이 진행될 수 있어야 함
- Concurrent Programming
: 여러 Job이 수행되면 공유 자원이나 공유 데이터의 관리 문제가 발생
해결 방안
1. Memory Protection, Memory Relocation을 위해 Job의 시작점을 기록하는 Base Register 개념과 Job이 사용하는 메모리 크기인 Bound Register 개념을 도입하고 Job이 다른 영역의 메모리를 참조할 때 OS가 Protection Error를 반환
* 논리 주소(Logical Address) : 프로그램에 의해 CPU가 바로 생성하는 주소
물리 주소(Physical Address) : Base Register과 Bound Register를 바탕으로 변환을 거친 최종적인 메인 메모리 주소
-> MMU(Memory Managerment Unit)의 도입
1. MMU는 Software Mechanism / Hardware Mechanism?
MMU를 Software Mechanism으로 구현할 수도 있지만 불필요한 성능 이슈 및 Software로 개발된 MMU도 동일한 문제가 발생할 수 있기 때문에 Hardware Mechanism으로 구현되었다
2. OS관점에서 MMU는 transparent 한가 그렇지 않는가?
OS관점에서 MMU는 transparent 하지 않다. MMU는 Job의 Base Register과 Bound Register를 제공받아야 한다. OS는 MMU에 Job의 정보를 제공하여 준다
Base Register과 Bound Register를 구하는 것은 OS만 가능하다(이 것을 Privilleged Instruction 이라고 함)
Phase2 : 60년대 중반 ~ 90년대 중반
Terminal : 중앙 컴퓨터와 연결되어 데이터를 입력하거나 출력할 수 있는 하드웨어 장치
하나의 CPU를 여러 User가 Interactive하게 사용
Interactive Time Sharing Operating System의 등장
File System의 발전
응답 속도와 보안의 중요성이 증가
'development > 강의노트' 카테고리의 다른 글
[운영체제의 기초] Processes and Threads (1) - Process Concept (0) | 2020.04.02 |
---|---|
[운영체제의 기초] Computer Hardware (0) | 2020.03.22 |
[운영체제의 기초] Evolution of OS (2) (0) | 2020.03.17 |