운영체제 개요

컴퓨터의 기원

• Compute + er : 과거에는 계산을 하기 위해서 사람을 고용했지만, 그 역할을 기계가 대신하기 시작한 것이 컴퓨터의 기원이라고 볼 수 있다.

• 컴퓨터가 구체적으로 형태를 띠기 시작한 것은 2차 세계대전이었다.

  • 암호 해석
  • 미사일 탄도 분석
  • 물리 계산

  등의 목적으로 기계가 동원되기 시작하면서 컴퓨터가 시작되었다.

Hand-operated System

• 1950년대 초반
  • 당시 컴퓨터는 현재의 컴퓨터에 비해 매우 원시적이었다.
  • 프로그램은 기계적인 스위치를 이용하여 1bit 단위로 컴퓨터에 입력되어 실행되었다.
    • 진공관 기반 - 집채만한 크기, 많은 열 방출
• 1950년 대 중반
  • 모든 프로그램은 기게어로 쓰여졌다. 어셈블리어 조차도 기계어는 아니다. 기계어는 문자 그대로 바이너리의 형태이다.
  • 플러그 보드(Plug-board)에 와이어링(wiring)을 통해 컴퓨터의 기능을 제어 file 개념이 없었기 때문에 플러그 보드는 컴퓨터의 전원이 꺼지면 유지되지 않았다. 따라서 매번 기계어를 다시 쳐야 했다.
  • 프로그래밍 언어 및 운영체제라는 존재가 없음
    • 영속적인 저장장치가 없음 - 매번 프로그램을 다시 입력해야 했다.
• 1960년 대 초반
  • 펀치카드가 등장 다음과 같이 미리 카드에 작성된 펀치 라인을 컴퓨터에 제출하면 그것이 컴퓨터 안에서 프로그램이 되어 메모리에 적재되고 수행이 되었다.
  • 프로그래밍한 카드로 컴퓨터 구동
    • 플러그 보드 대체

Mainframe - 일괄처리(Batch)

• Business machinery로써 쓰이면서 가치가 발생
  • 계산을 하는데 주로 사용되기 시작함
  • 교량(Bridge) 설계
• 일괄 처리 - 아주 단순한 OS 개념
  • 일단 시작한 job은 끝나냐 다음 job이 수행됨
  • Punch card를 제출하면, 메모리에 적재, 수행의 순서로 진행
  • 결과를 받기까지 중간에 No user interaction : 수행 중간에 사용자의 임의로 결과를 확인하거나, 중단이 불가능하다.
  • 사람이 job을 scheduling함
• CPU는 빈번히 idle(대기) 상태로 전환됨
  • 기계적인 IO 장치와 전기 장치인 CPU 사이에 현격한 속도 차가 존재 따라서 대부분의 시간을 CPU는 대기하고 있어야 한다. 참고로, CPU의 대기 시간은 최적화 가능 여부를 따질 수 있는 큰 기준이 된다. CPU가 대기 상태인 시간이 많다면 최적화할 영역이 많다는 것을 뜻한다. CPU가 늘 saturate된 상태라면 최적화를 하더라도 큰 소용이 없을 수 있다.
    • 프로그램을 메모리에 올리는 시간(loading)이 사람이 Punch Card를 프로그램에 제출하는 시간을 포함하기에 엄청난 손실이 있을 수 밖에 없었다.

Automatic Job Sequecing - 좀 더 나은 OS

• 사람의 관여 없이 여러 개의 프로그램을 컴퓨터에서 순차적으로 실행
• 이전 작업이 종료되자 마자 다음 작업을 실행하기 때문에, 일괄 처리(batch)보다 성능이 향상됨 사람의 의해서 생기는 CPU의 대기 시간이 절약된다.
  • 일괄처리
    • 사람이 직접 스케줄링
  • Automatic Job Sequencing
    • 스케줄링을 담당하는 소프트웨어에서 프로그램 실행
• IO에 의해 CPU가 유휴 상태로 전환되는 문제는 해결 X
  • 과거에 문서를 출력할 때에는 프린터가 출력을 모두 완료할 때까지 워드 프로그램은 중단되어있었다. 프린터가 출력을 완전히 완료해야만 CPU는 다음 동작을 이어 수행할 수 있었다. 이처럼 IO과정에서 CPU가 유휴 상태로 바뀌는 비효율을 해결하기 위한 또다른 방안을 고려해야 했다.

Spooling - 초기 해결책

• Simultaneous Peripheral Operation On-Line
  • 프린터 spooling
    • 인쇄할 문서를 디스크나 메모리의 버퍼에 로드
    • 프린터는 버퍼에서 자신의 처리 속도(분단위)로 인쇄할 데이터를 가져옴

