CPU는 어떻게 여러가지 일을 한번에 처리할까?

최근 스레드 풀에 대해서 공부하기 전에 스레드가 어떻게 운영체제에서 관리되는지 공부하기 위해 찾아보다 "스레드 생성 비용과 스레드 풀과의 관계" 포스팅을 작성했던 기억이 있어서 다시 찾아보게 되었습니다. 

 

PCB와 TCB에 대한 내용이었는데 겉핥기 식으로 이 둘에 대해 알고 있었다보니 이번 기회에 제대로 공부하자고 마음먹고 공부하게 되었습니다. 

 

이번 포스팅은 PCB에 대한 내용이 주된 내용이지만 PCB와 연관이 깊은 컨텍스트 스위칭도 같이 정리해보도록 하겠습니다. 

 

PCB (Process Control Block)

PCB는 운영체제가 프로세스를 관리하기위해 사용하는 자료구조입니다. 프로세스를 관리하기 위한 메타데이터가 저장되어 있고 주요 메타 데이터로는 PID, Program Counter, Register, 메모리 관련 정보, CPU 스케줄링 정보 등이 있습니다. 

 

이번 섹션에선 Program Counter (이하 PC), Register (이하 레지스터)에 대한 내용에 대해서 깊이있게 공부한 내용을 정리해보았습니다. 

 

PC (Program Counter)

PC는 프로세스가 다음에 실행해야할 명령어가 담긴 메모리 주소를 가지고 있습니다. 보통 PC는 차례대로 명령어를 실행하면서 값을 하나씩 증가시켜 다음 명령어를 순차적으로 실행하게 됩니다. 

 

PC는 다음과 같은 동작 원리를 가지고 있습니다. 

 

1. CPU는 PC가 가지고 있는 다음 명령어가 담긴 메모리 주소를 가져옵니다. 
2. 명령어를 가져오자마자 PC의 값이 하나 증가합니다. 다음 명령어 주소를 가리킵니다. 
3. 가져온 명령어를 실행합니다. 

만약 이 때 if 문 같은 분기가 생기게 되면 명령어가 순서대로 실행되지 않는데 if 문을 만나면 분기에 맞는 명령어 주소로 덮어 씌워 순차적인 명령어 실행을 건너 뜁니다. 

 

Register

레지스터는 프로세스를 실행하기 위해 사용되는 재료같은 요소입니다. 

 

예를 들어서 프로세스가 과제라면 레지스터는 그 과제를 수행하는데 필요한 재료입니다. 수학 과제라면 계산기, 노트, 펜이 될 것이고 과학 과제라면 현미경, 돋보기, 플라스크 같은 것이 될 것이죠. 

 

때문에 레지스터는 프로세스에 종속적이고 프로세스와 레지스터가 일치하지 않는다면 프로세스에 오류가 발생하게 됩니다. 

 

수학 과제를 풀려는데 현미경, 돋보기, 플라스크가 눈 앞에 있으면 수학 과제를 하지 못하는 것과 마찬가지이죠. 

 

 

PC가 분기를 만나면 다음 실행할 명령어가 아닌 분기에 맞는 명령어 주소로 덮어 씌워진다고 했는데 현실에서는 분기 뿐만 아니라 프로세스가 변경되는 상황에서도 다음 명령어가 순차적이지 않습니다. 

 

네, 바로 컨텍스트 스위칭 상황입니다. 

 

컨텍스트 스위칭

컨텍스트 스위칭은 운영체제가 프로세스 여러개를 동시에 실행하는 것처럼 보이게 하기 위해서 프로세스를 번갈아가면서 실행하는 것을 의미합니다. 

 

동시에 실행시키는 것처럼 보이게 한다는 의미는 실제로는 동시에 실행되는게 아니라는 말입니다. 

 

보통 10~100ms 정도의 텀을 두고 프로세스를 교체하는데 요즘 리눅스는 우선순위에 따라 우선순위가 높은 프로세스를 먼저 실행시키는 스케줄러를 가지고 있기도 합니다. 이 내용은 너무 딥한 내용이라 겉핥기만 공부했기 때문에 포스팅에 작성하진 않겠습니다. 

 

