데이즈

안녕하세요? 허니입니다. 운영체제에서는 스케줄링 정책을 어떻게 하냐에 따라 효율적인 자원 분배를 할 수 있고, 상황에 따라 쓰이는 스케줄링 기법들이 모두 다르기 때문에 운영체제 설계할때 가장 어려운 부분입니다. 때문에 스케쥴링에 대해 잘 알아야 운영체제 정책 및 설계를 잘 할 수 있습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하여 포스팅을 시작하며 언제든지 질문은 환영입니다.

오늘의 주제

- 좋은 스케줄링이란?

- 프로세스 스케줄링 알고리즘은?

스케줄링 (Scheduling)

우리가 살아가는데 스케줄이라는 건 왜 필요할까?

24시간 주어진 하루를 헛됨 없이 보다 알차게 보내기 위해 우리는 스케줄을 짠다. 프로세스 역시 알찬 일정을 수행하기 위해선 적절한 기준에 맞춘 스케줄링이 필요한 것이다.

 프로세스 스케줄링이란?

프로세스 스케줄러의 임무는 바로 준비, sleep, 실행 등의 상태에 놓인 프로세스들을 주어진 조건에 교체함으로써 CPU에 의해 보다 효율적으로 처리되도록 하는 것이다. 이와 같은 임무를 수행하기 위해서 프로세스 스케줄러가 해야 할 일은 우선 모든 프로세스의 상태를 파악하는 일이다. 프로세스의 상태 파악 후 프로세스가 준비 상태이면 준비 queue에, sleep 상태이면 sleep queue에 분배하는 작업을 하게 된다. 앞서 Process Life Cycle에서 언급되었던 것처럼 프로세스의 각 상태를 알기 위해 각각의 상태마다 리스트가 마련된다. 준비리스트에 놓인 프로세스는 각각 우선순위가 주어져 가장 높은 우선 순위의 프로세스의 차례로 CPU를 차지하게 된다. 그러나 sleep 리스트는 순위가 없다. 왜냐하면 sleep 상태에서 벗어나는 것은 정해진 순위에 의해서가 아니라 sleep상태로 머물러야 했던 조건들이 해결되면 다시 실행 상태로 돌아가기 때문이다. 이처럼 서로 다른 사이클로 프로세스들이 운영되기 때문에 프로세스 스케줄링이 필요한 것이다. Dispatcher는 프로세스 스케줄러에 포함된 하나의 요소로서 프로세스 스케줄러에 의해 선택된 프로세스에 CPU를 할당하는 기능을 하며 이때 프로세스의 여러 정보들을 레지스터에 적재(load)하고 프로세스 처리가 새로이 시작될 때 올바른 위치로 가게 해준다. 예를 들어 sleep 단계에 놓인 프로세스들을 sleep queue로 모아주는 작업이 바로 Dispatcher에 의해 수행되는 것이다.

잠깐, 상식! 레지스터(register)란? 컴퓨터의 CPU에서 사용되는 고속의 기억장치. CPU에서 연산을 수행하기 위해서는 반드시 피연산자가 레지스터에 존재해야 한다. 일반적으로 레지스터의 개수가 많을수록 처리속도가 빨라진다. 그러나 레지스터를 구현하는 비용이 많이 들기 때문에 일정수의 레지스터를 구현하게 된다.

그림 16 프로세스 스케줄링

그렇다면 좋은 프로세스 스케줄링 정책이란 어떤 것 일까.

위의 모든 조건을 갖추게 할 수 있는 시스템 설계자가 있다면 그 사람은 분명 세상에서 가장 완벽한 설계자일 것이다. 그러나 안타깝게도 이러한 모든 조건이 충족되는 프로세스 스케줄링은 확실히 불가능하다. 시스템 설계자는 어느 조건을 만족시키는 것이 좋은 스케줄링인가를 판단해 그에 적절한 스케줄링 알고리즘을 선택하게 되는 것이다.

프로세스 스케줄링 알고리즘

어떤 문제가 우리 앞에 주어졌을 때 그것을 풀기 위한 절차가 필요하다. (절차라는 것은 이미 일정한 처리의 순서가 마련되어 있는 것을 말한다.) 병원을 찾으면 우선 접수를 하고 접수순서에 따라 의사를 기다리고 진료를 받고 약을 짓고 마지막으로 진료비를 납부하게 되면 된다. 그러나 이 한가지의 절차만 존재한다면 병원은 아마도 환자들의 불만을 항상 들어야 했을 것이다. 초를 다투는 응급 환자의 발생시 또한 진료시간이 끝난 후 환자 발생시를 위해 응급실이라는 별도의 환자처리방법을 만들어 놓았다. 프로세스 스케줄링 알고리즘 역시 단순히 하나의 방법만이 쓰이는 것이 아니라 알고리즘에 문제가 발생하게 되면 그것을 보안해 나가며 계속 발전해 나가고 있는 것이다. “프로세스들이 어떤 절차를 통해 처리되어질 것인가” 하는 것을 알고리즘이라고 한다. 프로세스들은 다음과 같은 알고리즘에 의해 수행된다.

 FCFS (First Come First Served)

말 그대로 먼저 도착한 프로세스를 먼저 처리하는 방법이다. 이 방법의 가장 큰 장점은 구현하기가 쉽다는 것과 공평하다는 것이다. 그러나 가장 뒤에 들어온 프로세스가 가장 시급한 업무를 갖고 있다면 어떨까. 그 시급한 업무는 두발을 동동 구르며 안타까워하지 않을까. 바로 이러한 문제가 발생했을 경우 FCFS는 속수무책인 것이다. 또한 긴 작업이 짧은 작업을 기다리게 할 경우 평균 처리 시간이 휠씬 느려진다. 간단한 예를 한번 들어보자.

예제) job A = 7초, job B = 3초, job C = 2초

처리1.  A    ->   B    ->    C

       7초       10초        12초

평균 처리 시간= 7 + 10 + 12 / 3  = 9.666...

처리1.  A    ->   B    ->    C

       2초        5초        12초

평균 처리 시간= 2 + 5 + 12 / 3  = 6.333...

위의 예에서 살펴 보았듯이 A, B, C 작업의 총 처리 시간은 12초로 처리1과 처리2과가 똑같다. 그러나 7초의 긴 시간이 소요되는 작업이 앞에 놓인 처리1의 경우 평균처리시간이 9.666초인데 비해 처리2에 경우 6.333의 평균처리시간이 소요되었다.

 Priority Scheduling (우선순위 스케줄링)

이 알고리즘은 중요한 작업들에 우선권을 주어 우선순위가 가장 높은 작업을 먼저 처리하도록 하는 방법이다. 그렇다면 과연 어떤 조건을 가진 작업들이 우선순위를 갖는가. 그것은 시스템 설계자의 자유의지이지만 다음과 같은 보편적인 기준이 있다. 외부적인 우선순위는 사용자의 제시에 따라 이뤄지는데 사용자가 작업처리비용을 더 지불하거나 최고경영자가 급히 처리해야 할 업무를 지시하는 경우로써 이러한 우선순위를 결정하는 것은 OS가 통제할 수 없는 것이다.

내부적인 요인에 따른 우선순위의 근거는 일반적으로 다음과 같다.

Priority Scheduling 의 단점으로는 우선순위에서 자꾸 밀려 영영 처리될 수 없는 프로세스가 생겨날 가능성이 있다는 것인데 이럴 때를 대비해 시스템 내에 오랫동안 머물렀던 작업들에게 우선 순위를 높여주는 aging 방법이 고안되었다.

 Round Robin

라운드로빈의 특징은 하나의 작업에 의해서 CPU가 독점되지 않도록 타임퀀텀을 정해 놓고 타임퀀텀을 다 쓰고 나서도 처리가 끝나지 않으면 그 작업을 준비상태 큐의 맨 뒤로 놓이게 하는 방법이다. 이 방법은 FCFS 스케줄링 방법을 보완해준 것으로 예 2-1에서 설명했듯이 처리시간이 긴 작업이 앞자리를 차지하고 있을 경우 평균 처리 시간이 길어져 작업처리가 효율적이지 못한 경우에 많은 도움이 된다. 라운드로빈의 성능은 타임퀀텀 크기에 큰 영향을 받는다. 극단적으로 타임 퀀텀이 매우 크다면 라운드로빈은 FCFS와 다를 바가 없는 것이다. 다시 말해 타임퀀텀의 크기가 증가되면 response time이 길어지고 타임퀀텀이 감소하면 response time이 짧아진다.

간단한 예를 하나 들어보자.

예제)