즉, CPU는 프린터 버퍼에 데이터를 전송하는 작업이 끝나면 바로 다음 동작을 이어 수행할 수가 있게 되었다.

• IO와 Computation을 동시에 진행할 수 있음
  • 프린터가 인쇄하는 동안 컴퓨터는 다른 작업을 수행할 수 있음 이 당시 프린터가 문서를 출력하는 속도가 매우 느렸으므로 엄청나게 많은 시간을 절약할 수가 있었다.
• Spooling을 통해서 사용자는 여러 개의 인쇄 작업을 프린터에 순차적으로 요청할 수 있음
  • 이전 작업의 종료를 기다리지 않고, 버퍼에 인쇄 작업을 로드하여 자신의 인쇄 작업을 요청함 즉, 서로 다른 출력 작업을 두 번 요청할 경우, 두 번째 요청은 전에 요청된 문서의 출력이 완료될 때까지 기다리지 않고, 버퍼에 출력할 데이터를 로드하기만 하면 된다는 것이다.

참고로, 문서 출력을 요청한 후에 장치관리자에서 프린트 상태를 보면 스풀링이라는 단어가 나타나는 것을 확인할 수 있는데, 출력할 문서를 프린터 버퍼에 복사하는 중이라는 뜻이다.

• 여전히 Spooling을 도입할 때에도 배치 프로그램이 전제였다. 여전히 Job(현재에는 프로그램의 개념과 유사하다)은 요청된 순서대로 메모리에 올라가서 작업이 모두 완료될 때까지 CPU를 점유했다가 모두 완료되면 그제서야 다음 작업이 메모리에 올라와서 수행되는 형태를 취하고 있었다. 스풀링을 통해 IO 시간을 대폭 줄였지만 여전히 이 정책은 비효율적이고 느렸다.

Multiprogramming

• 배치 프로그램의 비효율성을 줄이기 위해, 사람들은 메모리에 여러개의 Job을 올리는 방법을 고안했다. 이것이 Multiprogramming이었다.

• 2개 이상의 작업을 동시에 실행

  • 운영체제는 여러 개의 작업을 메모리에 동시에 유지 배치 프로그램 당시에는 메모리가 하나의 프로그램을 올릴 정도의 크기였지만, 기술이 발전하면서 메모리가 더욱 켜저 하나 이상의 Job을 올릴 수 있게 되었다.
  • 현재 실행중인 작업이 IO를 할 경우, 다음 작업을 순차적으로 실행
  • 스케줄링이 도입됨 : first-come, first-served 메모리에 올라간 다양한 작업에 관해서 CPU를 점유하는 Job을 전환해줄 주체가 필요했고, 이것을 위한 별도의 공간과 작업이 OS의 스케줄링 기능으로 발전하게 된다.

• Multiprogramming의 목적
  • CPU 활용도 증가
    • idle을 최소화 IO과정에서 발생하는 CPU idle 시간(ex - 사용자의 키보드 입력 시간)을 CPU에게 다른 작업을 수행시킴으로써 절약할 수 있다.
• 단점
  • 사용자는 여전히 실행 중인 작업에 대해서는 관여할 수 없다.

IO란? Input과 Output의 약자로 CPU와 별도로 하드웨어가 동작하는 과정이며, 컴퓨터 및 주변 장치에 대하여 데이터를 전송하는 프로그램이다.

Issues With Multiprogramming

• 다른 job이 수행되기 위해서는 현재 수행되는 job이 IO를 해야 한다. - voluntary yield에 의존
  • 자발적인 영역에 의존한다는 것은 프로그램의 의도에 따라 상황이 달라질 수 있는 것을 의미한다. 예를 들어 의도적으로 IO를 안하거나, IO를 작업의 가장 마지막 단계로 두는 경우에 공평성이 결여된다.
• 공평성을 유지할 필요성
  • 어떤 Job이든 자원을 오래 쓰고 싶어 한다.
• High Priority로 수행할 필요도 생김
  • 어떤 Job은 IO 여부와 상관없이 큰 우선순위를 가져야할 경우가 있다.
• Job Scheduling으로는 해결이 안됨

concurrent VS. simultaneous

• concurrent 메모리에 여러 Job이 올라가서 한번에 수행되지만 미시적으로는 한 순간에는 한개의 Job만이 수행되므로, 여러 Job이 수시로 전환되면서 수행됨을 의미
• simultaneous CPU가 여러개여서 한 순간에 여러 개의 Job이 동시 수행됨을 의미

질문들

