OS 시스템의 발전 - batch System
OS - mediator, resource manager
OS는 하드웨어와 application 사이에서 사용자 프로그램의 작업을 처리하기 위해 하드웨어에게 어떻게 명령해야 효율적인지 (cpu 명령, 메모리 주소 할당, I/O 발생 처리 등) 어떻게 컴퓨터 자원을 편리하게 사용할 수 있는지에 목적을 두고 발전해왔습니다.
OS는 application을 실행할 수 있는 편리한 interface를 제공하고, 프로세스의 생성과 끝까지의 관리에 책임을 집니다.
또한 프로그래머에게 programming interface(java, python과 같은 언어)을 원활하게 이용할 수 있는 하드웨어 사이의 interface도 OS 수준에서 정의되어 있습니다.
그리고 여러가지 컴퓨터 자원과 처리 중인 데이터가 어디로 이동할지, 어디에 저장할지를 효율적으로 지정합니다.
이러한 OS가 어떻게 탄생하게 되었는지 그 배경을 알아보겠습니다.
Evolution of OS
컴퓨터가 발전하던 초창기에는 CPU가 국가적인 자산이었기 때문에 CPU의 계산 효율을 최대로 늘리는 것에 대한 고민이 최우선이었습니다.
그래서 상대적으로 컴퓨터를 다루는 사용자가 컴퓨터를 사용하는 시간보다 CPU가 직접 계산을 수행하는 시간이 더 중요하게 여겨졌습니다. (CPU의 생산성 - 응답 시간 >> 사람의 생산성 - 대기시간),
하지만 CPU처리 속도가 한계에 다다르고 사람의 노동가치가 점점 높아지자 이젠 어떻게 하면 컴퓨터를 이용하는 사람이 더 많은 작업을 진행할 수 있을까에 대해 고민했습니다. (CPU의 생산성 - 응답 시간 << 사람의 생산성 - 대기시간)
.
.
.
위와 같은 방향성을 두고 각 시기마다 OS가 어떤 System을 가졌었고, 어떻게 변화했는지를 알아보겠습니다.
serial Processing (1940s - 1950s)
이때 당시 컴퓨터의 CPU는 진공관, memory는 마그네틱 코어, input은 펀치카드였습니다.
OS라는 개념은 없었고, 사람이 직접 수동적으로 하드웨어 자원을 사용했기 때문에 작업을 시작하고 끝나는 시간을 계산하여 여러 프로그램들을 배치해야 했습니다.
또한 컴파일러와 같이 프로그램을 실행시키는데 필요한 프로그램들과 그 프로그램이 종료될 때까지의 모든 과정이 순차적으로 이루어졌기 때문에 하나의 프로그램이 끝나고 다른 프로그램을 실행시킬 때 발생하는 cost가 컸습니다. (setuptime)
문제점 : 고가 자원의 비효율적 사용
- 누가 컴퓨터를 사용할 것인가에 대한 Scheduling time이 생각보다 짧으면 작업을 다 처리하지 못하고 길면 대기시간이 늘어남
- input에 따른 setup time이 길고 수동적으로 이루어짐
위 문제점을 해결하기 위해 Simple batch System 이라는 구조를 만들어 비슷한 작업을 수행하는 프로그램들의 배치를 연결하여 해당 프로그램들이 실행될 때 필요한 작업을 한 번만 수행함으로써 setup time을 줄이려 했습니다.
여기서 프로그램 실행을 위한 공통적인 작업을 하나로 묶기 위해 컴파일러, 링커, 로더 같은 library라는 개념이 생겨났습니다.
Simple batch System
이 simple batch system을 사용하기 위해선 다른 프로그램들을 항상 주시하고 있는 소프트웨어가 필요했고, 최초의 OS인 Monitor가 만들어졌습니다.
Monitor는 각종 프로그램들의 순서를 제어하기 위한 JCL이라는 언어와 여러 device driver 등 자동화를 위한 기능들을 가지고 있습니다.
Monitor는 항상 실행 중인 상태로 다른 프로그램들을 제어하기 때문에 특정 메모리의 고정된 공간을 차지합니다. 그렇기 때문에 다른 프로그램이 그 메모리 공간을 침범하면 안 되고 memory protecting을 해야 한다는 것과,
프로그램을 약속한 시간안에 종료하고 실행시켜야 하기 때문에 상대적인 시간을 측정하는 system timer를 가지고 있어야 한다는 특징이 있습니다.
또한 I/O 관련된 명령을 일반 프로그램에서 실행하지 못하게 하고 Monitor에서만 실행 가능하게끔 하는 i/o 명령어의 권한이 나눠지기도 했습니다.
추가적으로, 다양한 device의 I/O 처리를 위한 I/O Controller도 이시기에 만들어졌는데,
(I/O controller -> interrupt handler-> CPU)
simple batch system에서는 특정 input에 대한 interrupt handler 의 신호를 기다리는 시간 동안 그 input이 처리되야만 다음 명령을 수행하는 프로그램들이 있었기에(의존성, Sychronous I/O) CPU의 대기시간은 불가피하게 늘어났습니다.
이러한 문제를 해결하기 위해선 Sychronous I/O에 따른 대기시간에 CPU가 다른 프로그램을 처리할 수 있어야 했고,
Multiprogrammed Batch System이 등장하게 됩니다.
Multiprogrammed Batch System
Multi processing과는 다른 개념입니다. Multi Programmed란 하나의 프로세서에서 다수의 프로그램을 실행할 수 있게 메모리에서 프로그램을 배치한다는 뜻입니다.
위 그림은 uniprogramming으로 프로그램 A에서 Sychronous I/O가 발생했을 때 입력을 기다리는 시간이 존재하는 것을 볼 수 있습니다.
이 그림은 multiprogramming으로 A에서 Sychronous I/O가 발생했을 때 B의 작업을 수행하고 B에서 다시 Sychronous I/O가 발생했을 때 C를 수행시킵니다.
이와 같이 대기시간에 다른 프로그램을 수행하여 CPU의 작업 효율을 높이는 것을 볼 수 있습니다.
하지만 프로그램의 실행이 동적으로 결정되기 때문에 프로그램간의 메모리 침범이 일어나기 시작했습니다.
원래의 simple batch system에서는 프로그램의 시작 순서가 정해져 있어 사용자는 시작 주소를 알고 끝 주소를 알고 있으면 프로그래밍을 간단하게 진행할 수 있었습니다. 하지만 muiti programming batch는 특정 프로그램이 어느 주소에서 시작하고 다시 실행될지가 정해져 있지 않습니다.
또한 새로운 작업이 들어왔을 때 메모리에서 제일 idle한 프로그램을 찾아 그 명령들을 잠시 disk에 넣어두고 새로운 작업을 그 메모리 주소에 할당하는 relocation이 필요했는데, 이 문제점들을 다음 그림과 같이 해결했습니다.
relocation을 해결하기 위해 base register라는 것을 추가해 프로그램의 시작 주소를 저장하여 특정 프로그램에 다시 접근할 수 있게 하였고,
bound register를 추가해 그 프로그램이 사용할 수 있는 주소(길이)를 저장하여 만약 사용 가능한 길이를 초과하였다면 exception을 발생시켜 메모리 침범을 막았습니다.