다음과 같은 처리시간을 요구하는 작업의 경우

a=5초, b=3초, c=1초

타임퀀텀 1초일 때 c의 response time은 얼마일까.

a 1초, b 1초, c 1초 => response time : 3초

타임퀀텀 2초일 때 c의 response time은 얼마일까.

a 2초, b 2초, c 1초 => response time : 5초

 Multiple queue

공통적인 특성을 가진 작업들끼리 모아 서로 다른 클래스로 구성하여 클래스마다 각각의 queue를 구성하는 것을 Multiple queue라고 한다. 예를 들어 카메라를 통한 실시간 동영상 입력을 컴퓨터 시스템이 받아드리는 경우와 웹브라우저를 통해 자료를 전송받는 것은 대단한 차이가 있는 작업이다. 카메라 입력의 경우 1초라도 시간을 놓쳐버리면 데이터가 망가져 버리는 것은 너무도 당연한 노릇이다. 그러나 웹브라우저를 통한 자료 전송은 전송이 중간에 끊어지면 재전송을 실행해도 큰 문제가 되진 않는다. 이와 같이 특성이 다른 작업을 하나로 모아 놓는다면 실수를 범하기가 쉬울 것이다. 그렇기에 Multiple queue를 통해 카메라 입력 작업과 웹브라우저 자료전송을 따로 따로 관리하게 되는 것이다.

그림 17 Multiple Queue

그러나 Multiple queue로 스케줄링을 할 경우 CPU가 하나일 때는 문제가 발생하게 된다. 바로 하나의 run queue만이 존재하므로 각기 다른 특성의 작업들을 수행해내기가 어려운 것이다. 5개의 Multiple queue가 구성되었다면 run queue 역시 5개가되어야지 서로 손발이 맞게 일이 처리되는 것이다.

 Shortest job first Scheduling

이 방법은 가장 짧은 시간에 처리될 수 있는 작업을 가장 먼저 수행하는 것이다. 그러나 이것은 이론만이 뒷받침 될 뿐 실행되기는 불가능하다. 하나의 프로세스가 얼마만큼의 작업을 해야 끝날지를 CPU는 알 수 없기 때문이다. 말 그대로 그것은 해봐야 안다.

요점정리

 Scheduling

1) FCFS(First Come First Served)

먼저 도착한 프로세스를 먼저 처리하는 방법이다. 이 방법의 가장 큰 장점은 OS를 구현하기가 쉽다는 것과 공평하다는 것이다.

2) Priority Scheduing (우선순위스케줄링)

이 알고리즘은 중요한 작업들에 우선권을 주어 우선순위가 가장 높은 작업을 먼저 처리하도록 하는 방법이다.

3) Round Robin

라운드로빈의 특징은 하나의 작업에 의해서 CPU가 독점되지 않도록 타임퀀텀을 정해 놓고 타임퀀텀을 다 쓰고 나서도 처리가 끝나지 않으면 그 작업을 준비상태 큐의 맨 뒤로 놓이게 하는 방법이다.

4) Multiple queue

공통적인 특성을 가진 작업들끼리 모아 서로 다른  클래스로 구성하여 클래스마다 각각의 queue를 구성하는 것을 Multiple queue라고 한다.

5) Shortest job first Scheduling

가장 짧은 시간에 처리될 수 있는 작업을 가장 먼저 수행하는 것이다. 이 방법은 이론만이 뒷받침 될 뿐 실제적으로는 수행이 불가능하다.

안녕하세요? 허니입니다. 운영체제에서 매우 중요한 기능 중에 뽑으라고 하면 저는 쓰레드를 선택할 것 같습니다. 정말 어렵다면 어렵고, 쉽다면 쉬운 스레드에 대해 포스팅 하겠습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다. 

오늘의 주제

 스레드(Thread)란?

 Process는 어떤 방법으로 의사소통을 할 수 있는가?

커널 스레드(kernel thread)의 등장

커널 내의 스택이 하나이기 때문에 처리속도가 떨어지는 것을 걱정한 시스템 설계자는 커널스레드를 구상하기 시작했다. 바로 커널스레드가 각자가 스택을 가짐으로써 동시에 여러 프로세스나 커널 내부에서 수행을 할 수 있게 되는 것이다. 바로 벽돌공이 쉼 없이 벽돌을 쌓을 수 있도록 계속해서 벽돌을 제공할 수 있는 새로운 시스템을 만들어낸 것이다.

그림 10 커널스레드가 있을 경우

스레드란 무엇인가? 프로세스의 처리속도를 높이기 위해 하나의 프로세스가 수행해야 할 여러 작업들을 나누어 수행할 수 있도록 설계된 것이 바로 스레드이다. 다시 말해 1개의 프로세스를 3개의 스레드로 구성한 것은 3개의 프로세스와 같은 처리속도를 낼 수 있는 것이다. 3개의 프로세스가 수행되는 것과 3개의 스레드가 수행되는 것이 처리속도에서 큰 차이가 없다면 시스템 설계자는 그냥 프로세스를 통해 작업을 수행하지, 무엇 때문에 스레드라는 새로운 처리과정을 통해 작업을 수행하려 하는 것일까. 분명 3개의 프로세스를 구성하는 것과 3개의 스레드를 구성하는 데는 뭔가 차이점이 존재하기 때문일 것이다. 스레드는 시스템 설계자가 하나의 작업처리 환경을 구축하는데 있어 막대한 수고를 덜어주는 매력이 있다. 그 매력은 바로 프로세스와의 차이에서 찾아볼 수 있다.

프로세스와 스레드의 분명한 차이로는 프로세스는 자신만의 보호영역을 갖고 있지만 스레드는 자신만의 보호영역을 갖고 있지 않다.

그림 11 프로세스와 스레드

잠깐, 상식! 보호영역(protected location)이란? 시스템의 동작 및 관리에 중요한 역할을 담당하는 정보가 저장되어있는 기억장소 영역을 말한다. 따라서 이러한 영역의 내용은 사용자가 직접 변경할 수 없고 중간에 위치한 OS에 의해 특정한 경우에 한해 제한적으로 갱신될 수 있도록 보호한다.

스레드가 자신만의 보호영역을 갖고 있지 않다는 말은 바로 한 프로세스에 존재하는 모든 스레드들은 프로세스의 상태를 공유한다는 의미가 된다. 예를 들어 스레드들은 똑같은 메모리 공간에 존재하고 똑같은 함수들과 똑같은 데이터를 참조한다. 하나의 스레드가 변수를 변경한 이후 다른 스레드들이 변수에 접근할 때 변경된 변수를 참고 할 수 있는 것이다. 별도의 communication이 스레드간에는 필요하지 않다는 뜻이다. 하나의 스레드가 한 파일을 읽기 위해 파일을 open하면 모든 다른 스레드들도 그것을 읽을 수 있다. 그러나 프로세스들은 그러한 정보를 고유하기 위해서-즉, 메모리를 공유하기 위해서- IPC라는 별도의 통신 방법이 필요하다. 이후 IPC(interprocess communication)에서 자세히 배우게 되겠지만 프로세스는 자신의 보호영역 안에서 실행되기 때문에 별도의 의사소통시스템이 필요하다.

동사무소를 예로 들어보자.

한 사람의 직원을 가진 동사무소가 있다. 동사무소가 제공하는 많은 서비스들이 한 직원(프로세스)의 손을 걸쳐 해결해야 하기 때문에 그는 여러 업무를 제각각 처리하고 또 다시 서로 관련된 여러 업무들을 연결하는데 많은 시간을 필요로 할 것이다.

삽화 1 직원 1명인 동사무소

직원이 세 명 있는 동사무소가 있다고 하자(스레드). 그들은 동사무소의 물건들을 공유할 수 있지만 각각 전문화된 기능들을 수행할 수 있을 것이다. 결국은 동사무소를 이용하는 주민들이 보다 질 높은 서비스를 제공받게 될 것이다.

삽화 2 직원이 여러 명인 동사무소

마을에 있는 동사무소의 수를 바꾸는 것은(새로운 프로세스를 생성하는 것) 많은 노력이 들지만 새로운 직원을 (새로운 스레드)고용하는 것은 매우 간단할 것이다. 또한 직원들 사이의 상호작용은 매우 간단하겠지만(스레드 사이의 작용) 아랫마을 동사무소와 관련된 일을(프로세스 사이의 작용) 처리하기 위해선 보다 복잡한 과정이 필요한 것은 당연하다. 다중 스레드 프로그램을 작성할 때 프로그램의 99%는 전과 동일하고 나머지 1%만이 스레드들을 생성하고 여러 가지 활동을 조정하는데 쓰인다. 시스템 설계자에게 있어 이보다 더 큰 매력은 없을 것이다. 그러나 스레드를 사용할 때의 문제점은 하나의 프로세스가 작업을 처리할 때에 비해 오류가 많이 발생한다는 것이다. 스레드의 생성은 간단했지만 보다 세심한 관리가 필요한 것이다.