Q : job1에서 IO가 수행되어 job2으로 넘어갔는데 job1에서 IO가 완료되면 그 때 다시 job1으로 가는건가요? A : 아니다. job2에서 IO를 하거나 완료될 때까지 job2가 계속 수행된다.

Q : job change 하는 데에 걸리는 시간이 IO 하는 데에 걸리는 시간보다 훨씬 적나요? A : 그렇다. 그래서 멀티프로그래밍이 의미가 있다.

Timesharing

• CPU의 실행시간을 타임 슬라이스(time slice)로 나누어 실행
  • 10ms (mill-seconds, 밀리초)마다 스위칭을 한다면? 1초에 100번 CPU 스위칭이 일어난다.
• 모든 프로그램은 타임 슬라이스 동안 CPU를 점유하고, 그 시간이 끝나면 CPU를 양보(relinkquish)
• 여러 개의 작업들은 CPU “스위칭”을 통해서 동시에 실행됨
• CPU스위칭이 매우 빈번하게 일어남
  • 사용자는 실행중인 프로그램에 관여(interact)가 가능

CPU 스위칭의 원리?

CPU 내에서 clock이 있을 경우, OS이 Job을 수행하는 동안 Clock을 통해 시간을 카운트 해야하는 데, 이미 Job이 수행 중이므로 양보가 불가능하다. 즉, 어떤 Job을 수행하면서 동시에 타이머를 읽는 것은 불가능하다는 것이다. 닭이 먼저냐 달걀이 먼저냐의 문제이다. 이것을 해결하기 위해서 컴파일러가 만 줄의 코드를 읽을 때 즈음에 CPU를 전환하여 타이머를 확인하는 등의 방법을 도입해서 구현해야 한다. 혹은 외부에서 시간을 알려주는 방법도 존재한다. 자세한 것은 다음 시간에 배울 것이다.

Q : Timesharing 중에 IO가 발생하면 다음 job으로 전환되나요? A : 그렇다. Timesharing policy가 적용될 때에는 마찬가지로 Multiprogramming도 적용되고 있다. 더 나아가서는 Spooling -> Multiprogramming -> Timesharing -> Multitasking 순으로 하나씩 더해져서 적용되고 있다고 생각하는 편이 좋다.

More On Time Sharing

• “Concurrent” 수행
  • 여러 프로그램들이 동시에 수행 상태에 있는 것
  • Multiprogramming 또 Time Sharing을 할 때 가능 다만 Multiprogramming에서는 concurrent라는 용어를 잘 사용하지 않는데, IO를 수행 중인 프로그램은 이미 수행 상태가 아니라 sleep 상태이기 때문이다. 이에 반해, time sharing은 스위칭되는 프로그램들이 모두 수행 상태라는 점에서 Multiprogramming보다는 concurrent라는 개념에 더 가깝다.
  • 어느 한 순간에는, 하나의 프로그램만 CPU에서 수행되고 있음
• Time Quantum == Time Slice
• Time Sharing을 통하여 CPU 스위칭이 발생하면
  • 프로그램의 state를 저장해놓아야 함 프로그램의 state은 Program Counter, Stack Point, CPU안의 register들의 값을 가리킨다. 그 중에서 이것은 CPU의 스위칭에 관한 것이므로 정확히는 CPU의 register들의 값을 가리킨다.
  • 이 state를 사용하여 CPU를 다시 받아서 수행할 수 있음 이것을 저장해놓아야만 나중에 해당 프로그램으로 다시 돌아올 때 진행되던 상태에서 이어 수행할 수 있다.

Multitasking

멀티태스킹은 다양한 의미로 사용될 수 있다. 간혹, 멀티프로그래밍이나 타임쉐어링과 같은 의미로 용어가 사용되는 경우도 많다. 그러나 엄밀히 따지면, 멀티태스킹은 멀티프로그래밍과 타임쉐어링과는 구분될 수 있는 또 다른 policy라고 할 수 있다.

• 하나의 작업(job)은 동시에 실행할 수 있는 여러 개의 태스크로 나뉘어질 수 있음
  • 리눅스 프로세스는 fork()라는 시스템 콜을 이용해서 여러 개의 자식 프로세스를 생성할 수 있음 자신을 복제할 수 있는 능력을 가짐을 뜻한다.
  • 프로세스 내에 여러 쓰레드(thread)가 동작할 수 있다.
• Multitasking은 사용자가 여러 개의 태스크를 동시에 실행할 수 있도록 하는 기능을 의미함

DBMS Multitasking

DBMS가 멀티태스킹의 좋은 예가 된다.

