데이즈

안녕하세요? 허니입니다. 운영체제에서 많이 쓰이는 동기화 기법으로 세마포어를 많이 씁니다. 세마포어는 프로세스의 순차적인 처리를 위해 만든 기법으로 프로세스들끼리 경쟁을 막아 원할한 자원 공유를 가능하게 합니다. 운영체제에서는 매우 중요하기 때문에 세마포어에 대해 자세하게 포스팅 하려고 합니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 SEMAPHORE

 Monitor

세마포어(SEMAPHORE)

프로세스의 순차적인 처리로 데이터의 값을 보장하는 방법에 대해 자세히 모르신다면 제 블러그에서 프로세스 동기화를 주제로 한 포스트를 읽어보시고 세마포어에 대해 읽어보는 것이 좋다. 프로세스를 단순히 2개라고 가정한 채 critical section을 한 프로세스만을 접근시켜보았는데 프로세스가 10개, 20개, 30개라고 가정한다면 대단히 복잡한 문제로 발전할 수밖에 없다.  그렇기에 시스템 설계자들은 발상의 전환을 하기 시작했다. 바로 신호체계를 만든 것이다. 하나의 프로세스가 critical section내에서 수행되고 sleeping하는 것을 신호에 따라 조절될 수 있도록 말이다. 그러한 발상에서 semaphore가 고안되었다. 바로 wait(약어P)와 signal(약어V)의 함수를 적절히 호출함으로 여러 프로세스를 수행하게 되는 것이다.

Semaphore의 동작을 간단히 살펴보면, S라는 변수를 두고 critical section내에 들어가기 전에 wait(S)함수를 수행하여 critical section 내에 다른 프로세스가 없는 상태를 기다린다. 이는 (S > 0)의 조건을 기다리는 것인데, 이 조건은 다른 프로세스가 signal(S)을 호출하거나 초기 상태에만 가능하다. 즉, 프로세스가 critical section에서 나올 때 signal(S)를 호출함으로써 (S > 0)의 조건이 만족되고, wait(S) 함수로 기다리던 프로세스들이 그것을 감지하여 critical section으로 진입하게 되는 것이다. 단 여기서 하나의 프로세스만이 critical section으로 진입하여야 하므로 while 구문을 가장 먼저 통과한 프로세스가 S를 다시 감소시켜 (S > 0)의 조건을 파괴하는 것이다. 그렇다면 critical section이 5개일 경우 1개의 semaphore를 구성하는 것이 효과적일까. 아니면 5개의 semaphore를 구성하는 것이 효과적일까. 각각의 critical section마다 semaphore를 둘 경우 동시수행이 가능해지기 때문에 처리능력이 향상된다. 그러나 교착상태(deadlock)의 위험이 도사리고 있는 것이 문제점으로 지적될 수 있다. 다음과 같은 경우를 한번 생각해 보자. 철학자 5명이 국수를 먹는다. 그러나 얄궂게도 젓가락이 5쌍이 아닌 5개밖에 없다. 여기에서 젓가락이 바로 critical section이 되는 것이다.

그림 22 Dining Philosophers

철학자들이 국수를 먹기 위해선 자신의 좌측 우측에 있는 젓가락을 잡아야 하는데, 이럴 경우 발생할 경우란 2사람의 철학자가 먹을 수 있는 경우와 아무도 먹을 수 없는 경우가 될 것이다. 다섯 명의 철학자가 젓가락을 하나씩 쥐고 계속 기다린다면 어떨까. 시간이 흘러도 그 상황은 계속 유지되어 철학자들은 계속 굶고 있을 수밖에 없는 것이다. 바로 교착상태(deadlock)이 발생하는 것이다. 바로 P와 V를 어떻게 사용해야 철학자들이 굶지 않을까 하는 것이 semaphore의 최대 관심거리인 것이다. 이러한 교착상태(deadlock)가 발생한 경우는 얼마간의 시간이 지나면 하나의 젓가락을 포기한 채 Synchronization을 다시 시도해야 한다. 교착상태(deadlock)가 발생하지 않기 위해서는 순서를 정해 양쪽 젓가락을 잡을 수 있도록 설계되어야 한다. 젓가락을 쓰는데 순서를 정해주면 2명씩의 철학자가 돌아가면서 국수를 먹을 수 있도록 말이다. 모자라는 자원의 최대 활용이라고나 할까....