따로 따로 떨어져 있는 프로세스들은 어떤 방법으로 의사소통을 할까?

앞서 설명했듯이 프로세스는 각각 자신의 고유영역에서 수행되기 때문에 Communication이 필요하다. 프로세스간에 Communication이 없다면 프로그램 수행 후 나온 결과물은 어떨까. 하나의 예를 들어보자. 갑씨는 5월달 전기료를 깜빡 잊고 내지 않았다. 한국전력의 컴퓨터시스템 내에 A프로세스는 갑씨가 5월 전기료를 미납했음을 처리하였다. 갑씨는 6월달에 두 달치의 전기료를 함께 납부하였다. B프로세스는 5월 6월 전기료가 함께 납부되었음을 처리하였다. 그렇다면 만약 A프로세스와 B프로세스간에 의사소통이 이뤄지지 않았다면 7월달 갑씨에게는 어떤 일이 생길까. A프로세스가 마지막으로 처리되었다면 갑씨는 5,6,7월, 석 달치의 전기료가 미납되었음을 통보받을 것이고 B프로세스가 마지막으로 처리되었다면 7월달의 전기료 미납만 통보받을 것이다. 바로 프로세스간에 의사소통이 이뤄지지 않았기 때문에 발생된 일이다. 그렇기에 IPC(interprocess communication)이 필요한 것이다. IPC에는 다음과 같은 방법들이 있다.

1. Pipe

파이프란 하나의 프로세스에 의해 출력된 데이터의 값을 다른 프로세스의 입력으로 전달되도록 하는 방법을 말한다. 이것은 다음과 같은 특성을 갖고 있기 때문에 마치 물파이프와 같은 성질을 갖는다고 표현된다..

그림 12 Pipe

a. 2개의 프로세스간에 하나의 pipe만이 연결되었다면 한쪽은 정보를 무조건 주기만 하고 다른 한쪽은 무조건 받기만 하는 단방향 시스템이 되고 만양방향의 의사소통이 가능하기 위해서는 2개의 pipe가 필요한 것이다.

b. 1대 1의 의사소통만이 가능하다.

c. 보내어진 순서대로 받는다.

d. 용량제한이 있기 때문에 파이프가 꽉 차면 더 이상 write를 할 수 없다.

2. Signal

시그널은 예전에 널리 사용되었던 무선호출 수신기-Radio Pager(삐삐)-와 유사한 성질을 갖고 있다. 호출을 할 때 우리는 상대방이 호출을 받을 수 있는 상태인지 받을 수 없는 상태인지는 모른 채 무조건 호출을 보낸다. 또한 호출을 받았을 경우 우리는 번호나 메시지 등을 확인한 후 전화를 해줄지 또는 호출을 무시할지를 결정한다. 시그널은 다음과 같은 특징을 가진다.

a. 발신자는 Signal number로 표현되는 시그널을 수신자에게 보낸다.

b. 수신자인 Signal handler는 시그널 수신을 받은 후 어떤 반응을 취할지 결정한다. Signal handler를 동작시키든지, 아니면 날아온 시그널을 무시할 수 있다.

c. 수신자에게 시그널은 비동기적이다.

그림 13 시그널

질문) 중요한 자료를 read하고 있는데 Signal이 들어오면 어떻게 됩니까?

답) 일단 Signal을 처리하고 read를 다시 한다.

질문) Signal은 시스템 내에서 어떤 방식으로 체크됩니까?

답) 커널이 디스패춰를 부르기 전에 Signal을 체크한다.

질문) 하나의 프로세스 안에 여러 개의 스레드가 존재할 경우 handler는 누가 수행합니까?

답) Signal마다  handler를 갖는데 중복 실행을 막기 위해 Signal mask를 갖는다. Signal mask란 스레드마다 받는 Signal list를 말한다. 스레드가 Signal mask를 설정해놓으면 그 설정에 따라 Signal을 골라서 받을 수 있다.

질문) Signal 1이 수행되고 있는데 Signal 2가 발생하면 어떻게 처리합니까?

답) 보통의 경우 Signal 2를 Queue에 저장하고  Signal 1을 먼저 수행한다. 그러나 Signal의 처리방법은 운영체제 마다 다르고 시스템 설계자의 자유의지를 반영한다.

3. 공유메모리(Shared memory)

공유메모리는 통신하는 프로세스들간에 메모리를 공유하도록 하는 것이다. 같은 메모리 공간을 공유함으로써 정보교환을 이루는 것이다. 프로세스들은 공유메모리를 자신의 메모리인 것처럼 접근할 수 있다. 하나의 프로세스가 공유메모리를 변경하면 다른 프로세스들은 공유메모리에 접근함으로써 변화의 내용을 알 수 있는 것이다. 공유메모리 방법이 어떤 식으로 동작하는지 데이터베이스 시스템의 동작을 통해 간단히 알아보자. 한 기업의 인사부에서 새로 10명의 신입사원을 채용했을 때 이 기업이 데이터베이스 시스템을 사용하고 있지 않다면 인사부는 기업 내에 각 부서마다 서면 통지를 통해 신입사원이 들어왔음을 통보하게 되고 통보를 받은 각부서는 제각기 입력을 통해 신입사원이 10명 입사하였다는 사실을 자기 부서의 컴퓨터에 기록하게 된다. 그런데 신입사원 연수 도중 1명이 사정에 의해 회사를 그만 두었다면 신입사원이 9명으로 줄었다는 사실을 각 부서마다 다시 서면 통보해야 하는 것이다. 그리고 또 각 부서에서는 다시 또 자기 부서의 컴퓨터에 변경된 사항을 입력해야 한다. 만약 다섯 개의 부서가 있다면 똑같은 과정을 각 부서마다 다시 수행해야 하는 것이다. 오직 한 가지의 변화 때문에 말이다. 여기서 신입사원 1명이 줄어 9명이 되었다는 것을 하나의 프로세스를 통해 데이터베이스-공유메모리-에 변화된 상황을 알려놓으면 모든 부서의 프로세스들은 간단히 그 변화를 깨닫게 되는 것이다. 또 이것은 경리부에서 한 달치 월급을 계산할 때 신입사원 10명의 월급을 계산할 오류가 줄어들게 해준다. 데이터베이스의 데이터가 변화된 순간, 월급을 계산하는 프로세스 역시 그 변화를 즉시 알 수 있기 때문이다. 정보를 공유해 작업을 처리해야 하는 모든 집단(기업, 학교, 병원, 경찰서, 동사무소, 대형매장 등)은 바로 공유메모리를 바탕으로 한 데이터베이스를 사용하고 있어 정보교환에 편리와 안전을 함께 이루는 것이다.

그림 14 공유메모리(Shared Memory)

4. 메시지 큐(Message queue)

메시지 큐란 데이터 통신에서 송신측과 수신측의 중간 단계 노드에서 전달할 메시지를 임시보관하기 위하여 사용되는 대기열을 말한다. 하나의 시스템 안에서는 프로세스간에 pipe나 Signal을 사용해 의사 소통을 했지만 부산에 떨어져 있는 친구의 컴퓨터에 pipe나 Signal을 통해 편지를 주고 받을 수는 없는 노릇인 것이다. 그렇기에 Message queue라는 의사소통방법이 고안된 것이다. 바로 송신측과 수신측 중간에 메시지를 보관하는 대기열이 존재하기 때문에 거리가 떨어져 있는 시스템간에 의사소통이 가능한 것이다. Message queue의 대표적인 예는 바로 인터넷 통신이다. 인터넷을 통한 통신은 때로는 미국을 때로는 일본을 연결해 자료를 전송받을 수 있다. 이렇듯 하나의 시스템이 아닌 거리가 떨어져있는 시스템간의 의사소통은 하나의 메시지 안에 전달되어야하는 의미가 확실해야한다.

잠깐, 상식! 메시지란 하나의 의미를 가지고 있는 문자들의 집합을 말한다. 데이터통신에서 메시지는 논리적으로 독립된 하나의 단위로 간주된다.

그림 15 Message Queue

a. read/writer와 같이 연속된 데이터를 주고 받는 것이 아니라 독립된 메시지 단위의 데이터를 주고 받는다.