• Fork를 이용한 Child Process 생성
  • 멀티태스킹 : 여러 프로그램이 동시에 수행(Concurrent Execution)
  • 하나의 태스크가 다른 태스크(Child Process)를 만들 수 있는 기능을 의미함
  • 자신이 필요한 기능을 Child Process 형태로 만들어 서로 협력을 통한 작업 수행
    • DBMS가 수행을 시작하자마자, 세 번의 Fork를 통해 세 개의 Chlid Process를 생성한다.
      • Storage Manager
      • Query Manager
      • Transaction Manager

Issues With Multitasking System

• 복잡한 메모리 관리 시스템
  • 동시에 여러 개의 프로그램이 메모리에 상주됨
    • 생성된 자식 프로세스들은 부모 프로세스와 서로 관계지어져서 함께 동작해야한다.
    • ex) gang scheduling : 태스크 여러개를 동시에 스케줄링하는 것을 의미한다. 여기서 각 프로세스들은 독립적이지 않고 서로 긴밀한 관계를 맺는다. 이들은 Concurrent하고 Orderly한 수행이 요구된다.
  • 메모리 관리 및 보호 시스템 필요
• 적절한 응답 시간 제공 - 서로 관계를 맺어가며 수행됨
  • 그러나 태스크들은 독립적으로 메모리와 디스크로 swap in/out될 수 있음
• Concurrent execution 제공
  • 정교한 CPU 스케줄링이 필요
• 필요에 따라 job들 간의 orderly execution이 필요
  • 동기화, deadlock

Q : Fork할 때 메모리도 복사됩니까? A : 그렇다.

Q : 교수님 멀티태스킹과 관련해 질문이 있는데요, 하나의 job이 여러 task들로 나뉠수 있다고 했는데 그럼 그 task들은 하나의 job에 종속되어, 스케쥴링을 통해 그 job이 잠시 중단하면 관련된 task들도 같이 중단되는건가요? A : 그렇다. 어쩔 때에는 task가 각각의 job으로 나눠질 수도 있지만 보통은 하나의 그룹으로 동작한다.

Q : Multitasking 의 경우 concurrent인가요? simultaneous 인가요? A : 코어가 여러개 있어서 한 순간에 두 개 이상의 job이 돌아가야만 simultaneous이다.

Lineage Of Operating Systems

다음은 운영체제 발전의 역사를 한 눈에 알아볼 수 있도록 그린 그림이다.

• UNIX 계열

  • Multics Multics는 1950년대 후반-1960년대 초반에 진행된 프로젝트로 운영체제의 시조라고 불린다. 그 당시 나온 논문들 중에서는 지금에서도 굉장히 흥미롭게 보일만큼 최첨단인 아이디어들이 많이 있었으나 성능의 한계로 인해 Multics는 아무런 결과물 없이 실패로 돌아갔다.

    • UNIX 그러나 실패가 또 다른 성공으로 돌아오듯이 연구자 중 켐 톤슨이라는 사람이 AT&T 연구소로 들어가서 OS 개발을 시작했고, 너무 많은 기능을 구현하려고 한 Multics의 실패요인을 고려하여 기능을 대폭 줄인 UNIX(UNI-‘하나’를 의미 + X-Multics의 ‘ics’)를 성공적으로 개발했다.
      • System V UNIX/Berkeley UNIX => SVR4 AT&T 연구소에서 오리지널 UNIX를 만든 사람들은 System 5 UNIX를 만들어 표준화를 시도했고, 이것의 4 버전인 SVR4을 공개했으나 굉장히 사용이 복잡하고, 비용적인 문제가 있었으며, 라이선스를 얻기에도 복잡했다.
    • BSD 1.0 UNIX의 소스코드를 버클리대학으로 가져가 BSD를 만들었다. 둘 사이에는 하드웨어적인 차이가 있었다. 요즘에야 버츄얼머신이 지원되므로 OS에서 하드웨어적인 차이가 크게 중요하지 않지만, 그 당시에는 하드웨어의 차이가 OS에도 큰 차이를 가져왔다.
      • NEXTSTEP/OPENSTEP BSD의 상업적인 가치를 알아본 스티브잡스가 애플에서 나와서 NEXT라는 회사를 차리고 자신의 제품 위에 OS를 올린 것이 NEXTSTEP이다. 그리고 이것이 곧 Mac OS로 발전한다.
    • MINIX 미국에서 System V UNIX나 BSD를 만든 사람들은 Microsoft와 Intel을 굉장히 경계했다. 그 당시에 위도우와 인텔이 시장 지배적인 위치에 있었기 때문이었다. 반면, 유럽에서는 인텔 CPU위에 UNIX를 올리려고 시도했고, 이것이 MINIX가 되었다.
      • LINUX 리누스 토발즈가 MINIX의 내부 구조나 함수 등을 차용하여 LINUX를 만들었다. 완전히 MINIX를 거쳤다고는 하기 힘들고, 영향을 받았다고 할 수 있다.
        • Android Linux 기반 위에서 동작한다. OS가 아닌 미들웨어의 형태이다.

