[운영체제] 1. 운영체제 서론(2/2), 프로세스 & 스레드(1/2)

1.7 운영체제 구조

monolithic systems : 전 운영체제 이미지가 하나의 프로그램으로 커널 모드에서 실행.

메인 프로시져 : 서비스 함수들을 호출

서비스 프로시져 : 시스템 호출을 수행하는 서비스 함수들의 집합

유틸리티 프로시져 : 서비스 함수들을 돕는 유틸리티 함수들의 집합

유틸리티 프로시져 수정하려면 서비스와 메인 프로시져도 수정 필요 -> 코드가 방대해지고, 수정이 어려움

서비스 프로세스를 동작해야 하는데 재부팅 필요 -> 다운타임 발생 -> 경제적 손실

 

Layered system

운영체제를 계층별로 나누어 사용하자는 아이디어에서 출발,

-> 실패

 

 

Micro kernels : MINIX 운영체제 그림. 커널의 핵심적인 기능만 아주 작게 담음.

IPC : INter process communication

Clock -> 타이머 인터럽트 -> 스케쥴링

Sys -> 시스템으로 진입하는 부분

회색부분만 커널, 나머지는 User mode로 동작. Drivers계층 위로 운영체제 기능이 등장.

Reinc 서버 프로세스 : 운영체제의 기능. 쪼개서 서버 형태로 동작. 각 서버 모듈이 제대로 동작하는 지 확인 -> 재시동 시켜줄 수 있음. 

 

micro kernels는 기존 방식보다 향상된 방식이나, IPC로 메세지를 주고 받으면 부담이 됨.

Windows 역시 파일 스크립터와 프로세스매니지먼트를 마이크로커널쪽으로 넘겨 성능 향상을 꾀함.

 

 

클라이언트-서버 모델 : 마이크로 커널 개념을 약간 변형한 아이디어, 프로세스를 두 개의 클래스 = 서버와 클라이언트로 둠.

클라이언트들은 서버로 메세지를 보내 통신

pc에서 서버에서 웹페이지를 요청하고, 웹페이지가 돌아오는 것 역시 이 모델

 

 

가상머신 : 시분할 시스템 사용, 다중 프로그래밍 제공, raw hardware보다 훨씬 편리한 인터페이스를 가짐.

하나 이상의 가상머신을 상위 계층에 제공. 또한 CMS(conversational monitor system)이라는 단일 사용자용 대화식 시스템을 실행.

CMS프로그램이 시스템 호출을 실행 -> vm/370이 아닌, 가상머신의 운영체제에 트랩 -> 일반적인 하드웨어 i/o명령 실행 -> vm/370이 트랩하여 하드웨어 시뮬레이션을 통해 실행.

 

 

 

위 가상머신의 구현에는 문제점 존재 : cpu를 가상화 해 줄 수 있어야 함.

가상 머신 위에서 실행하는 운영체제가 PSW를 변경하거나 I/O를 하는 것 과 같은 특권 명령을 실행하면, 소프트웨어로 에뮬레이션 될 수 있도록 하기 위해 하드웨어가 가상 머신 모니터로 트랩을 걸어 주어야 함. 그러나 어떤 CPU에서는 이 특권명령을 무시.

 

 

그래서 type 2 hypervisor을 연구. VMware Workstation이 이 것. 호스트 운영체제라고 불리는 기타 다른 운영체제 위에서 응용 프로그램들을 실행. 가상 디스크에 게스트 운영체제를 설치. 사실상 호스트 운영체제 파일 시스템에서의 큰 파일 하나에 불과.

 

 

 

 

1.8 C의 세상.

C파일이 3개, 헤더파일이 2개인 경우의 아래 그림과 같은 과정으로 진행.

 

 

 

 

 

 

 

2. 프로세스와 스레드

 

2.1 프로세스

프로세스는 독립적으로,

고전적 운영체제는 스케쥴링의 단위가 프로세스.  main부터 시작하는 실행의 흐름이 하나

-> 흐름이 여러개 필요하다고 느껴서 -> 멀티프로세스 등장.

(a) : 고전적 프로세스. 프로그램 카운터가 cpu에 딱 하나.

(b) : a 실행하는동안 짧게  b를. 독립적인 순차 프로세스. 실질적으로 프로세스가 하나지만 동시실행으로 보임.

(c) : 한 순간엔 한 프로세스만 실행

 

 

 

 

 

 

trace of processes.

100번지에 dispatcher ->  실행시킬 다음 프로그램 -> 운영체제 스케줄러 코드 

 

timeout 이 타이머 인터럽트. 다시 디스패쳐로 돌아가게 됨.

모드 스위치 발생하여, 유저 프로세스의 A의 문맥 저장 -> 타이머 인터럽트 핸들러가 100번지에 디스패쳐가 있다고 가르쳐줌 -> 반복.

 

 

A->B로 문맥전환, 8003 이후 I/O 요청, 다시 모드스위치(timeout과는 다르며 시스템 콜을 호출한 것 -> 시스템 콜 핸들러가 동장)