b. 각각의 메시지 의미가 정의되어 있지 않다. 메시지 의미는 보내는 사람에 의해 정의되기 때문이다. 다만 메시지가 교환되는 양식은 정의되어 있어야만 교환이 제대로 이뤄질 수 있는 것이다.

c. 공유해야 하는 정보의 규모가 적다. 메시지 의미가 보내는 사람들에 의해 정의되기 때문에 공유되는 정보 역시 적을 수밖에 없을 것이다.

d. 공유되는 정보의 양이 적기 때문에 네트워크 환경으로 확장하기 쉽다.

잠깐, 상식! 네트워크란? 우리말로 바꾸어 표현하면 통신망이라 할 수 있는데 데이터 통신이라는 공통의 목적을 바탕으로 두 개 이상의 장치들이 연결되어 있는 통신구조이다. 이러한 통신구조에는 데이터통신을 원하는 컴퓨터시스템뿐만 아니라 데이터 통신을 수행하기 위해 사용되는 전송장치, 교환장치 등이 통신선로에 의하여 연결되어 있다.

앞서 설명한 프로세스 통신방법에 있어 어느 것이 가장 적절한 방법이라고 단편적으로 말할 수는 없을 것이다. 프로세스가 어떤 환경에서 서로 통신하느냐에 따라 적절한 방법은 달라질 것이다. 현재 시스템의 환경을 제대로 파악하고 보다 적절한 방법을 구현해 주는 것 역시 시스템 설계자의 몫인 것이다. 참고적으로 스레드간에 의사소통은 전역 변수(global variable)를 사용함으로 가능하다. 그렇기에 별도의 IPC는 필요 없는 것이다.

잠깐, 상식! 전역변수란 프로그램 전체영역에서 사용될 수 있도록 선언된 변수를 말한다. 그 반대로 지역변수(local variable)는 일정한 영역에서만 사용될 수 있도록 선언된 변수를 말한다.

요점정리

 스레드란?

프로세스의 처리속도를 높이기 위해 하나의 프로세스가 수행해야 할 여러 작업들을 나누어 수행할 수 있도록 설계된 것이 바로 스레드이다.

 프로세스와 스레드의 차이

프로세스는 자신만의 보호영역을 갖고있지만 스레드는 자신만의 보호영역을 갖고 있지 않다.

 IPC란

프로세스는 각각 자신의 고유영역에서 수행되기 때문에 Communication이 필요한데 다음과 같은 방법이 사용된다.

1. Pipe

2. Signal

3. Shared memory

4. Message queue

안녕하세요? 허니입니다. 운영체제의 프로세스의 처리 속도를 어떻게 하면 성능 효과를 볼 수 있을까요? 하드웨어는 고정된 성능과 자원을 제공하기 때문에 이를 효과적으로 활용하는 것이 프로세스의 처리 속도를 향상시키는 키가 될 수 있습니다. 이번 주제는 프로세스 관리가 어떻게 되는지를 알아야 이해하실 수 있으니 프로세스 관리에 대해 먼저 선행 스터디를 하시고 읽어주세요.

오늘의 주제

 Process의 처리속도를 높이고 싶다면

만약 하나의 컴퓨터 시스템에 3개의 CPU를 설치한다면 처리속도 역시 3배로 빨라질까

컴퓨터의 사용영역이 계속 확대되면서 사용자들은 좀 더 빠른 처리속도를 원하게 되었다. 많은 전문가들은 보다 빠르게 보다 많은 양의 작업을 처리하기 위해 여러 방법을 고려했다. 그 중 한가지 방법이 바로 CPU의 개수를 늘리는 것이었다. 그러나 CPU의 개수를 늘려 놓았는데도 처리속도가 빨라지지 않아 한때 시스템 설계자들은 매우 의아해하였다. 그렇다면 무엇이 문제였을까. 컴퓨터에 있어서 인간의 두뇌와 같은 CPU의 개수가 처리능력에 향상을 가져오지 못하다니 말이다. 바로 각각의 CPU가 처리해야 할 작업을 나누어 놓지 않았기 때문이었다. 다음과 같은 예를 하나 들어보자. 어느 컴퓨터 내부에 3개의 CPU를 설치해 놓았다고 생각해보자. 이 3개의 CPU가 처리해야 하는 계산은 총 30번인데 1번의 계산에 1초씩의 시간이 걸린다. A의 시스템에서는 3개의 CPU 설치 이후 더 이상의 조절작업을 하지 않아 CPU가 직렬연결 상태라면 30번의 계산은 다음 그림과 같이 수행된다. 그렇기 때문에 CPU가 하나인 컴퓨터 시스템과 계산속도의 차이가 없는 결과가 나타나게 되는 것이다.

그림 5 CPU의 직렬연결

바로 CPU가 1개이건 2개이건 작업이 일렬로 처리될 때는 속도에 별다른 차이가 없는 것이다. 바로 주어진 작업을 CPU마다 병렬처리로 조정해 놓아야만 3개의 CPU가 10개씩의 계산을 분담해 동시 처리가 가능해 지는 것이다. 다시 말해 30초의 작업시간이 10초로 빨라질 수 있는 것이다. 다음의 그림과 같이 말이다.

그림 6 CPU의 병렬연결

그러나 컴퓨터 시스템의 처리속도를 높이는 것과 관련된 문제는 여기서 끝나지 않았다. CPU가 2개 이상일 때 이것을 통해 동시에 수행되는 프로세스를 운영체제 구조적으로 뒷받침해줄 수 없는 것이다. 그것은 바로 커널 스택이 하나라는 OS구조상의 문제가 표면으로 나타난 것이다. 사용자영역의 프로세스들이 커널 스택의 사용을 위해서 차례를 기다려야 하는 것이다. CPU가 하나일 경우에는 커널 스택이 하나라는 것이 작업을 수행되는데 걸림돌로 작용하지는 않았었다. 그러나 CPU가 3개일 때 3개의 프로세스가 동시 처리가 가능해진다면 어떨까. 이를 구체적으로 설명하기 앞서 스택의 역할을 살펴보기로 하자. 메모리를 쪼개어보면 다음과 같은 process image가 나타난다.

그림 7 Process Image

스택은 프로그램이 수행되기 위한 모든 정보를 갖고 있는 부분으로 프로세스가 수행되는 동안 계속해서 변화되는 수행값을 저장하기 위해 메모리 확보를 하게 된다. 또한 스택포인터라는 것은 가장 최근 스택에 삽입된 자료의 위치를 가리키고 있는 포인터를 말한다.

잠깐, 상식! 포인터란 어떤 하나의 자료가 저장되어 있는 메모리의 위치 또는 주소를 가르키는 정보를 말한다. 프로그램에서는 이러한 정보를 통하여 자료가 저장되어 있는 위치로 직접이동할 수 있다.

예를 들어 97년 한 해 동안 A라는 학생은 국어시험에서 다음과 같은 성적을 얻었다.

* 1학기 중간고사 80점, 기말고사 90점

* 2학기 중간고사 70점 기말고사 100점

총 평균 점수를 계산하는 프로그램을 수행한다면 그 수행과정에서 스택은 어떤 역할을 할까. 평균점수를 얻어내기 위해선 4번의 시험점수를 더하는 처리와 최종적으로 더한 값을 4로 나누는 작업이 이뤄져야 한다. 이 작업을 1학기 점수를 계산하는 프로세스 1과 2학기 점수를 계산하는 프로세스 2로 나누어 수행한다고 생각해보자. 프로세스 1이 계산한 80+90=170에서 170이라는 결과값이 바로 스택에 기억되어 다음 처리를 가능하게 해주는 것이다. 170이라는 점수가 저장되어 있어야만 프로세스2에 의해 2학기의 국어성적을 더할 수 있기 때문이다. 스택은 프로세스가 계산을 수행할 때마다 메모리를 확보해 임시 변수들을 저장하는 공간이다.

그림 8 스택의 역할

잠깐, 상식! data segment : 작업을 처리하기 위한 자료(하나의 사실이나 숫자 통계치)등의 함수를 갖고 있는 부분으로 내용의 값을 디스크에서 가져온다.

여기에서 잠깐 함수라는 개념을 짚어보자.

우리가 그림 2-9에서 A학생의 국어 평균점수를 계산해 보았다. 그렇다면 고려고등학교 모든 학생의 평균국어성적을 계산해 본다면 어떨까. 뭔가 보다 간편한 처리가 있어야 할 것 같지 않은가. 함수를 정의해 보자면 프로그램 내에서 자주 쓰는 기능들을 좀더 편리하게 사용할 수 있도록 정의해 놓은 것이다. 함수는 프로그래머의 의도에 따라 정의되기도 하고 이미 다른 사람에 의해 정의된 함수가 사용되기도 한다.