잠깐, 상식! 교착상태(deadlock)란? 프로세스들이 서로 작업을 진행하지 못하고 영원히 대기 상태로 빠지는 현상을 교착상태라고 한다. 이러한 교착상태가 발생하는 원인은 프로세스 사이에 할당된 자원의 충돌로 인하여 발생하게 된다. 예를 들어 A와 B라는 2개의 프로세스가 동작을 한다고 하자. 그리고 이들은 각각 a와 b라는 자원을 할당 받아 사용하고 있다고 가정하자. 이때 프로세스 A 에서는 작업을 계속 진행하기 위해서 b라는 자원을 요청하고 프로세스B에서는 a라는 자원을 요청하게 되면 각각의 프로세스가 요청한 자원이 이미 다른 프로세스에 할당되어 있기 때문에 할당이 풀릴 때까지 대기 상태에 들어가게 된다. 그런데 A와 B 프로세스 모두 상대방이 자원을 내놓기를 기다리면서 대기 상태로 들어가기 때문에 이들은 영원히 대기 상태에 머무는 교착상태에 빠지게 되는 것이다.

또 다른 semaphore의 쓰임새를 살펴보자. 앞서 예로 들었던 은행 잔고가 잘못 기록되는 문제점에 대한 해결 열쇠 또한 semaphore가 쥐고 있는 것이다. 은행 잔고를 처리하는 부분을 semaphore로 관리하면 되는 것이다. 지금까지 살펴보았듯 semaphore를 사용하게 되면 Synchronization을 보다 효율적으로 구현할 수 있다. 그러나 앞에서도 잠깐 언급했듯이 Synchronization을 구현하는 것은 사용자의 필요성에 의해 각자에게 맡겨진 것이다. 어떠한 1명이 고의적으로 또한 P와 V의 구조를 잘못 이해해서 실수를 범하게 된다면 그 결과는 아무도 예측하지 못하게 된다. 바로 미꾸라지 하나가 Synchronization를 엉망으로 만들 수 있는 것이다. 그렇기에 이러한 문제점의 해결방안으로 Monitor가 구성되었다. Monitor는 P, V와 같은 함수의 정의가 언어로 표현되어 사용자들이 보다 쉽게 Synchronization을 구현 할 수 있도록 한 것이다.

요점정리

 세마포어(Semaphore)란?

wait(약어P)와 signal(약어V)의 함수를 적절히 호출함으로 여러 프로세스를 수행하는 방법이다.

안녕하세요? 허니입니다. 운영체제에서 프로세스끼리 자원경쟁을 한다거나 서로 자원을 쓰지 못하는 기아현상을 해결하기 위해 동기화 기법을 활용합니다. 즉, 자원을 효과적으로 활용하기 위한 정책으로 프로세스 동기화에 자세히 포스팅 하려고 합니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 프로세스 동기화(Process Synchronization)

Process Synchronization

 동기화(Synchronization)