-> 스케쥴러 동작 -> ~105 동작 0 -> 유저로 돌아가 다시 선택 가능. B는 I/O request가 끝날 때 까지 대기.

이미지에서는 C를 선택해서 실행. 그리고 다시 타임아웃 후 A로, 만약 이단계에서 끝나면 다시 타임아웃.

이런 방식으로 과거엔 하나의 씨피유에 하나의 프로세스가 동작하지만, 여러개의 프로세스를 동시에 실행할 수 있음.

 

 

프로세스 생성

실행되는 프로세스가 프로세스 생성해달라고 시스템 콜(실행 요청), 배치 작업을 시작할 때, 유저가 새로운 프로세스를 만들어 달라고 할 때, 시스템 초기화 혹은 ststem initialization(부팅).

 

부팅 : cpu는 메모리에서 명령어를 롬으로 계속 가져와 실행, 메모리에 매핑 되어있음.

메모리 로드 -> 부트로더 초기화 -> 커널 이미지 메모리 로드 -> 커널이 제어 -> 부팅과정에서 cpu는 메모리 일부만 관리

-> mmu를 켜면 cpu가 전체 메모리를 관리 가능 -> 시스템 관리 프로세스 생성 -> 1번 프로세스의 자식 프로세스로 여러 프로세스가 쭉 만들어짐.(트리 구조)

 

프로세스 종료(termination)

exit 호출 : 자발적 종료

exit(0) : normal exit

exit(n) : error exit

나머지 fatal error(예외발생), killed by another process는 비 자발적 종료. 스스로 종료 불가능, 운영체제에 시스템 콜로 종료해달라고 요청해야함.

0으로 나누는 등의 행위 : 운영체제에 exeption handler 발생, 프로세스에 시그널 보냄.

 

프로세스 상태(states)

실행 : cpu사용

준비 : 실행 가능하지만 다른 프로세스가 실행할 수 있도록 일시 정지

대기(블록) : 실행할 수 없음

 

1 : running 상태에서 인풋 기다리며 blocked, io요청한 놈도 대기하며 blocked

2 : 스케쥴러에 의하여 timer interrupt -> ready, ready하던 프로세스는 running

3 : 마찬가지

4 : running하다 blocked된 프로세스들을  ready로 바꾸어준 후 running해야함.

 

 

Queues for Scheduling

프로세스가 만들어지면 admit에 의해 ready queue -> 대기 -> dispatcher에 의해 실행 -> time out에 의해 ready queue로.

Event wait : 프로세스가 IO요청 -> 특정 이벤트 기다리는 wait queue로 -> 이벤트발생 -> 해당 프로세스 ready 상태

 

 

Suspend state

Blocked -> Suspend : OS or User에 의해 잠시 멈춘 것

New : 만들어진 프로세스를 실행시킬것을 물어보는 스케쥴러 존재

Exit : Running 끝나면 자원회수를 위한 과정

 

 

Two suspend state

완전한 프로그램 상태.

Admit이 판단하여 실행안시킬거면 ready/suspend

io요청 이후  block된 상태에서도 suspend가능 -> blocked/suspend

running중 ready/suspend로도 가능.

 

 

implementation(이행) of processes

가장 하위계층에 스케쥴러가 있으며, 다수의 프로세스들이 스케쥴러(운영체제 코드)를 공유.

위 이미지는 인터럽트가 발생할 때 운영체제의 가장 하위 레벨에서 수행하는 작업.

 

 

2.1.7 다중 프로그래밍 모델링

만약 프로세스가 시간 중 80%를 I/O를 기다리면서 보낸다면, 적어도 10개의 프로세스가 메모리에 적재되어야 CPU낭비를 10%이하로 줄일 수 있음. -> 멀티프로세스의 정도를 높이려면 프로세스를 많이 실행

 

 

 

2.2.1 스레드의 사용

 

각각의 실행의 흐름. 프로세스 동그라미 하나에 실행의 흐름이 여러개(이미지에선 3)

멀티코어 환경의 등장으로 실질적인 스레드 활용 시작

멀티스레드 환경에서의 웹서버 : 디스패처(네트워크로부터 도착하는 작업 요청을 읽어들임)가 대기상태의 스레드에게 요청 -> 잠든 스레드를 꺠워 대기에서 준비상태가 되도록 함 -> 작업 스레드에게 전달 -> 작업스레드는 웹 브라우저에 표현된 페이지 요청하여 클라이언트에 전달

 

a : 디스패처 스레드 b: 작업 스레드

순차적으로 동작

 

서버 구성하는 세가지 방법.

블롱킹 시스템 호출 : 프로그램을 쉽게 해줌

병렬성 : 성능 향상

 

2.2.2 고전적인 스레드 모델

 

과거 : 1 프로세스 1스레드, 현재 : 1프로세스 다스레드

프로세스 내부의 스레드는 동일한 주소공간을 가지며, 동일한 전역변수 및 자식프로세스, 알람, 시그널 등을 공유.

각자의 스택이 존재하여 서로의 스택을 참조할 수 있음.