text segment code : 컴퓨터 시스템이 이해할 수 있는 기계어 부분으로 내용의 값을 디스크에서 가져온다. 모든 컴퓨터의 기본적인 언어는 0과 1의 배열로 이루어져 있다. data를 처리하기 위해 CPU를 가동시키려면 프로그램은 기계어 형태로 되어있어야 한다. 우리가 어디선가 들어 봤음직한 어셈블리어가 바로 이러한 기계어들인 것이다.

 질문) 프로그램을 수행하다 만약 스택 영역이 부족해지면 어떻게 될까.

 답) 이러한 경우 커널에 의해 자동처리가 된다. 스택으로 할당받은 공간이 가득 차서 스택 포인터가 그 범위 바깥을 접근하게 되면 자동적으로 segmentation fault가 생기고 이렇게 되면 커널이 모자라는 스택 영역을 보충해준다.

지금까지 스택의 역할을 살펴보았다. 그렇다면 앞서 언급한 커널 스택의 문제를 다시 짚어보자. 여러 개의 CPU가 사용되고 있는 경우 커널스택이 하나라면 어떤 일이 발생할까. 예를 들어 벽돌 쌓는 작업을 하는 인부는 여러 명인데 벽돌을 나르는 인부는 1명뿐이라고 가정한다면 어떨까. 벽돌 나르는 인부가 가져다준 벽돌을 모두 쌓은 후 다시 나에게 벽돌이 돌아올 순서가 오지 않는다면 그는 어쩔 수 없이 손을 놓고 있어야 함으로 작업 진척이 더딜 것이다. 마찬가지로 하나의 CPU만이 스택을 사용하게 됨으로 계속 수행-멈춤-수행-멈춤을 반복할 수밖에 없는 것이다. 다시 말해 자신이 작업할 영역을 확보해 줄 때까지 CPU는 아무 일도 할 수 없는 상황인 것이다.

그림 9 커널 스택이 하나일 경우

요점정리

 작업의 처리속도를 높이기 위해서는 CPU가 1개이건 2개이건 작업이 일렬로 처리될 때는 속도에 별다른 차이가 없는 것이다. 바로 주어진 작업을 CPU마다 병렬처리로 스케줄 해놓아야만 동시 처리가 가능해 처리속도가 향상된다.

 CPU 병렬 연결만 해놓으면 속도 향상의 모든 문제는 해결되나?

CPU가 2개 이상일 때 운영체제 구조상의 문제가 어려움으로 발생되었다. 그것은 바로 커널 스택이 하나라는 OS 구조상의 문제가 표면으로 나타난 것이다. CPU가 하나일 경우 커널스택 역시 하나이기 때문에 작업이 수행되는데 걸림돌이 존재하지 않지만 만약 CPU가 3개여서 3개의 프로세스가 동시 처리가 가능해진다면 어떨까. 사용자영역의 프로세스들이 커널 스택의 사용을 위해서 차례를 기다려야 하는 것이다.

 커널 스택 문제의 해결 방안은?

커널 내의 스택이 하나이기 때문에 처리속도가 떨어지는 것을 걱정한 시스템 설계자는 커널스레드를 구상하기 시작했다. 바로 커널스레드 각자가 스택을 가짐으로써 처리속도가 증대되는 것이다.

안녕하세요? 허니입니다. 운영체제에서 가장 중요하다고 볼 수 있는 프로세스는 각 프로그램이 돌아가는데 있어 많은 역할을 하고 있습니다. 때문에 프로세스 관리가 매우 중요하기 때문에 프로세스가 어떻게 처리 되는지에 대해 잘 알아야 하기에 포스팅을 하겠습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 프로세스 관리는 왜 필요한가?

 Process는 어떤 과정으로 처리되어지나?

프로세스 관리는 왜 필요한가?

하나의 컴퓨터 시스템이 오직 한 사람의 사용자만을 위해 존재하고 한번 컴퓨터가 작동할 때 하나의 프로세스만이 작업을 수행한다면 아마도 프로세스 관리라는 말은 나올 필요가 없었을 것이다. 그러나 이러한 시스템이 어딘가 존재한다면 그것은 이미 컴퓨터이기를 포기한 물건일 것이다. 이 시대 컴퓨터 시스템은 하나의 시스템 내에서 통신을 통해 파일을 다운 받으면서 한글 문서를 작성할 수 있듯이 동시에 여러 프로그램의 사용이 가능하다. 또한 대용량의 중앙처리컴퓨터를 놓고 여러 대의 모니터가 설치되어 사용되기도 하고 수천 명이 동시에 PC통신에 접속하기도 한다. 이렇듯 여러 작업이 동시에 이뤄질 때 프로세스들을 제대로 관리하지 않으면 처리가 느려질 것이다. 두말하지 않더라도 결과는 뻔할 것이다. 모든 시스템 사용자들은 자신이 요구한 결과들이 느릿느릿 처리된다면 엔터 키를 계속 내려치거나 대단히 화난 얼굴로 컴퓨터 모니터를 노려볼 것이다. 성격이 급한 사람은 당장 컴퓨터 회사에 전화를 걸어 고장신고를 할지도 모르겠다. 바로 이러한 문제를 피하기 위해 프로세스를 보호해주고 프로세스마다 작업 시간을 할당해주고 그 작업에 우선 순위를 매기는 등의 작업이 바로 프로세스 관리(process management)이다.

프로세스들은 어떤 과정으로 처리되어지나?

하나의 프로세스가 수행되는 동안 시스템 콜에 대한 작업은 어떻게 수행될까. 또한 우선순위가 높은 프로세스가 존재한다는 것은 과연 어떻게 알 수 있을까. 하나의 프로세스처리 과정 중 발생하는 이러한 문제를 해결하기 위해 시스템 설계자는 다음과 같은 조금은 복잡하다고 느껴지는 처리 과정을 구상해 내었다.

그림 1 프로세스 처리과정

위의 그림을 다시 한번 설명하자면,

 1. 사용자 영역(user mode)에서 프로세스A가 수행되고 있다.

 2. 시스템 콜이 호출된다. 수행되던 프로세스 A는 트랩이 걸리고 수행영역은 사용자영역(user mode)에서 커널영역(kernel mode)으로 이동된다.

 3. 커널영역에서 호출한 시스템 콜 작업이 수행된다.

 4. 작업 수행 후 상태에 따라 running 큐나, sleep 큐에 넣는다.

 5. 프로세스A의 인터럽트 이후 처리를 수행하기 이전 보다 우선순위가 높은 프로세스가 있는가를 확인하기 위해 디스패춰(dispatcher)를 부른다.

 6. 디스패춰를 통해 보다 우선순위가 높은 프로세스 B를 선택한다.

 7. 프로세스B로 점프하여 먼저 처리한다.

잠깐, 상식! * 사용자영역(user mode) : 컴퓨터 시스템의 영역 가운데 사용자에 의하여 요청된 프로그램에서 사용되고 있는 영역을 말한다. * 커널영역(kerel mode) : 프로그램이 OS에서 제공되는 기능을 이용하기 위하여 시스템콜     을 호출하여 현재 커널의 코드를 수행하고 있는 상태로 사용자가 요구한 작업을 시스     템 내부에서 처리하기 위하여 컴퓨터시스템이 차지하는 영역을 말한다. * 디스패춰 : 다중프로그래밍 시스템에서 대기열에 기다리고 있는 하나의 프로세스를 선택     하여 CPU의 사용권한을 부여하는 OS 스케줄러 프로그램의 한 부분.

이와 같이 7가지 과정으로 나뉜 프로세스 처리 과정을 살펴보았다. 그러나 단순한 시스템은 1,2,3,1의 과정을 반복한다.

그림 2 1,2,3,1의 과정

그러나 보다 정밀한 OS는 우선순위가 보다 높은 프로세스가 존재하는가를 확인하고 그것을 처리하기 위해 4,5,6,7의 과정을 밟게 되는 것이다. 그렇다면 앞서 언급했던 문맥전환(context switching)은 어느 순간에 이뤄지게 되는 것일까. 바로 6과 7 사이에서 문맥전환이 일어나게 된다. 우선순위가 보다 높은 프로세스가 존재한다면 CPU는 자신이 처리하던 프로세스A를 잠시 멈추고 프로세스B를 수행하게 되므로 문맥전환이 일어나게 되는 것이다. 만약 더 이상 높은 우선순위의 프로세스가 존재하지 않아 프로세스 A가 다시 선택되면 문맥전환은 일어나지 않는다.