• Windows 진영

  • MS-DOS Windows의 시작이었던 MS-DOS는 아주 원시적인 형태의 OS이다.
    • Windows 3.0 & Windows 95 Windows NT가 포함되지 않은 버전들로 MS-DOS와 마찬가지로, OS라고 하기도 뭐한 수준이라고 할 수 있었다.
  • DEC VMS => Windows NT DEC라는 회사에 있던 사람들 중, Multics VMS(Virtual Memory System)라는 아주 우수한 시스템을 만들었다. 그러나 UNIX가 버클리대학에서 BSD로 발전하면서 우세해지는 동안 입지가 줄어든 DEC의 개발자들은 생존을 위해서 시애틀에서 Windows와 함께 협업하여 Windows NT를 만든다. 그리고 이것이 Windows의 커널에 지금까지도 자리잡고 있는 핵심 시스템이 된다.
  • Windows XP Windows NT가 모던화된 버전으로, Windows를 성공으로 이끌었다.

Linux의 발전과 Open Source

• 리눅스 이전
  • SW code가 회사의 일급 비밀이었음 : 특히 OS
• 리눅스 개발
  • 전세계의 개발자들이 자발적 참여
    • Code가 공유되고 있음 리누스 토발즈 혼자선 리눅스를 완전히 개발할 수가 없다. 토발즈가 기본 소스 코드를 공개하고, 전세계의 개발자들이 참여해서 그 코드에 여러 기능을 덧붙였기에 그렇게 성공적인 모델이 만들어질 수가 있었다.
• 왜 Open Source
  • 많은 노력과 비용을 들여서 개발한 code를 무료로 세계에 공개하는 것이 말이 되는가?
    • 그것이 혼자서 모든 것을 만드는 것보다 더 빠르게 소프트웨어를 발전시킬 수 있는 방법이므로
    • 가상화 소스코드(Xen) : 아무리 공개된 소스라도, 코드를 이해할 만한 역량이 되는 자만이 이를 활용할 수 있다.
• 개발 방법론의 진화
  • 오픈소스 개발을 통해 한 소프트웨어를 전세계 사람들이 자유롭게 발전시킬 수 있게 되었다.
  • 한명이 모든 것을 다 만들 필요는 없다. 남들이 만든 것을 가장 잘 활용하여 자신의 것으로 발전시키는 것이 더 효율적인 방법이다.

그 외 시스템들

• Multicore systems
  • 예 : big.little architecture(heterogeneous한 시스템, core의 규모와 종류가 각각 다른 시스템)
• 분산 시스템
  • 여러 개의 시스템들이 LAN/WAN으로 연결된 것
  • Client-server Model, Peer-to-peer Model
  • LAN/WAN과 Bus(한 하드웨어 안에서 메모리와 CPU를 연결하는 용도로 사용됨, 주로 Multicore가 Bus로 연결됨)와의 차이
    • 성능/속도 : Bus가 LAN과 WAN보다 훨씬 속도가 빠르다. (Bus > LAN > WAN)
    • 연결(connectivity)의 유연성(flexibility) - 얼마나 자유롭게 연결이 가능한가 : Bus가 유연성이 떨어진다. (Bus < LAN < WAN)
  • Clustered Systems
  • 공동의 목적을 위해 여러 개의 Multicore 시스템 네트워크를 통해 작업을 수행
  • 이것이 분산시스템이 아닌 이유 : LAB(2m 근방)에서 긴밀하게 연결된 시스템을 특정함
  • Embedded Systems
    • 특정 목적을 위한 운영체제 및 소프트웨어가 하드웨어에 탑재된 형태의 시스템
      • 하드웨어와 긴밀하게 연결되어 동작하는 시스템
    • MP3 player, Smart Phone, PDAs
  • Real Time Systems
    • 시스템에서 수행하는 작업의 완료 시간(deadline)이 정해짐
      • 예) 원자로를 설계할 때, 특정 임계치를 넘어가면 안된다든지, 주어진 시간 내에 끝내야되는 그런 경계들이 정해짐
    • Soft real-time, Hard real-time : 얼마나 데드라인이 엄격하느냐에 따라