여러 프로세스의 접근이 가능한「공유된 데이터」에 여러 프로세스들이 동시에 접근했을 경우 과연 어떠한 문제가 발생하게 될까. 체계적인 접근방법을 만들어 놓지 않는다면 예측하지 못했던 결과가 나올 가능성이 있다. 이러한 가능성을 배제하기 위해 Synchronization의 개념이 도입되었다. 예를 들어 은행에 1000원의 잔고가 남아 있다고 하자. 통장의 주인이 500원을 찾는 순간 동시에 고향 어머니께서 500원을 송금해 오셨다면 어떤 결과가 발생할까. 우리가 바라는 결과값은 두말할 나위 없이 바로 1000원인데 말이다. 그러나 그 결과값이 500원이 나왔다면 또는 1500원이 나왔다면 이것은 엄청난 문제가 아닐 수 없다. 어떻게 이런 결과값이 나올 수 있었을까. 바로 공유 데이터, 은행 잔고 1000원에 A프로세스(500원 인출)와, B프로세스(500원 송금이 동시에 접근해 각각의 프로세스가 서로 다른 결과를 갖고 있기 때문이다.

그림 18 Synchronization의 필요성

위의 그림과 같이 A프로세스는 500원의 결과를 B프로세스는 1500원의 결과를 갖고 있을 경우 마감 처리되는 프로세스의 결과가 최종 은행잔고로 남게 되는 것이다. 어떠한 데이터에 대해 동시 작업이 일어났을 경우 처리순서에 상관없이 원하는 결과값을 얻기 위해 바로 Synchronization이 필요한 것이다. 즉, Synchronization의 목적은 data consistency을 보장해 주는 것이다. 하나의 작업을 처리하는데 100개의 시그널이 동시에 날아와 제 각각의 처리를 마쳐도 데이터는 항상 시종일관 자신이 갖고 있어야 할 결과값을 담고 있어야 하는 것이다. data consistency을 보장해 주기 위한 방법은 다음과 같다.

 상호배제(Mutual exclusion)

공유 데이터에 동시에 여러 개의 프로세스가 임의로 접근하게 되면 앞서 살펴본 예와 같이 데이터의 상태가 부정확하게 되는 문제가 발생된다. 그렇기에 공유데이터가 하나의 프로세스에 의해 독점적으로 사용되는 원칙을 상호배제라 한다. 여기서 잠깐 critical section이라는 코딩 용어를 알아두자. 바로 상호배제의 원리가 지켜져야 하는 영역이 critical section인 것이다. 자칫 잘못하면 위험한 결과가 초래될지도 모르기에 위험한 세션이라 이름을 붙인 것일까....

예를 들어 프로그래머가 다음과 같이 코딩을 하였다.

프로세스는 critical section안으로 들어가기 이전 entry section 단계에서 출입을 허가 받아야 한다. 이러한 허가절차를 받는 이유는 critical section안에 오직 하나의 프로세스만이 존재하도록 하기 위해서다. 프로세스를 이렇게 순차적으로 접근시킨다면 동시에 2개 이상의 프로세스가 접근해 서로 다른 결과치를 갖게 되는 문제가 해결되는 것이다. 다시 말해 A프로세스가 최종결과로 시스템 내부에서 처리되면 통장에는 500원의 잔고가 남을 것이고 B프로세스가 최종결과로 시스템 내부에서 처리되면 통장에는 1500원의 잔고가 남을 것이다. 이러한 문제의 발생을 막기 위해 A프로세스가 -500을 수행하는 동안 +500을 수행하는 B프로세스의 접근을 차단시키는 것이다. 그 역할을 바로 entry section이 맡고 있는 것이다. 이러한 상호배제(Mutual exclusion)는 DB의 프로그램에서는 자동적인 부가기능으로 지원되지만 OS의 경우는 사용자의 요구에 따라 지원된다. DB프로그램은 공유된 데이터의 보장이 프로그램의 가장 중요한 요소이다. 모든 프로그램이 수행될 때 공유된 데이터를 바탕으로 사용되기 때문이다. 그러나 OS는 사용자의 요구에 따라 상호배제(Mutual exclusion)가 지원된다. 바로 그 필요성이 DB만큼 막대하지 않기에 사용자의 필요성에 맡기는 것이다. 은행을 운영하는데 있어 CCTV등의 보안장치는 필수불가결하기 때문에 전국 어느 은행이나 설치를 했겠지만 보통의 가정집은 집주인이 필요하다고 판단되면 설치되는 것처럼 말이다.

상호배제(Mutual exclusion)의 장점은 무엇보다도 혼란이 없고 간단하다는 점이다. 그러나 매우 커다란 문제점이 내재되어 있었다. 바로 read와 write의 처리에 관한 문제였다. 「공유 데이터」에 read라는 명령어를 수행하기 위해 접근하는 프로세스는 100개나 1000개가 동시에 critical section안으로 들어와도 아무런 문제가 없다. 그 프로세스들을 공유된 데이터를 다만 참조할 뿐 더 이상의 어떤 변화도 가져오지 않기 때문이다. 그러나 write라는 명령어를 수행하기 위해 접근하는 프로세스의 경우는 1개만이 critical section 안에서 처리되어야 한다. write는 공유 데이터를 변화시키기 때문이다.

그러나 상호배제(Mutual exclusion)의 방법에서는 바로 이러한 read와 write의 처리를 구분 짓지 않는다. 무조건 「공유 데이터」에 접근하기 위해선 1000개가 동시 처리되어도 좋을 read마저도 오랜 기다림을 가져야 했다. 그렇기에 시스템 설계자는 새로운 무엇을 찾아내려 했다. 그 방법은 바로 kernel 자체가 하나의 커다란 critical section의 역할을 하는 것이다.

그림 19 kernel 자체의 critical section

여기서 가장 핵심이 되는 것은 lock이란 개념이다. 우리말로 표현한다면 잠금장치, 즉 자물쇠인 것이다. 바로 lock이라는 용어는 남이 접근하지 못하도록 잠궈 놓는다는 의미를 갖고 있는데 하나의 프로세스가 공유데이터에 접근하는 동안 다른 프로세스가 공유데이터에 접근하지 못하도록 입구를 잠궈 두는 것이다. lock에는 spin lock과 sleep lock이 있는데 spin lock이 0일 때는 critical section에 프로세스가 들어와도 된다는 것을 의미하고 spin lock이 1일 때는 critical section안에 다른 프로세스가 들어와 있다는 것을 의미한다. spin lock이 1일 경우 다음 수행을 기다리는 프로세스는 1이 언제 0이 될까를 관찰하며 Lock을 계속 돌게 된다. 바로 exit section에 의해 critical section내에서 프로세스가 처리되었다는 것이 인식되어 spin lock을 0으로 만드는 것이다.

그림 20 spin lock

sleep lock은 lock이 1일 경우 기다리던 프로세스는 sleep을 하게 되는 것이다. critical section내에 프로세스가 언제 처리가 끝날지 모르기 때문이다. critical section내에 프로세스의 작업이 끝나게 되면 sleep중인 프로세스를 깨워 처리하게 된다.

그림 21 Sleep Lock

그러나 이러한 방법 또한 완벽한 것은 아니었다. 또 다시 발생한 문제점은 동시에 2개 이상의 프로세스가 접근해 0을 1로 바꿀 가능성이 있다는 것이었다. 이러한 상황은 하나 이상의 프로세스가 동시에 lock=1에서 lock=0으로 바뀐 변수를 확인한 경우 발생하게 된다. 바로 프로세스가 처리될 때 0을 read해 1로 write하는 작업이 따로 수행되기 때문이다. 예를 들어 프로세스A와 프로세스B가 동시에 lock=0인 것을 read했다. 그러나 프로세스B가 먼저 lock=1을 write하고 프로세스B는 read만을 한 채 더 이상 작업이 진행되지 않았다. 이럴 경우 프로세스B는 context switching이 일어나게 되고 그 다음 작업이 수행될 때는 read작업을 다시 하지 않는다. 그렇기에 context switching이 발생하기 이전 lock=0이었던 것만을 기억한 채 작업을 수행하기 때문에 현재 lock=1이 라도 프로세스는 데이터에 접근하게 되는 것이다. 바로 또다시 동시에 2개 이상의 프로세스가 접근해 서로 다른 결과값을 갖게 되는 근본적인 문제가 다시 발생되는 것이다. 이러한 문제의 가장 간단한 해결책은 read/write를 하나의 명령어로 만들어 놓는 것이다. 이렇게 되면 동시에 2개의 프로세스가 lock을 0으로 볼 리는 없는 것이다.

요점정리

 Synchronization은 왜 필요한가

여러 프로세스의 접근이 가능한「공유된 데이터」에 동시에 여러 프로세스들이 접근했을 경우 어떠한 접근체계를 만들어놓지 않는다면 예측하지 못했던 결과가 나올 가능성이 있다. 이러한 가능성을 배제하기 위해 Synchronization의 개념이 도입되었다.

 바로 Synchronization의 목적은 data consistency을 보장해 주는 것이다.

하나의 작업을 처리하는데 100개의 시그널이 동시에 날아와 제 각각의 처리를 마쳐도 데이터는 항상 시종일관 자신이 갖고 있어야할 결과값을 담고 있어야 하는 것이다. 

 data consistency을 보장해 주기 위한 방법

1)상호배제(Mutual exclusion) - 공유데이터가 하나의 프로세스에 의해 독점적으로 사용되는 원칙을 상호배제라 한다.