그림 3 문맥전환(context switching)

그렇다면 이와 같이 복잡한 과정으로 프로세스를 수행하는 이유는 뭘까. 많은 세월 시스템 설계자들은 어떻게 하면 프로세스를 보다 많이 보다 빠르게 또한 보다 효율적으로(보다 급한 처리를 원하는 프로세스는 보다 빠르게) 처리할 것인가를 고민해 왔다. 그 고민은 하나의 시스템 설계 목표를 세우는데 이르렀다. 바로 처리량(throughput)을 높이고 응답시간(response time)을 낮게 하는 것이었다. 바로 프로세스를 보다 많이 보다 빠르게 처리하기 위한 방법이 7가지 프로세스 처리 순서를 만들어내게 한 것이다.

잠깐, 상식! *쓰루풋(throughput)이란? 주어진 시간에 시스템이 처리하는 일의 양 *반응 시간(response time)이란? 하나의 작업이 시작해서 끝날 때까지의 시간

지금까지 프로세스들이 어떤 방법으로 처리되는가에 대해 이야기해 보았다. 다음과 같은 질문들을 통해 보다 깊이 있는 내용을 살펴보자.

질문1) 커널영역에서 타임퀀텀이 다 되었을 경우에는 어떻게 수행하게 되나?

질문2) 디스패춰 호출을 했을 경우 프로세스A의 결과 값은 어느 영역에 저장되나?

질문3) 커널이 시스템 콜을 수행하고 있을 때 다른 프로세스가 수행될 수 있을까?

답1) 커널영역에서 타임퀀텀이 다 되었을 경우에는 적절한 순위의 수행큐에 저장되게 된다. 저장할 때 flag를 붙여놓아 다음에 취할 action을 표시하게 된다.

답2) 사용자 스택 (User stack) 즉 프로세스 스택에 결과값이 저장된다. (프로세스 스택의 개념은 이후 강의할 것임으로 일단은 설명을 접어두기로 하자.)

답3) 없다. 현재까지 CPU가 하나일 때를 가정한 것이기 때문이다. 여러 개의 프로세스를 만들어놨다 하더라도 실행 프로그램은 오직 하나이다.

요점정리

 프로세스 관리란?

프로세스를 보호해주고 프로세스마다 작업 시간을 할당해주고 그 작업에 우선 순위를 매기는 등의 작업이 바로 프로세스 관리이다.

 프로세스들은 어떤 과정?

 1. 사용자영역에서 프로세스A가 수행되고 있다.

 2. 시스템 콜이 호출된다. 수행되던 프로세스 A는 인터럽트가 걸리고 수행영역은 사용자영역에서 커널영역으로 이동된다.

 3. 커널영역에서 시스템 콜을 호출한 작업이 수행된다.

 4. 작업 수행 후 상태에 따라 수행, sleep queue에 넣는다.

 5. 프로세스A의 인터럽트 이후 처리를 수행하기 이전 보다 우선순위가 높은 프로세스가 있는가를 확인하기 위해 디스패춰를 부른다.

 6. 디스패춰를 통해 보다 우선순위가 높은 프로세스 2를 부른다.

 7. 프로세스2로 점프하여 먼저 처리한다.

안녕하세요? 허니입니다. 운영체제의 프로세스 생애주기(Process Life Cycle)에 대해 포스팅을 하려고 합니다. 프로세스 라이프사이클은 마치 한 사람의 삶의 모습과 닯아 있기 때문에 이해하기 쉬운 부분이 많습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 Process Life Cycle

Process Life Cycle

프로세스 라이프 사이클은 한 사람의 삶의 모습과 닮아있다고 말하고 싶다. 한 사람으로 태어나 성인으로 자라 한 사람으로서 자신의 몫을 다하고 어떠한 삶의 역경에 부딪혀 잠시 주저 앉기도 하고 또다시 자신의 몫을 찾아 역할을 다하다 결국에는 인생을 마감하는, 그런 인간의 모습 말이다. 프로세스 라이프 사이클을 고안해낸 사람 역시 어떤 한 인간이었기에 그 모습이 서로 닮아있을 수밖에 없을 것이다. 프로세스로 생성되어 자신의 역할을 할 때까지 기다림을 갖고 자신의 몫을 할 순간에는 그 역할에 충실하고 또한 어떤 문제의 부딪혔을 때 잠시 자신의 자리를 내어주기도 한다. 그리고 자신의 자리를 되찾아 하나의 프로세스로서의 역할을 다하고 마감되는 그 모습을 이해하는데 우리는 별다른 어려움이 없을 것이다.

프로세스 라이프 사이클은 다음과 같은 5단계로 나뉜다.

1. 생성 - 디스크에서 메모리로 프로그램이 올라가 실행준비를 하는 상태

2. 준비 - 순서에 맞춰 처리를 기다리는 상태

3. 수행 - 작업이 처리되고 있는 상태

4. sleep(=blocked)- 프로세스가 잠시 어떠한 조건에 의해 작업이 이뤄질 수 없는 상태로 그 조건이 해결되기를 기다리는 상태

5. 종료

이 과정에서 주의해야 할 점은 준비상태의 프로세스와 sleep 상태의 프로세스는 각각의 list를 작성해야 한다. 준비리스트에 있는 프로세스들은 각각 우선순위가 주어져 가장 높은 우선 순위의 프로세스의 차례로 CPU를 차지하게 된다. 그러나 sleep 리스트는 순위가 없다. 왜냐하면 대기상태에서 벗어나는 것은 정해진 순위에 의해서가 아니라 대기상태로 머물러야 했던 그 어떤 조건들이 해결되면 다시 실행 상태로 돌아갈 수 있기 때문이다.

그림 15 프로세스 라이프 사이클

a. 생성과정에서 준비상태로의 이동과정에서는 프로세스가 처리되기 위한 메모리와 필요한 주변장치들이 체크된다.

b. 준비상태에서 수행상태로의 이동과정에서는 미리 정해진 알고리즘(FCFS, SJN 등은 이후 프로세스 관리에서 배우게 된다.)에 따라 프로세스가 선택 처리된다.

c. 수행상태에서 다시 준비상태로 가는 때는 현재 처리되고 있는 프로세스의 타임 퀀텀이 다 되었을 경우이다.

d. 수행상태에서 sleep상태로의 이동은 입력/출력 요청에 의해 이뤄진다. 하나의 프로세스가 수행상태에서 입력/출력이 요청되면 그 작업이 마쳐질 때까지 그 프로세스는 sleep상태로 잠시 이동되고 커널의 스케줄링 알고리즘에 따라 적절한 순위의 프로세스가 수행 상태로 이동되는 것이다.

e. sleep상태에서 준비상태로의 이동은 입력/출력이 끝났다는 신호에 의해 이루어진다.

f. 수행상태에서 종료상태로의 이동은 작업이 성공적으로 완료되었거나 혹은 에러가 발생하여 작업이 미리 종료되는 경우이다.

요점정리

 Process Life Cycle

1. 생성 - 디스크에서 메모리로 프로그램을 올리고 실행 준비를 하는 상태

2. 준비 - 순서에 맞춰 처리를 기다리는 상태

3. 수행 - 작업이 처리되고 있는 상태

4. sleep(=blocked) - 프로세스가 잠시 어떠한 조건에 의해 작업이 이뤄질 수 없는 상태로 그 조건이 해결되기를 기다리는 상태

5. 종료

안녕하세요? 허니입니다. 운영체제를 공부하는데 기본적인 용어와 개념들을 알아야 합니다. 많은 분들이 기본 개념들을 모르기 때문에 운영체제가 많이 어렵다라고 말씀들 하시는 것 같습니다. 그렇게 때문에 오늘 기본적으로 알아야 할 운영체제 개념들에 대해서 포스팅 해 보겠습니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 OS를 전체적으로 이해하는 데 기본이 되는 몇 개의 개념들

OS를 전체적으로 이해하는 데 기본이 되는 몇 개의 개념들

 Kernel

