- 본 글은 이전에 사용하던 영상 강의 필기 앱인 'Slid'에서 필기 했던 내용을 Velog로 옮긴 내용입니다.
- 본 글은 이화여대 반효경 교수님 2017학년도 1학기 운영체제 강의를 기반으로 작성되었습니다.
- 강의 링크 : http://www.kocw.net/home/search/kemView.do?kemId=1226304
운영체제라는 단어를 꺼내는 순간 분명히 이런 질문을 들을 것이다.
프로세스와 쓰레드의 차이는 무엇인가요?
혹은
프로세스와 프로그램의 차이는 무엇인가요?
아직 학교에서 운영체제 교과목을 듣지 않은 나조차도 수없이 들었던 질문이다. 그만큼 프로세스는 운영체제의 가장 핵심적인 개념이라 할 수 있다.
지난 강에서는 프로그램의 실행에 대해 알아보았다. 특히, 프로그램 스스로 할 수 없는 일을 할 때(I/O) 운영체제 kernel이 그 일을 어떻게 처리하는지에 대해 알아보았다. 따라서 이번 강은 지난 강의 연장선으로 I/O를 포함하여 프로그램이 요구하는 task들을, 운영체제는 어떻게 수행하고 관리하는지가 이번 강의 주제이다.
프로그램은 우리가 눈으로 볼 수 있게끔 파일로서 저장된 것, 즉, 실행 파일을 뜻한다. 일반적으로 주로 사용하는 Window에서는 .exe로 대표되며 Linux에서는 .out을 포함한 binary file 들을 뜻한다. 이것은 우리가 더블 클릭으로 실행하거나 파일을 열지 않는 이상 디스크 공간을 잡아먹는 파일 덩어리에 불과하다. 하지만 이것을 더블 클릭 혹은 명령어로 실행하여, 실행 파일에 적힌 기계어들을 읽어 들이고 그것이 메모리에 올라갈 때 그것을 프로세스(Process)라고 한다. 그러니까 프로세스는 프로그램의 하나의 객체, 인스턴스라고 표현할 수 있다.
여기서 한 가지 해야 할 가정이 있다. 논의의 편의를 위해서 우리는 CPU가 1개, 즉, 싱글 코어인 컴퓨터에서의 운영체제를 가정한다. 아무튼 CPU가 하나라는 가정이 생긴다면, 쉽게 생각하여 어떤 특정 시간에 처리할 수 있는 일은 오직 하나라는 결론이 쉽게 나오게 된다.(이후 쓰레드의 개념을 배운다면 이 문장은 틀렸다고 할 수 있지만 일단 넘어가자.) 이제 여기서 운영체제는 고민에 빠지게 되었다. CPU는 특정 시간에는 하나의 일만 처리할 수 있다. CPU는 정말 빠르고 성실한 녀석인데, 만약 어떤 프로그램이 엄청나게 많은 시간을 잡아먹는 행동을 요구했다고 하자. 예를 들어, disk에서 어디 구석에 처박힌 텍스트 1000만 줄을 읽어 들여 그것을 암호화해야 한다면, 우리는 그 텍스트 1000만 줄을 읽어 들일 때까지 아무것도 할 수 없게 가만히 두어야 할까?
프로세스 문맥(Process Context)
당연히 답은 No일 것이다. 그렇다면 어떻게 중간에 생기는 시간의 간극을 채울 수 있을까? 여기서 등장하는 개념이 프로세스의 문맥(Process Context)이다. '문맥(Context)'는 흔히 인문 서적에서 등장하는 단어이다. 우리가 수 년 전에 치렀던 수능에서도 '~ 문맥상 알맞은 것을 고르시오.'와 같은 질문들이 심심찮게 등장한다. 이때 등장하는 문맥의 느낌과 운영체제에서 등장하는 프로세스의 '문맥'은 큰 차이가 없다. 전자의 경우, 문맥을 글의 흐름 정도로 해석할 수 있는데 프로세스의 문맥 또한 마찬가지로 프로세스의 흐름 정도로 해석할 수 있겠다. 이 개념을 염두에 두고 진행해보자. 우선 위에서 1000만 줄을 암호화하는 예시에서 우리는 당연하게도 CPU가 그 지루한 프로세스를 붙잡고 놓아주지 않을 것이라는 멍청한 결과로 이어지지 않을 것임을 예상하였다. 왜 그렇냐고 묻지 말고 '내'가 바로 운영체제라고 생각한다면 그런 멍청한 짓을 하지는 않을 것이기 때문이다. 그렇다면 이것을 어떻게 해결할까? 프로세스의 '문맥'을 어딘가에 저장하고 다른 프로세스로 넘어가면 될 것 아닌가? CPU는 어차피 device에 직접 접근할 수 없다. 그러면 device한테, 여기서는 disk한테 "너는 1000만 줄 읽어올 때까지 일하고 있어. 나는 다른 거 하고 있을게." 라고 하면 될 것이다.
요컨대 특정 시점에서 프로세스가 어디까지 수행을 했는지 규명하는데 필요한 요소들을 프로세스의 문맥이라 부른다. Program Counter가 현재 프로세스의 code 영역 중 어디를 가리키고 있는가, 무슨 내용을 stack에 얼마나 쌓아놓고 있는가, 등등… 을 프로세스 문맥이라 한다. 그 내용에는 크게 세 가지로 나뉜다.
- CPU 수행 상태를 나타내는 하드웨어 문맥(CPU와 관련)
- 프로세스 주소공간
- 프로세스 관련 커널 자료 구조
1번 CPU 수행 상태를 나타내는 하드웨어 문맥이란 CPU의 PC가 해당 프로세스의 code영역 중 어디를 가리키고 있었는가, 어떤 내용을 stack에 얼마나 쌓아놓고 있었는가 등의 정보를 뜻한다.
2번 프로세스 주소 공간은 stack, data, code의 주소 공간 자체를 담고 있어야 그 문맥을 정확히 알 수 있을 것이다.
3번은 운영체제가 프로세스가 하나 생길 때마다 커널에 해당 프로세스와 관련한 정보를 생성하게 되는데 그러한 것들을 뜻한다. 대표적으로 PCB(Process Control Block)이 있다. PCB는 그 프로세스의 정보를 담고 있으며 이 자료 구조를 통해 커널이 프로세스를 관리하게 된다.
* PCB(Process Control Block)
프로세스가 운영체제한테 자기가 못하는 일을 요청했을 때, 즉, system call을 했을 때 Program Counter는 그 프로세스의 code를 가리키는 것이 아니라 커널의 code를 가리키면서 커널 스택에 저장하는데 , 이때 프로세스마다 커널 스택을 달리 한다.
(PCB에 관해 정확한 이해가 힘듬.)
프로세스 상태(Process State)
위와 같은 프로세스 문맥이 있고, 이 문맥을 통해 프로세스가 서로 번갈아가며 CPU를 점유하기 때문에 프로세스의 상태라는 개념이 존재한다. 기본적으로 프로세스 상태는 Ready, Blocked, Terminated 가 있다.
- Running은 말 그대로 현재 실행 중인 프로세스이다.
- Ready는 CPU가 당장 디스크 접근을 못하니까 당장 필요한 부분은 메모리에 올라와 있어야 수행 가능하다. 따라서 다른 모든 준비는 끝나 있는 상태로 CPU의 점유만을 기다리고 있는 상태이다.
- Blocked는 위 1000만 줄 예시에서도 나왔지만 디스크에서 뭔가를 읽어와야 하는 상태와 같이 어차피 cpu를 얻어도 당장 할 것이 없는 상태이다. 요청한 I/O 작업이 끝나서 기다리고 있는 waiting과 같은 상태 혹은 프로세스 실행 도중 Timer가 다 됐지만 할 일이 남아있을 때의 상태를 말한다.
이 그림을 간략하게 그림으로 나타내면 다음과 같다.
이렇듯 프로세스의 상태를 보고 운영체제는 프로세스를 관리하는데 이것은 queue를 통해 관리한다. 다음 그림을 먼저 살펴보자.
프로세스가 I/O device로 간다면(blocked) device controller에 의해 Disk I/O queue로 관리된다. 해당 프로세스의 I/O가 끝나면 device controller가 CPU에게 interrupt를 건다면 CPU는 프로세스 실행하다가도 OS에게 넘어가고, 커널은 그 프로세스의 메모리 영역에 데이터를 넘겨주는 역할도 할 것이며 프로세스 상태를 blocked state에서 ready state (혹은 queue)로 넘겨지게 된다. 이러한 큐들은 Kernel이 본인의 자료구조로 만들어 놓고 프로세스 상태를 바꿔가면서 운영한다.
