안녕하세요. 운영체제 3번째 글입니다... 2번째 글을 작성한지 조금 시간이 많이 흘렀는데요. 기존 운영 홈페이지 데이터 이전 결정을 내리면서 데이터 이전에 시간이 좀 걸리는 듯 합니다. Tistory 운영지침 상 1일 15건 글쓰기 제한이 있어서요.
자. 지난 시간에 운영체제 독학의 목표와 운영체제 개요, 운영체제란, Abstraction, OS and Kernel에 대해 살펴 보았습니다. 이번 시간은 약간 컴퓨터 역사시간이라고 보시면 됩니다. 운영체제의 역사와 굉장히 긴밀하기 때문이죠.
02.01. 컴퓨터의 기원
Compute + er
2차 세계대전 : 암호해석, 탄도 분석
초창기 컴퓨터 시스템에 대해서 다뤄볼게요.
1950년대는 프로그램을 기계적인 스위치를 이용하여 1bit 단위로 컴퓨터에 입력하여 실행했습니다. 이는 진공관 기반이였죠. 1950년대 중반에는 프로그램을 기계어로 작성했는데요. Plug-board와 wireing을 통해 컴퓨터의 기능 제어했습니다. 프로그래밍 언어 및 운영체제라는 존재없었다고 볼 수 있죠. 이때까지만 해도 저장장치가 없었습니다. 즉, 매번 프로그램을 다시 입력해야 했습니다.
1960년대는 펀치카드가 등장했습니다. 구멍 뚫어~ 구멍 뚫어서 이 카드로 컴퓨터를 구동한 것이죠. 펀치카드는 실행되지 않으면 카드가 튀어 나왔습니다. 안 돌아가고 튀어낳오면 아.... 한숨을 쉬었겠죠...이 카드는 OMR카드를 생각나게 하네요.
일괄처리(Batch)는 아주 단순한 OS개념이라고 볼 수 있습니다. 일단 시작한 'Job'이 끝나야 다음 Job이 수행되죠. 펀치카드를 넣으면 메모리 적재 > 수행의 순으로 진행하였습니다. 또한 결과를 받기까지 중간에 user interaction을 허용하지 않았습니다. 그럼 scheduling을 누가 했을까요?
사람입니다.. 띠용~
이러한 처리는 CPU가 빈번히 idle 상태에 빠진다는 것에 단점이 있습니다. 기계장치와 전기장치의 속도차이 때문이였죠.
02.02. Automatic job sequencing
좀 더 나은 OS라고 할 수 있을 것 같군요. 펀치카드를 설명드리면서 scheduling을 사람이 한다고 말씀드렸는데요. 이제는 사람의 관여없이 여러개의 프로그램을 컴퓨터에서 순차적으로 실행하게 되었습니다. 이전 작업이 종료되자마자 작업을 실행하기 때문에 Batch보다 성능이 향상되었다고 볼 수 있겠네요. 하지만 아직 중요한 단점이 남아있죠. Automaitc job sequencing과 Batch의 공통적인 단점이라는 것이 힌트가 될 수 있겠네요
I/O에 의한 CPU idle 상태 : Wait until previous task finished
02.03. 해결책을 찾기 위한 여정
Spoling
Spoling은 초기에 제안된 해결책이라고 볼 수 있습니다. Simultaneous Peripheral Operating On Line. I/O와 Computation을 동시에 진행할 수 있는데요. 바로 버퍼를 사용하는 것입니다. 사용자는 Spooling을 통해서 여러개의 작업을 순차적으로 요청할 수 있게 된거죠. 이전 작업의 종료를 기다리지 않고 그냥 버퍼에 로드하여 자신의 새로운 작업을 요청할 수 있게 된 것이죠. 컴퓨터 프린트대기열을 보시면 스풀링 중... 이라는 창이 뜨는 것을 보신적이 있을텐데요. 바로 여기서의 스풀링이 이 Spooling입니다. 아주 획기적인 발명이였죠.
Multiprogramming
Multiprogramming은 아주 중요한 개념입니다. 2개 이상의 작업을 동시에 실행하는 것이죠. 운영체제는 여러개의 작업을 메모리에 동시에 유지합니다. 현재 실행중인 작업이 I/O를 할 경우 다음 작업을 순차적으로 실행합니다. 조금 더 정교한 스케쥴링을 요구하게 되었습니다. 그럼 왜 I/O를 기준삼았냐고요? 여러분 타이핑 속도를 생각해보세요.... 인터넷에 잘 설명된 그림이 있어 찾아보다가 쏙 마음에 드는 그림을 찾았습니다. 여기서 ready queue와 I/O queue가 뭔지 궁금하실텐데요. 이 궁금증을 다른 글에서 마주칠 때까지 간직해주세요.
돌아와서 그럼 왜 이렇게 하는 걸까요? 바로 CPU의 활용도 때문이죠.(이 글의 소제목이 뭐죠? 해결책입니다! 바로 Automatic job sequencing등의 문제점을 해결하는 거죠.) 단점은 뭘까요? 힌트는 펀치카드의 단점입니다.
사용자는 여전히 실행중인 작업에 대해 관여할 수 없다.
많은 분들이 헷갈리시는 것이 그럼 멀티프로그래밍은 실제로 여러 Job이 실행되는지에 대한 것입니다. 다 실행중이라고 볼 수 있죠. 하지만 CPU Core가 1개라면 물리적으로 어느 똭 한 시점에서 실행되고 있는 것은 하나입니다. : Concurrent와 Simultaneous의 차이라고 보시면 됩니다. Concurrent는 partially하게 수행되는 것이 아니에요! CPU를 사용한다는 관점에서 실행은 아니지만 어쨋든 IO를 기다리고 있으니까 수행중이라고 생각할 수도 있겠죠?
Issue of multiprogramming
다른 Job이 수행되기 위해서는 현재 수행되는 job이 I/O를 해야하는 것입니다. 여기서 음흉한 미소를 짓는 분들은 이기적인(?) 분들이에요... 바로 Volutary yield에 의존하는 문제가 있습니다. 공평해야 할 컴퓨터를 누군가가 의도적으로 I/O를 사용하지 않아 독차지 할 수 있는거죠. 이는 High priority로 수행할 필요가 생깁니다. 하지만 Job scheduling으로는 해결되지 않습니다. 화장실에 먼저 들어간 사람이 나올 생각이 없는데 그 앞에서 누가 먼저 들어갈건지 싸우는 꼴 밖에 더 됩니까?
Timesharing
Timesharing은 그런 문제를 해결하기 위해 등장했습니다. 그냥 강제적으로 나눈 거에요. 모든 프로그램은 정해진 Time slice동안 CPU를 점유하고 시간이 끝나면 CPU를 돌려주는 거죠. CPU Switcing이라는 것을 통해서 여러 개의 Job이 동시에 실행될 수 있게 된 것입니다. 이러면 사용자가 중간중간에 실행중인 프로그램에 관여가 가능하다는 장점도 챙길 수 있죠. 여기까지 잘 따라오셨다면 당연히 떠올려야 하는 질문이 있습니다. Time slice는 어떻게 정할 것인가?
CPU clock을 반영하겠죠. 요즘 시스템에서는 time slice 간격에 varaible하게 바꿀 수도 있다네요...
컴퓨터 구조과목을 배우신 분들이라면 한가지 질문을 더 생각하실 수 있습니다. Switching 구현을 어떻게 할 것인가? 어떻게 프로그램이 돌아가는 중간에 내가 양보해야하는지 알 수 있을까?
Idea1 : memory counter
프로그램이 양심적이지 않다면요?
Idea2 : CPU자체 clock
Job이 실행 중인데 OS가 어떻게 볼 수 있을까요? 보려면 OS가 CPU를 사용해야 하는 거 아닐까요?
Idea3 : Interrupt
여러 아이디어를 떠올리셨나요? 결국은 내부적인게 아니라 외부적인 무언가가 필요하다는 것을 느끼셨을 겁니다. 마치 화장실 문을 누군가가 비켜달라고 두들기는 것처럼요. 어느 정도의 instruction이 실행된다면 외부적인 input을 통해 강제적인 switch가 가능하게 하는 것이죠. CPU에 가산기랑 register를 넣어서 하드웨어적으로 구현하면 될까요? Compiler를 사용할 수도 있겠군요.
이러한 문제를 프로세스간 전환 문제라고 합니다. 2가지 개념이 있을 수 있겠네요.
협조 방식(cooperative) : 시스템콜 기다리기 말그대로 진행중인 프로세스가 스스로 시스템콜을 보내, 운영체제가 다 시 CPU의 제어권을 갖게 하는 것이다. 하지만 이 방식이 제대로 작동 하려면, 프로세스를 신뢰할 수 있어야 한다는 전제가 필요하다.
비협조 방식 : 운영체제가 전권을 행사 위에서 언급한 Timer interrupt를 이용해 일정 시간마다 interrupt를 발생시켜 운영체제가 CPU의 제어권을 얻는 방식이다. interrupt가 발 생하면 현재 수행중인 프로세스는 중단되고 미리 구성된 운영체제의 인터럽트 핸들러가 실행된다. 이 시점에 운영체제는 CPU 제어권을 얻게 되는 것이다.
그럼 Timesharing과 Multiprogramming의 차이를 하나 더 살펴 볼까요? 멀티프로그래밍에서는 I/O로 들어가서 어차피 Sleep 상태입니다. 하지만 Timesharing에서는 active하죠. 그냥 CPU가 잠시 다른거 해서 진행을 못하고 있을 뿐입니다.
너무 많은 질문거리를 던졌다고 생각하시나요? 마저 하나의 질문을 더 던지겠습니다. Timesharing을 통하여 CPU Switching이 발생하면 그냥 바꾸면 될까요? 아니죠. 프로그램의 state를 저장해 놓아야 합니다. 마치, 복습할 때 어디까지 지난시간에 복습했는지 기억하는 것 처럼요. 그럼 state에는 어떤 것이 있을까요? 컴퓨터구조과목을 떠올려 보시기 바랍니다.
PC(Program Counter), Stack Pointer, CPU Register 등이 있겠네요.
Hadling procedures에 관한 내용을 참고해주시면 될 것 같습니다. 개념만 배우셨을 수도 있을 텐데요. stack pointer는 스택의 메모리 구조적 특성 LIFO에 맞추어 어느 위치까지 데이터를 저장했는지 기억해야 합니다. frame pointer는 stack pointer의 문제점때문에 존재하죠(호출된 함수가 빠져나오는 시점에서 함수 내에서 할당된 메모리 공간을 반환하기 위해 스택 프레임 단위로 stack pointer를 이동시켜야 하는데 얼마나 이동시켜야 하는지 모를 수 있음) 이때 Stack pointer, frame pointer를 포함하는 cpu register의 대부분 값이라고 볼 수 있겠네요. Calle와 Caller에 대한 내용이 여러분의 이해를 숙성(?)시키는데 도움 될 것 같습니다.
02.04. 족보
뭐 이 그림을 굳이 설명해야 할까요? 흠... 고민이 됩니다. 그냥 요렇게 발전되어 왔다고 말하고 넘어가고 싶은 부분이네요. 잠깐만 살펴볼테니, 궁금하신 분들은 google search해보세요... 무책임한 발언은 사과드립니다.. 어디서 들어본 것도 있네요. MAC OS, UNIX, Linux, MS-DOS, Windows... 처음 들어보는 것도 많습니다. 1950년대 후반 Multics는 굉장히 재미난 아이디어가 많이 포함되어 있는데요. 사공이 많으면 배가 산으로 가죠? 아이디어에 비해 하드웨어 성능이 딸려서 좀 아쉽게 끝난 프로젝트입니다. 그후 AT&T는 OS개발에 착수하면서 Multics를 분석하죠. 아...너무 많은 기능이 문제구나! 간단하게 바꾸었습니다. 그 후 BSD, MINIX등으로 분화되어 갔네요. MINIX는 유럽에서 Intel CPU위에 UNIX를 올리는 작업이였습니다. 그 당시에는 OS가 하드웨어 debalance가 컸죠. 이런걸 사용해 본 분들이 이 글을 읽으실까요? 허허허...이걸 사용해 본 분들이라면 아마 다들 교수님이나 현업에 종사하고 계신분들 일겁니다. 말이 길어졌네요. 그래도 이 이야기는 꼭 해야겠습니다. Linux! open source를 빼먹을 수 없네요. 가슴뛰는 이야기 open source! 제 실력 밑천을 훤히 보여주는 open source님이 되시겠습니다. Linux이전에는 SW 코드가 초특급 비밀이였습니다. OS는 말할 것도 없겠죠. 리눅스는 전세계 개발자들이 자발적으로 참여하여 코드를 공유하고 있습니다. 개발 방법론의 변화를 이끌어 낸 것이죠. 경제학과 학생분들이 분노할 이야기일 수도 있겠습니다. 하지만 공개를 통해 더 발전시키고 큰 이익을 얻을 수 있다는 점에서 규모의 경제라고 할 수 있겠네요. 또 내가 다 만들지 않는다. 좀 나눠서 만들자라는 것도 좋아보이군요. 요즘 세상에 카피도 능력이라는 말이 있더군요. 어쩌면 남의 것을 이해하고 빨리 사용하려는 자세가 필요한 세상일 수도 있다는 생각이 듭니다.
이번시간에는 운영체제의 역사에 대해 톺아보는 시간이였습니다. 상당히 긴 글이 되었을 수도 있을텐데 찬찬히 읽으시면서 던져진 질문에 대해 함께 고민해주셨다면 감사합니다. 질문에 대한 여러 코멘트를 기대해 보겠습니다.
'학부공부 > OS_운영체제' 카테고리의 다른 글
| 05. Multics vs Unix [Interesting topic to study] (0) | 2021.11.02 |
|---|---|
| 04. 운영체제 구조(2) (0) | 2021.11.02 |
| 03. 운영체제 구조(1) (0) | 2021.11.01 |
| 01. 운영체제란 무엇인가 (0) | 2021.10.20 |
| 00. 운영체제 STUDY 시작 (2) | 2021.10.20 |
댓글