커널은 컴퓨터 시스템의 전원을 처음 켰을 때 메모리로 올라와 시스템이 동작되는 동안 계속 머무르는 부분으로 OS에서 가장 기초적이고 핵심적인 기능을 담당한다. 커널을 통해 메모리, 파일, 주변장치 등과 같은 시스템을 구성하는 중요한 자원들을 관리할 뿐만 아니라 시간관리, 프로세스관리, CPU 스케줄링, 메모리관리, 입출력 제어 등과 같이 컴퓨터 운영에 필요한 핵심사항들을 처리한다. 우리는 서론에서 컴퓨터 시스템 구조를 공부해봤다. 하나의 프로그램을 실행시킬 때는 그림 9와 같은 컴퓨터 시스템 구조와는 또 다른 컴퓨터 시스템 내부구조를 그려낼 수 있다. 여기서 커널의 역할은 하드웨어에 두 사람 이상이 동일한 작업을 실행시켰을 때 중재자의 역할을 하고 또한 여러 사용자가 시스템을 동시에 사용할 때 각자가 독자적으로 작업할 수 있도록 영역을 확보해준다. 앞서 OS를 한 국가의 정부와 비교해 보았다. 그렇다면 커널은 정부의 대표인 공무원이라고 비교하면 적절할 듯 하다.

그림 9 커널 영역

그림에서 커널이 하드웨어를 둘러싸고 있는 것은 하드웨어를 제어하는 기능을 갖고 있기 때문이다.  또한 application과 커널 사이에 자리잡고 있는 Library는 사용자가 프로그램을 실행시킬 때 커널에게 응용프로그램을 이해시켜 프로그램이 수행될 수 있도록 기능하게 된다. 만약 Library가 존재하지 않는다면 프로그램마다 OS가 바뀌어야 한다. 다시 말해 하나의 프로그램에는 그 프로그램을 이해하도록 설계된 OS가 꼭 짝을 이뤄야 하는 것이다. 어떠한 시스템 내에서라도 Library를 동일하게 구성함으로 어떠한 OS 내에서도 응용프로그램은 동일한 기능을 수행할 수 있는 것이다.

 Interrupts

이 단어를 사전에서 찾아보면 가로막다. ‘중단하다’로 해석된다. 사무실에서 A 프로젝트 기획안을 작성하는 도중 전화가 걸려온다면 그는 분명 일을 잠깐 멈추고 전화를 받을 것이다. 전화용건을 해결하고 난 다음 다시 기획안 작성을 하게 될 것이다. 이렇듯 하나의 프로그램 수행 중 현재의 프로그램과 상관없는 사건이 발생한다면 어떨까? 이러한 사건이 생기면 인터럽트를 일단 걸어 수행중인 작업을 잠시 멈추고 새로 발생한 사건을 처리하게 된다.

인터럽트에는 하드웨어와, 소프트웨어 인터럽트가 있다. 우리가 앞으로 배우게 될 프로세스 수행의 결과로 발생하는 인터럽트는 소프트웨어 인터럽트이고 하드웨어 장치로부터 비동기적으로 발생하는 것은 하드웨어 인터럽트이다. 즉 프로세스 수행과 무관한 외부적 원인으로 인터럽트가 발생되는 것이 바로 하드웨어 인터럽트이다. 중요한 것은 인터럽트 서비스 루틴은 가능한 짧아야 한다는 것이다. 원래 수행 중이었던 작업을 두고 인터럽트 서비스를 길게 처리할 수는 없을 것이다. 제2, 제3의 인터럽트가 발생했을 경우 그것 역시 제 시간에 수행돼야 하기 때문이고 인터럽트 발생이전 수행 중이었던 프로그램 역시 계속 수행해야 하기 때문이다. 이러한 인터럽트를 해석하고 서비스 루틴을 수행하는 역할을 하는 것을 인터럽트 핸들러(interrupt handler) 라고 한다.

그림 10 인터럽트

그렇다면 어떤 경우에 인터럽트를 사용될까? 대표적인 예는 키보드의 경우를 생각해 볼 수 있다. 만일 인터럽트를 사용하지 않는다면, CPU는 아주 빈번히 키보드의 입력을 매번 확인을 해야 할 것이다. CPU가 키보드 입력을 확인하는 주기는 아주 짧은 반면에 사람이 키보드를 두드리는 속도는 매우 느리다면, CPU는 키보드의 입력이 없음에도 불구하고 확인을 할 것이다. 하지만 입력이 없을 때의 확인은 아주 불필요한 것이고 이러한 작업은 CPU의 입장에서는 귀중한 CPU 수행시간을 낭비하는 것이다. 이러한 점을 착안해서 인터럽트 방식이 고안된 것이다. 키보드는 사용자가 키보드에 입력을 하면 키보드는 이러한 사실을 CPU에게 알리고 CPU는 어떠한 키가 눌러졌는지를 감지하게 된다. 즉, 키보드의 입력이 없는 동안에 CPU는 많은 일을 할 수 있을 것이다.

 Trap

트랩은 간단하게 말해 커널 안으로 들어가 커널 서비스를 제공받기 위한 하나의 절차이다. 예를 들어 컴퓨터 시스템 사용자가 작업도중 시간을 알고 싶다는 요청을 하면 트랩을 통해 커널 안으로 요청이 들어가고 커널은 트랩을 통해 들어온 요청이 실행 가능한 것인지를 판단해 서비스를 제공하게 되는 것이다. 바로 사용자와 커널간에 의사소통을 해주는 아주 유용한 통역자인 셈이다. 트랩은 커널과 Library의 경계선상에서 기능을 수행하게 된다.

 System call

System call을 간략하게 정의하자면 커널에게 작업을 의뢰하는 것이다. 트랩에서 언급했듯 작업도중 시간을 알고 싶다는 사용자의 요청 하나가 바로 하나의 system call인 것이다. 한글프로그램상에서 저장된 파일을 불러오는 것, 새로운 문서를 작성해 파일명을 지정해 저장하는 것, 디렉터리상에서 파일이름을 삭제하는 것 바로 이러한 작업 모두가 System call을 통해 수행되는 것이다. 프로그램 수행 중에 System call을 호출하면 트랩은 OS에게 System call을 전달한다. 그리고 나면 커널은 System call이 어떤 처리를 원하는 것인가를 확인하고 그에 해당하는 서비스를 처리한다. System call을 커널, 트랩과 연관 지어 설명하자면, 우리가 동사무소에 어떤 업무 처리를 위해 찾아갔을 때 (주민등록 떼기, 전입, 전출 신고, 출생신고 등) 그 하나하나의 업무들은 바로 system call과 동등한 의미가 되는 것이다. 그리고 우리는 그 처리를 담당자에게 요구하기 위해 해당용지에 기재 사항들을 적게 되는데 이러한 과정은 트랩이 담당하는 것이고 담당공무원이 업무를 처리해 주는 것 그것은 바로 커널의 역할인 것이다.

그림 11 System Call

 DMA(direct memory access)

프로그램 처리 중 입력/출력 처리속도가 느린 것을 염두에 두고 고안해낸 방법이다. 바로 입력/출력이 동작할 때 CPU와는 관계없이 직접 DMA 컨트롤러가 메모리에 접근해 입력/출력을 처리하는 것이다. DMA로 인해 입력/출력 처리 중에도 CPU는 쉼 없이 다른 처리를 할 수 있는 것이다. DMA 처리과정을 살펴보면 먼저 CPU는 DMA컨트롤러에서 입력/출력 내용들을 카피할 것을 명령한다. DMA 처리과정에서 CPU의 역할은 이 한가지로 막을 내린다. DMA 컨트롤러는 메모리에 접근해 입력/출력 내용을 카피하게 되고 그 내용은 디스크에 저장되게 되는 것이다. 바로 입력/출력 시간 동안 CPU의 낭비를 막기 위해 프로그램 처리를 분업화해 CPU는 자신의 영역 업무 만에 매달릴 수 있게 한 것이 바로 DMA이다. 결국 DMA를 사용함으로써, CPU의 사용률을 올릴 수 있게 된다.

그림 12 DMA

 문맥전환(Context Switching)

문맥전환이란 CPU의 수행 내용이 어떠한 조건에 의해 바뀌는 것을 의미한다. 쉽게 표현한다면 옷을 갈아입는다고 말할 수 있을 것이다. 옷을 갈아입는 사람은 CPU가 되고 옷은 수행되는 내용을 뜻한다. 현재 수행 중이었던 프로세스가 어떠한 조건에 의해 잠시 수행이 멈춰지고 그 다음 프로세스가 수행됨을 말한다. 예를 들어 타임쉐어링처럼 하나의 프로그램이 CPU를 사용할 수 있는 시간을 고정시켜 제한된 시간을 하나의 작업이 다 쓰고 나면 다음작업을 수행하게 될 때 문맥전환이 일어나게 되는 것이다.

문맥교환이 일어나게 되는 조건들은 다음과 같다.

1. 타임 퀀텀이 다 된 경우, 하나의 CPU로 여러 작업들을 처리하게 되면 작업을 보다 빠르게 수행하기 위해 일정시간을 정해 놓고 그 시간 동안 작업이 완료되지 않았을 경우 다음 작업을 수행하게 된다. 바로 CPU의 수행작업이 바뀌게 되는 것이다.