2)kernel을 이용 - spin lock과 sleep lock을 이용하여 kernel 자체가 critical section 역할을 하게 된다.

안녕하세요? 허니입니다. 많은 스케줄링 알고리즘이 존재하기 때문에 어떤 스케줄링 기법을 활용하냐에 따라 성능차이가 많이 납니다. 때문에 비교 기준이 필요합니다. 때문에 저는 스케줄링 알고리즘을 어떻게 비교할 수 있을까에 대해 포스팅을 하려고 합니다. 학생이나 연구원분들에게 많은 도움이 될 것이라고 생각하며 언제든지 질문은 환영입니다.

오늘의 주제

 스케줄링 알고리즘의 비교기준

스케줄링 알고리즘의 비교기준

무엇인가를 평가하는 것은 분명 나름대로의 기준이 있기 마련이다. 무조건 공부 잘하는 학생을 최고의 학생으로 평가하는 선생님도 있을 것이고 공부보다는 친구들과의 관계, 여러 활동 상황 등의 사회성을 보다 높게 평가하는 선생님도 있기 마련이다. 가치있는 삶을 돈이란 기준으로 평가하는 이들도 있고 인간관계라고 평가하는 이들도 권력이라고 평가하는 이들도 있다. 그 어느 것이 보다 좋다는 것을 말하려는 것이 아니다. 바로 각자가 가진 평가기준에 따라 최고라는 기준은 달라지게 마련이다. 그렇기에 보다 다양한 사람들이 모인 사회가 되는 것일 테지만 말이다. 이와 같이 시스템 설계자 또한 스스로가 선택한 한가지의 기준에 따라 최적의 스케줄링 알고리즘을 설계하는 것이다. 여기서 말하는 기준이란 바로 다음과 같다..

 CPU utilization