프로세스를 스위칭하는 과정에서 각기 다른 컨텍스트를 유지하면서 스위칭하려면 해당 프로세스에 대한 문맥이 완벽하게 관리가 되어야하고 이 때 PCB의 위력이 발휘됩니다. 

 

PCB에는 프로그램 카운터와 레지스터가 있으니 컨텍스트 스위칭을 유려하게 관리하게 되는데 지금부터 PCB가 컨텍스트 스위칭을 어떻게 도와주는지 정리해보겠습니다. 

 

1. 프로세스 A가 실행되다가 A가 점유한 시간이 다 되었습니다. 
2. CPU가 빠르게 현재의 프로세스가 가지고 있던 레지스터를 A의 PCB에 레지스터를 복제하고 다음 실행할 명령어에 대한 주소를 PC에 저장합니다. 
3. 프로세스 B가 실행되기 위해서 B의 PCB에 넣어놨던 레지스터를 CPU 레지스터를 싹 정리한 뒤에 오버라이트합니다. 
4. CPU가 B의 PCB 안에 PC에 적힌 명령어 주소를 가져와 실행합니다. 

그런데 저는 이 내용을 공부할 때 이런 의문이 들더군요. CPU의 레지스터는 프로세스의 레지스터를 위한 발사대인가? 라는 생각이 들더군요. 

 

이걸 앞선 예시를 이용해서 설명하면 다음과 같습니다. 

 

CPU는 책상 프로세스는 과제, 레지스터는 재료였죠. 책상 위에서 수학 과제를 할 땐 계산기, 노트, 펜을 이용해서 과제를 하다가 갑자기 과학 과제를 해야하면 어떻게 될까요? 그럼 책상 위에 있는 모든 재료들을 싹 정리하고 현미경, 돋보기, 플라스크를 가져와야죠. 

 

CPU의 공간은 하나밖에 없기 때문에 모든 프로세스들이 이 한 공간을 동시에 사용해야하다보니 책상이 비워지고 다른 재료를 가져오는게 합리적이죠. 

 

번외 (JVM의 PC Register)

JVM을 공부하다보면 JVM 메모리 영역에 PC Register라는 것이 있습니다. 얘도 네이밍을 풀어보면 Program Counter Register이기 때문에 분명 연관이 있을 것이라고 생각했습니다. 

 

JVM은 자바 코드로 되어있는 것들을 클래스 파일로 컴파일해서 바이트코드로 변환하는데 JVM은 이 때 내가 다음에 실행시켜야할 바이트코드를 적어놓습니다. 

 

이 때의 개념이 PCB에서의 Program Counter와 일맥상통합니다. 

 

하지만 JVM 또한 운영체제 입장에서 실행해야할 프로세스입니다. 즉, 이중 구조로 되는 것이죠. 

 

운영체제는 JVM을 관리하기위한 프로세스를 관리하고 JVM의 다음 명령을 위해 PC가 존재합니다. 이어서 JVM 내부에서도 바이트 코드를 실행하기 위한 PC가 존재하죠. 

 

번외2 (Thread Control Block)

운영체제를 개발한 개발자들이 PCB가 마음에 들었는지 스레드를 관리할 때도 TCB라는 것을 이용해서 스레드를 관리하고 있습니다. 이에 대한 내용은 아래의 링크에 자세히 설명이 되어있으니 참고해주시면 감사하겠습니다. 

 

https://coding-review.tistory.com/572

자바는 스레드 생성비용이 어느정도길래 스레드 풀을 둘까?

 

마치며

요즘 클라우드 자격증을 공부하느라 블로그 포스팅을 쓸 시간이 없었는데 이미 한달 가까이 안쓰게 되어서 이건 안되겠다 싶어 주말에라도 써야겠다는 생각을 했습니다. 

 

다음 포스팅은 "스레드 풀은 어떻게 동작할까"에 대한 내용을 쓸 예정이니 많은 관심 부탁드리겠습니다. 

 

이번 포스팅을 작성하기위해 공부했던 내용들이 운영체제를 공부했던 것 중에서 가장 재밌어서 공부하는데도 즐겁게 했던 것 같습니다. 

 

이번 포스팅은 여기서 마치도록 하겠습니다. 오늘도 즐거운 하루 되세요!