[ETL] Evolution of OS

출처 : SNUON / 운영체제의 기초: 쉽게 배우는 운영체제 원리 / 서울대 홍성수 교수님

 

Phase I

초기 컴퓨터에서 가장 중요한 것 : CPU Utilization

 

I/O 하는 동안 CPU가 놀고 있네? 뭔가 CPU의 낭비를 줄일 방법 없을까?

 

1. Synchronous I/O : 얘는 어쩔 수 없는 것 같고...

 

2. Asynchronous : 얘는 그냥 알아서 처리하게 명령만 내리고 CPU는 하던 일이나 마저 하면 되지 않을까?  

 

$\Rightarrow$ I/O controller 만들어서 I/O 작업 맡기고 Interrupt 로 결과만 알려주자!

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

낭비를 줄이긴 했는데 synchronous I/O에게 일을 맡겨놓은 동안 CPU는 idle 상태네...

 

낭비를 더 줄일 순 없을까?

 

$\Rightarrow$ multi-programming : 메모리에 여러 프로그램을 올려두고 꺼내가면서 수행

 

이 때부터 메모리에 os를 올려두고 그 위에 여러 프로그램을 쌓아두는 구조가 만들어졌다!

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

IBM에서 야심차게 컴퓨터 내놓으려고 했는데 OS 개발이 3년이나 지연

 

Why? 미처 생각치 못했던 여러 기술적 문제들이 발생해서!

 

multi-programming 을 시작하면서 새로 발생한 문제

1. memory protection

2. memory relocation

3. concurrent programming

 

1. memory protection

job1이 수행되고 있는데 job1의 포인터가 job2의 메모리를 잘못 건드려서 job2의 프로그램에 문제가 발생

 

job2의 개발자는 "분명 잘 짠 것 같은데 뭐가 문제지..." 하다가 머리를 짜내면서 고민했는데 어느날 갑자기 고쳐지고 "흠... 왜 고쳐진거지?"

 

이런 식으로 프로그램 자체에 문제가 없더라도 다른 프로그램에 의해 문제가 발생하는 경우가 있었음.

 

더 심각한 경우 job1이 OS의 메모리를 건드려서 큰일이 날 수도 있었음.

 

$\Rightarrow$ job에게 정해진 만큼만 공간을 부여하고 포인터의 target memory가 부여된 공간 안에 있는지를 확인하는 방식으로 해결!

 

2. memory relocation

내 프로그램이 어느 메모리 위치로부터 시작할지 모르는데 코드를 어떻게 짜야 하지?

 

job이 메인 메모리의 임의의 위치에서 수행될 수 있도록 할 수는 없을까?

$\Rightarrow$ base register : 프로그램이 로드된 시작 주소를 담고 있는 주소

 

이제 내 프로그램은 항상 0번지부터 시작된다고 가정하고 코드를 짤 수 있겠다!

물론 실제 주소가 만들어질 떄는 base register에 있는 시작 주소와 합쳐져서 주소가 생성되겠지!

 

 

여기에 job의 크기도 bound register에 저장하면 memory protection도 해결이 되겠구나!

 

논리적 주소 : 프로그램의 instruction에 따라 CPU가 생성하는 주소

물리적 주소 : 일련의 변환을 거쳐 만들어진 실제 메모리 주소

 

MMU (Memory Management Unit) : 논리적 주소를 물리적 주소로 변환해주는 하드웨어 장치 (현대에는 CPU에 내장해놓는듯)

 

이렇게 시스템을 구성해놓고 나니 base register, bound register는 OS에게만 접근 권한을 주는게 타당

$\Rightarrow$ privileged instructions

 

3. concurrent programming

여러 job을 동시에 수행하다보면 공유 자원이나 공유 데이터 관련해서도 많은 문제가 생긴다.

이 부분은 synchronization 파트에서 굉장히 자세하게 공부할 것이다.

 

Phase II

하드웨어가 급속도로 발전하는 동시에 인건비가 급등하던 시기.

 

OS의 역할이 변하기 시작했다.

 

CPU를 놀게 하지 않는 것 $\Rightarrow$ 사람들의 생산성을 높이는 것

 

예를 들어, multi-programmed batch를 쓰니까 배치 맡겨놓고 기다리는 시간에 사람이 놀게 된다.

 

Terminal : BTCS 같이 생긴 CRT 모니터 + 키보드에 텍스트 라인만 나오는 입출력 장치

 

회사에서는 terminal을 1대씩 나눠주고 terminal들을 중계 장치로 묶어서 서버 컴퓨터에 연결.

 

CPU는 서버 컴퓨터에 하나 밖에 없는데 어떻게 여러 사람이 interactive 하게 사용할 수 있을까?

 

CPU의 시간을 조금씩 쪼개서 사용자들에게 나누어주면 되겠구나! 

 

time sharing operating system 탄생!

 

modern os의 근간이 되었다!

 

ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ

 

Interactive time sharing OS 도입되니까 너무 편리해서 private한 정보도 컴퓨터에 저장하기 시작

$\rightarrow$ OS 개발자들은 수요에 맞춰 사용자 별로 접근성을 제한할 수 있는 파일 시스템을 추가하기 시작

 

OS를 평가하는 지표도 점차 변하기 시작했다.

 

단위 시간당 얼마나 많은 job을 처리하는가 $\Rightarrow$ 사람들의 사용감 (response time, private data의 보호 정도)

 

Phase III

Internet Access, Multimedia support 등 OS가 지원해야 하는 대상이 달라지면서 더 발전하고 복잡해졌다