이 경우의 기준은 사용자가 컴퓨터를 이용한 전체시간 중에 작업처리를 위해 실제 CPU가 이용된 시간의 비율을 말한다. 바로 CPU의 낭비가 가장 적은 것에 초점을 두고 스케줄링하는 것이다. 다시 말해 CPU utilization는 ‘몇%의 일이 처리되었나’가 관심사이다.  예를 들어 은행에 A직원은 3명의 손님을 처리하였고 B직원은 30명의 손님을 처리했다면 어느 직원이 열심히 일한 것일까. 별다른 고려없이 표면적인 수치로만 이해한다면 분명 B직원이 열심히 작업을 수행했다고 생각할 수 있다. 그러나 만일 A직원이 처리한 3명 손님의 작업은 시간이 오래 소요돼 잠시도 쉴 틈이 없었고 B직원이 처리한 30명의 작업은 1분씩의 시간이 소요돼 30분만에 마치고 나머지 시간은 사적인 일을 처리했다면 어떨까. 그렇다면 단순히 처리된 손님수로만 직원의 성실도를 체크할 수는 없는 것이다. 이와 같이 은행직원이(CPU) 얼마나 쉼 없이 일을 처리했느냐는 것이 바로 CPU utilization의 관점인 것이다. CPU utilization의 관점에서 가장 효율적인 스케줄링은 FCFS(First Come First Served) 이다. FCFS의 경우는 프로세스에 대한 별도의 처리없이 (예를 들어 타임퀀텀이 다 되어 수행하던 프로세스를 저장하고 다음 프로세스를 처리) 계속해서 작업이 수행됨으로 overhead가 적어진다. 따라서 CPU의 낭비가 가장 적은 스케줄링인 것이다. Priority의 경우에는 하나의 프로세스를 처리하던 중 우선순위가 높은 프로세스가 처리되어야 할 경우 앞서 수행되던 프로세스를 저장하고 이후 제자리를 찾아주는 등의 작업에 overhead가 소요되는 것이다. 또한 Round Robin의 경우 타임퀀텀 내에 완료되지 않은 프로세스들을 관리하는 작업에 overhead가 소요되는 것이다 

