|
Go back OS Review Device Driver NS Tools Home Papers Daily Link To Main |
4. 프로세스 (Process)
창세기 무렵의 컴퓨터들은 한번에 단 한개의 프로그램이 실행되는 환경을 제공해주고 있었습니다. 즉, 한개의 프로그램은 시스템의 컨트롤을 완전히 독점한체 시스템이 제공해주는 리소스에 대한 모든 권한을 쥐고 있게되는것이죠. 그러나, 오날날의 컴퓨터 시스템은 여러개의 프로그램이 메모리안에 로딩되고, 동시에(concurrently)실행되는 기염을 토하고 있습니다. 이러한 근대적인 환경을 제공해주기 위하여 등장하는 것이 바로 프로세스(process)라는 개념입니다. 프로세스란? 프로세스란 간단히 정의내리면 실행중인 프로그램을 의미하게 됩니다. 이것은 시분할(time-sharing)시스템의 기본 단위이기도 하지요. 결국 동시에 어떤 프로그램을 실행시킨다는것은 시간적으로 여러개의 프로세스를 돌아가면서 실행시키는 것으로 구현하게 되는 것입니다. 극단적으로 따지자면 결국 하나의 씨피유를 가지고 있는시스템에서는 진정한 의미의 멀티프로세싱이 불가능하겠죠? 프로세스라는 개념은 오에스차원에서 매우 중요합니다. 유저가 원하고자 실행시키는 프로그램 밑바닥에는 마치 평온한 호수가에서 유유자적하는 어플-프로세스백조가 빠져죽지 않으려 물갈퀴달린 오에스-프로세스들의발바닥을 촐싹거리면서 휘져어야 하거든요. 결국 시스템은 각종 프로세스들의 모음으로 이루어진다고 생각하셔도 무방할 지경일겁니다. 초반에 언급한 배치시스템은 잡(jobs)단위로 실행을 하게 되지요. 이에반해 시분할 시스템은 유저프로그램, 또는 태스크(task)단위로 실행을 하게 됩니다. MS-DOS또는 매킨토시 오에스조차! 몇가지 프로그램을 동시에 돌리는 능력이 있다고 교과서는 놀라워 합니다. -_- 정말,,,무시당해도 이만저만이 아니군요. 이러한 잡, 태스크 등등은 결국 비슷한 성격을 가지고 있기에 뭉뚱그려 프로세스라고 앞으로는 칭하도록 하겠습니다. 한가지 질문을 하지요. 다음 글을 읽고 옳다 또는 그르다라고 답하시오. "프로세스란 리소스를 점유한채 실행중인 코드를 의미한다" 제가 함정에 빠진 경험이 있는 질문이죠. 답은 옳소입니다. 왜냐하면 코드가 실행이 되려면, 메모리 씨피유등의 최소한의 시스템 리소스를 점유하고 있을수 밖에는 없기 때문입니다. 프로세스를 이루고 있는 구성요소들은 실로 다양합니다. 먼저 다음번 코드를 실행시킬 코드가 들어있는 주소를 가리키고 있는 프로그램카운터(씨피유 레지스터 내부에 존재하고있죠), 다른 참조해야할 레지스터들의 값, 잠시 필요한 값을 저장해두는 스택, 데이터, 그리고 전역변수 등등이죠. 프로그램 그 자체와 프로세스와의 가장 중요한 차이점은 프로그램 자체는 수동적 존재임에 반해 프로세스는 위의 정보를 바탕으로 살아움직이는 능동적 존재라는 사실입니다. 따라서 프로세스는 나름대로의 상태를 가지고 있겠죠? 총 다섯가지 상태로 크게 나뉘고, 각각의 상태에 대한 흐름도가 교과서 그림 4.1입니다. (교과서 사래두,,,좋데두,,,) 프로세스는 같은 프로그램에 귀속될지라도 서로 독립적으로 존재하게 되는데, 그 좋은 심플텍스트같은 어플이죠. 심플텍스트의 프로그램자체는 하나만 존재하지만, 여러개의 창을 열때마다 각각의 프로세스들이 생성되서 각각의 윈도우를 관리해주게 되지요. 이때 좀더 전문적으로 이야기하면, 각각의 프로세스의 텍스트 섹션은 동일하지만 데이터 섹션은 다르다! 라고 말하면 되겄습니다. 프로세스의 또 중요한 특징은, 이놈이 살아 꿈틀대는것으로만도 모자라서, 이제는 아들, 딸프로세스까지 생성이 가능하다는데에 있습니다. 무슨말이냐,,,한개의 프로세스는 위에서 말한 각종 정보를 가지고 태어나는데, 이녀석이 차일드프로세스(child process)를 만들게되면 부모 프로세스의 데이터및 스트럭쳐들이 모조리 복사되어 똑같은 붕어빵 프로세스가 태어나게 됩니다. 이때 생성을 가한 프로세스를 패런트프로세스(parent process), 생성된 프로세스를 차일드프로세스(child process)라고 하지요. 이러한 개념을 코딩으로 적용할때에는 매킨토시 프로그래밍만을 공부하던 저희들로써는 매우 생소할수도 있는 개념이죠. 다음장에 유닉스를 이용하여 위의 개념을 적용한 예를 설명해드릴 참입니다. 패런트 프로세스와 차일드 프로세스의 관계는 참으로 엄격하면서도 유용한 구석이 있습니다. 먼저, 차일드 프로세스는 글로벌이건 로컬이건간에 가리지 않고 패런트로부터 모조리 데이터를 복사해오는데, 복사된 순간부터는 각자의 길을 걷게 되지요. 로컬 변수야, 그냥 그려러니 해도, 나중에 패런트 프로세스의 글로벌 변수를 고쳐주어도 차일드는 그냥 씹어버립니다. 자신에게 이미 글로벌 복사본이 존재하닌까요. 그러면 도데체 이 두 부자지간의 프로세스사이에 놓여있는 세대차를 어떻게 극복해야하나 하는 문제가 대두되는데, 이를 해결해주는 것이 바로 IPC(Inter Process Communication)입니다. 이것은 초반에 언급한 몽키북이 다루는 주제이고 책한권의 분량이며, 말그대로 이젠 "통신"이라는 거창한 다리를 건설해주어야 둘간의 의사소통이 이루어지는 개별적! 존재가 되어버렸음을 의미하기도 하지요. 이 내용은 앞으로 반드시 다시 제대로 다룰예정입니다. 자, 이젠 다시 프로세스 고유의 성격을 논해보기로 하죠. 프로세스를 논하기 위해서는 먼저 PCB(Process Control Block)을 알아야합니다. 각각의 프로세스는 PCB로 대표되어지는데 이는 프로세스의 상태, 프로그램 카운터, 씨피유레지스터, 피씨유 스케줄링 정보, 메모리 관리 정보, 어카운팅 정보, 그리고 I/O상태정보등을 담고 있게 되지요. 거대한 레코드같은 존재입니다. 그러나 하나의 프로세스를 하나의 PCB로 표현할수 있다는 사실은 프로세스 간의 관계를 정의하고 나타내기 위해서는 매우 유용한 개념이죠. 먼저 프로세스 스케줄링은 멀티프로그래밍의 목적이 언제나 활성화되어있는 프로세스들이 존재함으로써 CPU가 놀지않고 그 활용도를 극대화 시키는 것이니 만큼, 이에 걸맞도록 설계됩니다. 스케줄링을 위해서는 언제나 큐(queue가) 필요해요. 참고로 큐(queue)란 FIFO(First In First Out)을 구현하는 데이터 스트럭쳐입니다. 먼저 온놈이 먼저 서빙을 받는다는 아이디어이지요. 한개의 프로세스가 시스템에서 생성이 되면, 일단 잡큐(job queue)에 쇽, 들어갑니다. 잡큐에 있던 녀석들이 메모리에 로딩되고 실행할 준비를 마치면 비로서 레디큐(ready queue)로 다시 쇽쇽 들어가는데 레디큐는 링크드 리스트로 이루어져 있습니다. 즉, PBC로 링크드 리스트를 만드는 것이죠. (이말 이해못하는 녀석, 일요일마다 아무생각없이 논녀석이여!) 이밖에 필요한 큐로서는 I/O와 관련된 프로세스를 담아주는 디바이스큐(device queue)라는 것이 또 존재하죠. 각각의 디바이스는 각자의 디바이스큐를 가지고 있게됩니다. 이젠 멀티프로그래밍이 구현되는 원리를 살펴보죠. 시스템이 p0이라는 프로세스를 실행하고 있었다고 칩시다, 그런데 불현듯 p1을 위한 인터럽트나 시스템 콜이 호출되버리면, 오에스는 즉시 p0의 PCB 내부 필드의 값들을 모두 업데이트 시킨다음상태를 레디상태로 돌려버리고 레드큐에 쑤셔 넣죠. 그대신 p1의 PCB를 러닝상태로 전환 시키고 필요한 값들을 씨피유의 레지스터에 주르르 펼쳐놓고 작업을 하게 됩니다. 같은 방법으로 다시 p0은 씨피유에 복귀되고 p1은 쫏겨나고,,,이런식으로 순간순간 여러개의 프로세스들이 자신의 상태를 바꾸어가며 질서있게 각자의 큐에서 씨피유의 호출을 기다리는 것이죠. 이렇게 레디큐에서 기다리는 프로세스들중 어떤녀석을 씨피유에 불러드리는 과정을 디스패치(dispatched)되었다!라고 말하는 것이고, 도데체 어떤 프로세스를 어느때에 디스패치 시킬것인가를 결정하는 알고리즘을 프로세스 스케줄링 알고리즘이라고 합니다. 프로세스 스케줄러(구현된 스케줄링 알고리즘)는 또 크게 두가지로 나누는데 첫째는 롱텀 스케줄러(long-term scheduler) 또는 잡 스케줄러(job scheduler)라고 일컫죠. 이녀석은 생성될 프로세스중 어떤것을 메모리에 로드 시킬것인가를 결정합니다. 또하나는 숏텀 스케줄러(short-term scheduler)또는 씨피유 스케줄러(cpu-scheduler)라고 하며 이녀석이 바로 레디큐에서 어떤것을 디스패치 시킬것인가를 결정하게 됩니다. 이둘의 가장 큰 차이점은 결정의 빈도에 있다고 할수 있는데, 숏텀 스케줄러의 경우 프로세스당 100밀리초 마다 실행이 되야할경우(프로세스당 씨피유점유 시간) 10밀리초가 걸린다면 매 프로세스 실행시간의 9%를 단지 다음번 프로세스를 결정하는데 사용하는 결과를 초해하게 되지요. 이와 달리 롱텀은 정말 멀티프로그래밍의 정도 (얼마나 많은 프로세스를 생성하는가)에 따라 그 빈도가 비교적 천천히 발생하는 여유를 가지고 있습니다. 자! 여기서 우리는 왜 많은 어플을 띄우게 되면 시스템이 괜이 더 버벅되는지를 깨닫게 되죠? 프로세스 스케줄링 논할때 롱텀과 숏텀 스케줄링 이렇게 두개만을 여기서는 소개했지만, 원래는 한개를 더 갔다 붙이기도 해요. 바로 미드텀(mid-term) 스케줄링입니다. 미드텀 스케줄링은 이미 메모리에 존재하는 프로세스중 몇가지를 제거해줌으로써 멀티프로그래밍의 정도, 즉 씨피유및 메모리의 부하를 줄이는데 사용되는 기법인데 다른말로는 스와핑(swapping)이라고도 합니다. 이는 메모리 스케줄링에서도 등장하는 말인데 메모리에 프로세스를 올리는 스왑인(swap in), 메모리에서 프로세스를 제거하는(완전히 지우는 것이 아니라 하드디스크같은 기억장치에 보관을 하게 되지요) 스왑아웃(swap out)등이 있어요. 여기서 한가지 느낄수 있는 사실은 메모리 스케줄링을 잘하면 결국 프로세스 스케줄링 또한 효율적으로 이루어진다는 것이죠. 씨피유가 한 프로세스를 실행하다가 실행하던 프로세스의 상태를 저장하고, 또 다른 프로세스로 순간적으로 전환해서 실행을 하는것이 멀티프로그래밍의 원리라는 사실을 이젠 깨달으셨을겁니다. 이때 멋진 단어가 하나 등장하죠. 바로 '컨텍스트 스위칭(context switching)'입니다. 컨텍스트 스위칭이란 바로 씨피유가 그렇게 프로세스를 전환하는 순간을 일컫는 말인데요, 문제는 이것이 정말 순수한 오버헤드라는 사실입니다. 멀티프로그래밍을 구현하기 위하여, 본래의 프로세스들의 내용과는 관계없이 그냥 이루어지는 것이잖아요. 컨텍스트 스위칭은 오에스 자체보다는 하드웨어적인 환경에 더욱 영향을 많이 받게되죠. 이 컨텍스트 스위칭은 한 시스템의 성능을 평가함에 있어서 병목현상의 주된 원인이 되기도 해요. 그래서 이제는 프로세스들 끼리는 필연적으로 컨텍스트 스위칭을 필요로 한다는 사실을 극복하려는 과정에서 태어나는것이 바로 그 이름도 유명한 쓰레드(thread)입니다. 쓰레드에 대한 설명은 좀 나중으로 미루기로 하고, 일단 왜 멀티 쓰레딩이 빠른 성능을 보여주는지에 대한 기본적인 이해가 되시겠지요? - 바로 컨텍스트 스위칭이 없기 때문이죠 :) 일단 프로세스에 대한 이론적인 이야기는 여기까지 하고, 다음 장에서는 구체적으로 어떻게 패런트 및 차일드 프로세스를 생성시키고 이용하며, 그리고 종료시키는지에 대한 설명을 하기로 하죠. -duffer 경준 (http://vorlon.cwru.edu/~kxm73)
|