2. 입력/출력이 발생되어 그 유휴 시간 동안 CPU가 다른 작업을 수행할 경우, 입력/출력은 CPU를 통해 이뤄지는 작업이 아니므로 CPU는 여유 시간 동안 다른 작업을 수행할 수 있는 것이다.

그림 13 문맥 전환 (Context Switching)

 PCB (Process Control Block)

프로세스가 수행되기 위해서는 프로세스만이 필요할까? 여러 프로세스들이 하나의 시스템 내에서 처리되기 위해선 그 프로세스의 정보가 유지되어야 한다. PCB에는 프로세스에 어떤 자원이 할당되어 있고 또 프로세스가 어떠한 상태에서 수행 중인가를 나타내는 일체의 관련정보가 수록되어 있다. 사람이란 존재 역시 그 실체만으로 자신을 표현할 수는 없는 것이다. 이름이 무엇인지, 나이가 얼마고 하는 일은 무엇인지 등과 같은, 그 사람을 표현해줄 수 있는 모든 정보가 따라다니기 마련이다. 다시 말해 문맥교환에 필요한 모든 정보가 PCB에 수록되어 있는 것이다. 커널은 각각의 프로세스에 대한 PCB를 갖고 있다. 그렇다면 PCB에는 어떤 정보들이 수록되어 있는가?

- 프로세스가 준비, 실행, 대기 등 현재 어떤 상태인가.

- 프로세스가 다음 어떤 명령을 처리하나.

- 프로세스가 CPU를 얼마나 사용했나.

- 먼저 처리되어야 할 프로세스는 어떤 것인가.

등 모든 정보가 꼼꼼히 PCB에 저장되어 있다. OS가 CPU를 다른 프로세스의 작업을 처리하고 이전 프로세스에게 돌아왔을 때 이러한 정보가 남아있지 않다면 CPU는 분명 당황해 할 것이다.

그림 14 PCB

요점정리

 OS를 이해하기 위한 기본개념

- Kernel

커널은 컴퓨터 시스템의 전원을 처음 켰을 때 메모리로 올라와 그 이후 항상 주기억장치에 머무르는 부분이다. OS와 상등한 개념을 가지고 있다.

- Interrupts

하나의 프로그램 수행 중 현재의 프로그램과 상관없는 사건이 발생한다면 어떨까......

이러한 사건이 생기면 인터럽트를 걸어 수행중인 작업을 잠시 멈추고

새로 발생한 사건을 처리하게 된다.

- Trap

트랩은 간단하게 말해 커널모드 안으로 들어가 커널 서비스를 제공받기 위한 하나의 절차이다.

- System call

System call을 간략하게 정의하자면 커널에게 작업을 의뢰하는 것이다.

- DMA (direct memory access)

바로 입력/출력이 동작할 때 CPU와는 관계없이 직접 DMA 컨트롤러가 메모리에 접근해 입력/출력을 처리하는 방법으로 입력/출력 처리 중에도 CPU는 쉼 없이 다른 처리를 할 수 있다.

- Context Switching

Context Switching이란 CPU의 수행 내용이 어떠한 조건에 의해 바뀌는 것을 의미한다.

- PCB (Process Control Block)

PCB에는 프로세스에 어떤 자원이 할당되어 있고 또 프로세스가 어떠한 상태에서 수행 중인가를 나타내는 일체의 프로세스 관련정보가 수록되어 있다.

안녕하세요? 허니데이즈입니다. 오늘은 지르콘 시스템콜이 뭐가 있는지 포스팅 하겠습니다.

지르콘 커널에서 사용되는 시스템콜은 현재까지 20여가지 기능을 하기 위한 세트로 정의되고 있으며 다음과 같다.

 Handles

handle_close - close a handle

handle_close_many - close several handles

handle_duplicate - create a duplicate handle (optionally with reduced rights)

handle_replace - create a new handle (optionally with reduced rights) and destroy the old one

Objects

object_get_child - find the child of an object by its koid

object_get_cookie - read an object cookie

object_get_info - obtain information about an object

object_get_property - read an object property

object_set_cookie - write an object cookie

object_set_property - modify an object property

object_signal - set or clear the user signals on an object

object_signal_peer - set or clear the user signals in the opposite end

object_wait_many - wait for signals on multiple objects

object_wait_one - wait for signals on one object

object_wait_async - asynchronous notifications on signal change

Threads

thread_create - create a new thread within a process

thread_exit - exit the current thread

thread_read_state - read register state from a thread

thread_start - cause a new thread to start executing

thread_write_state - modify register state of a thread

Processes

process_create - create a new process within a job

process_read_memory - read from a process's address space

process_start - cause a new process to start executing

process_write_memory - write to a process's address space

process_exit - exit the current process

Jobs

job_create - create a new job within a job

job_set_policy - modify policies for a job and its descendants

Tasks (Thread, Process, or Job)

task_bind_exception_port - attach an exception port to a task

task_kill - cause a task to stop running

task_resume - cause a suspended task to continue running

task_resume_from_exception - resume a task from a previously caught exception

task_suspend - cause a task to be suspended

Channels

channel_call - synchronously send a message and receive a reply

channel_create - create a new channel

channel_read - receive a message from a channel

channel_read_etc - receive a message from a channel with handle information

channel_write - write a message to a channel

Sockets

socket_create - create a new socket

socket_read - read data from a socket

socket_write - write data to a socket

Fifos

fifo_create - create a new fifo

fifo_read - read data from a fifo

fifo_write - write data to a fifo

Events and Event Pairs

event_create - create an event

eventpair_create - create a connected pair of events

Ports

port_create - create a port

port_queue - send a packet to a port

port_wait - wait for packets to arrive on a port

port_cancel - cancel notifications from async_wait

Futexes

futex_wait - wait on a futex

futex_wake - wake waiters on a futex

futex_requeue - wake some waiters and requeue other waiters

Virtual Memory Objects (VMOs)

vmo_create - create a new vmo

vmo_read - read from a vmo

vmo_write - write to a vmo

vmo_clone - clone a vmo

vmo_get_size - obtain the size of a vmo

vmo_set_size - adjust the size of a vmo

vmo_op_range - perform an operation on a range of a vmo

vmo_replace_as_executable - add execute rights to a vmo

Virtual Memory Address Regions (VMARs)

vmar_allocate - create a new child VMAR

vmar_map - map a VMO into a process

vmar_unmap - unmap a memory region from a process

vmar_protect - adjust memory access permissions

vmar_destroy - destroy a VMAR and all of its children

Cryptographically Secure RNG

cprng_draw

cprng_add_entropy

Time

nanosleep - sleep for some number of nanoseconds

clock_get - read a system clock

clock_get_monotonic - read the monotonic system clock

ticks_get - read high-precision timer ticks

ticks_per_second - read the number of high-precision timer ticks in a second

Timers

timer_create - create a timer object

timer_set - start a timer

timer_cancel - cancel a timer

Hypervisor guests

guest_create - create a hypervisor guest

guest_set_trap - set a trap in a hypervisor guest

Virtual CPUs

vcpu_create - create a virtual cpu

vcpu_resume - resume execution of a virtual cpu

vcpu_interrupt - raise an interrupt on a virtual cpu

vcpu_read_state - read state from a virtual cpu

vcpu_write_state - write state to a virtual cpu

Global system information

system_get_features - get hardware-specific features

system_get_num_cpus - get number of CPUs

system_get_physmem - get physical memory size

system_get_version - get version string

Logging

log_create - create a kernel managed log reader or writer

log_write - write log entry to log

log_read - read log entries from log

Multi-function

vmar_unmap_handle_close_thread_exit - three-in-one

futex_wake_handle_close_thread_exit - three-in-one

DDK

cache_flush - Flush CPU data and/or instruction caches

interrupt_ack - Acknowledge an interrupt object

interrupt_bind - Bind an interrupt object to a port

interrupt_create - Create a physical or virtual interrupt object

interrupt_destroy - Destroy an interrupt object

interrupt_trigger - Trigger a virtual interrupt object

interrupt_wait - Wait on an interrupt object

smc_call - Make an SMC call from user space

acpi_uefi_rsdp

ioports_request

framebuffer_set_range

vmo_create_contiguous

vmo_create_physical

출처: https://fuchsia.googlesource.com/zircon/+/master/docs/syscalls.md

지르콘 커널에 대해 더 알고 싶으시다면 아래 목차에서 클릭!