Response time

이 경우의 기준은 하나의 프로세스가 일을 시작해서 끝날 때까지 걸리는 시간에 초점을 맞춘 것으로 작업처리 평균시간이 가장 적게 걸리도록 스케줄링하는 것이다. 은행에 한손님이 들어서 은행을 나설 때까지 걸리는 시간을 최대한 줄이는 것이 바로 Response time을 기준으로 설계된 것이다. 여러 방법 중 Round Robin으로 설계했을 때 Response time이 가장 적게 걸린다. 스케줄링 알고리즘에서도 언급했듯이 FCFS의 경우 긴 시간을 필요로 하는 작업이 앞에 놓였을 때 작업처리평균시간은 길어지게 마련이다. 바로 짧은 타임퀀텀을 갖고 있는 Round Robin이 Response time을 가장 적게 해주는 설계방법인 것이다.

 Throughput

처리량을 기준으로 할 경우 기준시간당 얼마나 많이 일을 처리했느냐 하는 것이 관건이다. 바로 한 명의 은행직원이 몇 명의 손님을 처리 했는냐 하는 것인데 빨리 빨리라는 개념이 최상의 서비스란 생각을 갖고 있는 은행장이라면 처리량을 기준으로 은행시스템을 설계할 것이다. 은행직원의 관심은 오직 ‘한 시간 동안-기준시간을 한 시간이라 한다면-몇 명의 일을 처리 했나’일 것이다. 은행은 1시간당 100명의 손님이 오는데 직원 1명은 1시간당 평균 25명을 처리하니까 창구직원을 4명을 두어야겠다 라는 생각을 분명 갖고 있을 것이다.

 Waiting time

프로세스가 준비상태의 큐로부터 얼마나 빨리 나오게 할 수 있느냐에 초점을 맞춘 것이 Waiting time이다. 은행에 들어서 번호표를 빼어 든 다음 자신의 번호가 표시되어 처리가 시작될 때까지 기다리는 시간을 최소로 하는 것이 바로 Waiting time의 관점에서의 설계기준인 것이다. 최근 어느 은행에서는 손님이 10분 이상 Waiting time을 가졌을 경우 1000원을 보상해주는 제도가 도입되었었다. 바로 그 은행은 최고의 서비스란 손님들의 Waiting time을 최소화하는 것이란 생각이 분명 내재되어 있었을 것이다.

질문) throughput의 관점이 결국 CPU utilization의 관점과 유사한 개념이 아닐까요?

답) throughput의 관점에서는 CPU, memory, I/O를 다 보는 것이다. throughput는 보다 넓게 시스템의 균형을 중심으로 보는 것이다.              

질문) CPU 스케줄링이 시스템의 균형과 무슨 관계가 있는 것입니까. (앞서 우리는 CPU가 프로세스의 처리속도와는 별다른 관계가 없다고 하었다)

답) CPU 스케줄링을 잘하면 시스템이 효율적이게 된다. 결국 CPU 스케줄링이 시스템 전체에 어떤 영향을 미치는 것인가를 주목하는 것이다.

요점정리

 Scheduling의 비교기준

1. CPU utilization

이 경우의 기준은 바로 CPU의 낭비가 가장 적은 것에 초점을 두고 스케줄링하는 것이다. 다시 말해 ‘몇%의 일이 처리되었나’가 관심사이다.

2. Response time

이 경우의 기준은 하나의 프로세스가 일을 시작해서 끝날 때까지 걸리는 시간에 초점을 맞춘 것으로 작업처리평균시간이 가장 적게 걸리도록 스케줄링하는 것이다.

3. Throughput

처리량을 기준으로 할 경우 기준시간당 얼마나 많은 일을 처리했느냐 하는 것이 관건이다.

4. Waiting time

프로세스가 준비상태의 큐로부터 얼마나 빨리 나오게 할 수 있느냐에 초점을 맞춘 것이 Waiting time이다.

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

오늘의 주제

- 좋은 스케줄링이란?

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

스케줄링 (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로 점프하여 먼저 처리한다.