🙂 Process

Process 란?

실행중인 프로그램 이라고 할 수 있으며, 물리적으로는 메모리에 로드된 프로그램 데이터를 의미한다.

Why?

왜 Process 라는 개념이 필요할까? 라고 묻는다면 나는 이렇게 대답할 것 같다.

동적인 상태의 프로그램(프로세스) 를 데이터화 하여 우리가 관리할 수 있도록 하기 위해서 Process 가 필요하다.

프로세스 라고 적은 것은 말 그대로 동적인 상태의 프로그램을 지칭하는 말이고, Process 는 우리가 직접 조작할 수 있는 프로세스 추상화 객체 정도로 생각할 수 있다.

이게 무슨 말장난 처럼 느껴질 수 있는데, 조금 더 부연 설명을 해보겠다.

앞서 OS 게시글에서 하나의 프로그램의 데이터와 Instruction 을 한꺼번에 메모리에 로드하는 것을 프로세스를 생성한다 라고 했다.

여기서 먼저 생각해볼 수 있는 것은 메모리에 로드를 한다는 것이 어떤 의미를 갖는지에 대한 것이고, 그 다음은 메모리에 어떤 정보가 로드되는지에 관한 것이 될 수 있다.

---

구조

Process 는 최대 4GB 의 메모리를 점유할 수 있다(어디까지나 논리적으로 그렇다는 것이고 실제로는 약 3GB 라고 한다)

그렇다면 내가 16GB 메모리를 쓰고있다면 4개의 프로세스만 로드할 수 있을까? 그 이전에 하나의 프로세스는 4GB 의 메모리를 모두 다 사용할까?

당연히 아니다. 실제로 프로세스는 할당된 공간에 저장된 데이터보다 남는 공간이 훨씬 많기 때문에 우리가 논리적으로 할당된 공간을 전부 차지하고 있진 않는다.

오히려 프로세스는 공간을 공유하고 심지어 물리적으로는 하나의 프로세스가 연속적인 메모리공간을 가지고 있지도 않는다!

가령 4GB 의 메모리가 있다면 프로세스가 아래 사진과 같은 방식으로 메모리 공간을 나눠서 각각의 공간을 공유하고 있는 방식이다

각각의 공간에 대해 간략하게 설명하자면

OS kernel Space : 말 그대로 kernel 프로그램의 memory 영역이다 실제로 사용자 프로그램에서 Stack 이 존재하지만 해당 Stack 은 사용자 프로그램을 위한 영역이고 systemcall 스택은 따로 kernel stack 이라는 곳에 쌓여 트랩이 발생했을 때 해당 영역의 데이터를 참조하여 명령을 수행한다.

Stack : 사용자가 생성한 메소드의 영역을 의미하며 하나의 메소드 별로 일정 크기의 공간을 가지고 데이터를 사용한다. 어셈블리 코드로 구현하면 stack pointer 로 offset 을 통해 공간을 확보하는 것을 의미한다.

Heap : 런타임 상에서 할당되는 메모리를 위해서 존재하는 영역으로, 대표적으로 컴파일 시점에는 예상할 수 없는 데이터의 크기를 런타임 상에서 부여하는 동적할당(malloc) 등의 명령을 위해 존재한다

BSS : 아직 초기화되지 않은 static(프로그램 정적 변수, 즉 이 프로그램에서 공통적으로 사용될 것 같은 변수를 미리 메모리에 올리는 방식) 변수 저장 공간인데 따로 영역을 둠으로써 프로그램 전체 크기를 줄일 수 있다고 한다.

Data : 초기화된 static 변수가 들어가는 공간으로 위에서 설명한 바와 같다.

Text : 프로그램의 instruction 이 저장된 공간으로 CPU 는 instruction 을 참고해서 연산을 수행한다

---

PCB

CPU 는 연산 장치다. 그렇다면 무엇을 연산할까? 바로 레지스터에 저장된 값과 instruction 이다. 그리고 이 값들은 메모리에서 불러온다.

즉 CPU 는 그냥 계속 밀려들어오는 값과 instruction 을 처리할 뿐이다. 그렇다면 어떤 데이터 집합들을 밀어넣을지에 대한 고민이 필요한데, 이 때 같은 종류의 데이터로 묶을 수 있는 것이 하나의 프로그램, 즉 프로세스가 될 수 있다.

이 동작하는 프로그램이라는 개념을 데이터로 표현한 것이 Process 이고, 실제로 이 Process 는 PCB(Process Control Block) 이라는 구조체로 process 정보를 저장하여 Kernel 이 관리한다.

이제 CPU 위에서 동작하는 프로그램이 직관적으로 보이기 시작한다.

PCB 에 저장된 데이터는 아래와 같다

1. Process State : 프로세스가 어떤 상태인지 (아래에서 부연 설명)

2. Program Counter : 프로세스가 명령어를 어디까지 수행했는지

3. CPU registers : 저장될 당시에 register 값들

4. CPU scheduling info : CPU 에 의해 어떤 순서로 처리될 것인가

5. Memory-management info : 메모리를 얼마만큼 차지하고 있는가

6. Accounting info : 이 프로세스가 CPU 자원을 얼마나 사용하는지

7. I/O status info : 현재 연결돼있는 디바이스 정보

위와 같은 정보는 왜 필요할까?

그거슨 바로 Process 가 관리될 필요가 있기 때문이다..!!

---

Process 관리

앞서 Process management 는 kernel 의 역할이라고 했다

PCB 가 존재함으로써 kernel 은 PCB 만 저장하고있으면 전체 Process 를 모두 관리 가능하다고 볼 수 있다.

실제로 각 Process 가 생성될 때 마다 PCB 가 생성되어 되고 kernel 이 PCB 리스트를 저장하고 있다.

Process 를 관리한다는 것은 CPU 가 처리하는 Process 를 정해주는 것과 밀접한 연관이 있는데, CPU 는 기본적으로 한번에 하나의 Process(엄밀히 따지면 thread) 를 처리할 수 있기 때문에 주기적으로 처리되는 process 를 교체해줄 필요가 있다.

처리되는 Process 의 교환이 일어나는 것을 Context Switching 이라고 하는데, kernel 의 scheduling 규칙에 따라서 다음에 처리될 Process 가 결정된다.

Context Switching

Context Switching 을 하는데는 여러 이유가 있겠지만 가장 핵심적인 기능은 사용자로 하여금 프로그램이 동시에 동작하고 있는 것처럼 느끼게 한다는 것이다.

kernel 은 PCB 를 사용하여서 바로바로 process 의 정보를 불러오고 현재 실행중인 process 는 다시 PCB 형태로 저장해서 메모리 혹은 디스크에 저장해둔다.

자주 사용하는 PCB 는 메모리 ready queue 에 적재(선점)가 될 것이고 비교적 우선순위가 낮거나 I/O 대기 중인 process 는 wait queue 에 적재가 된다.

자세한 process 의 life cycle 은 아래와 같다

life cycle

최초 fork system call 로 부터 새로운 process 가 생성된다.

프로그램이 실행되면 곧바로 ready 에서 run 단계로 넘어갈 것이다

run 은 실제로 cpu 자원을 할당받아서(cpu 가 해당 프로세스의 연산을 처리한다는 뜻) 동작한다.

중간에 I/O device 처리를 기다려야 하는 등의 idle 상태가 예상이 되면 wait 단계 혹은 ready 단계로 돌아가서 대기를 하고 있다가 I/O controller 의 인터럽트가 발생하면 그제서야 다음 동작을 이어나갈 수 있다.

동작이 마무리 되고 프로세스가 더이상 연산할 것이 없으면 terminate 된다

---

🙂 Thread

process 와 항상 같이 나오는 thread 는 실제 kernel 의 scheduling 단위 이다.

분명 앞서서 scheduling 은 process 를 가지고 수행된다고 했는데, 이야기가 달라져서 이해가 잘 안될 수 있다.

여기서 내가 말하고 싶은 것은 프로세스나, 쓰레드나 전부 다 우리가 만든 논리적인 개념에 불과하다는 것이다.

연산 주체인 cpu 는 지금 수행하고 있는 작업이 A process 인지 B process 인지 혹은 A process 내부의 1번 thread 인지 궁금하지도 않고, 계속 밀려들어오는 연산만을 수행할 뿐이다.

이게 무슨 말이냐면 프로세스 내부에서 연산될 순서를 내가 임의로 정해서 cpu 에 밀어넣는다면 cpu 는 마치 프로세스 내부를 쪼개서 동작시키는 것 처럼 보일 것이다.

조금 더 쉽게 설명하자면 하나의 프로세스 내에서도 분명 먼저 연산을 처리했으면 하는 부분이나, 동시에 처리가 됐으면 하는 부분이 생길 것인데

가령 요청된 페이지를 제공해주는 프로그램이 있다고 쳤을 때 해당 프로그램이 단일 요청만을 처리한다면 뭐 물론 속도 자체는 빠르겠지만 100명이 요청을 보낸다면 분명 뒤에 몇명은 응답을 기다리기가 굉장히 지루할 것이다.

반대로 2번째 요청이 들어왔을 때 나의 프로세스의 다음 연산을 2번 요청을 처리하는 로직을 수행하도록 구현한다면?
그리고 일정 시간(엄청 짧은 시간) 후에는 다시 1번 메소드를 처리하도록 한다면??
분명 첫 번째 사용자는 위의 방식보다 느리다고 생각할 수 있지만 뒤에 기다리는 사용자는 요청이 처리된다는 느낌을 보다 빠르게 느낄 것이다.

요청이 들어올 때마다 요청을 처리하는 프로세스를 추가하면 안되나요?

안될 것은 없지만, 프로세스를 생성하는 것은 쓰레드를 프로세스 내에서 생성하는 것보다 엄청 많은 시스템 오버헤드를 발생시킨다.

간단하게 생각하면, 프로세스는 무에서 유를 창조하는 행위고, 쓰레드는 이미 깔려있는 판에서 부가적인 작업을 추가하는 것으로 비교를 할 수 있을 것이다.

구성 요소

Thread 의 구성요소 라기 보다는 쓰레드가 프로세스 내에서 어떻게 분리가 되는지 알아보자

쓰레드는 크게 공유 영역 과 쓰레드 영역 으로 나눌 수 있다

공유 영역은 말 그대로 쓰레드간에 공유하는 데이터가 존재하는 공간을 이야기하는데, 해당 영역에는 code, data 등 프로그램 동작에 필요한 주요 데이터가 있다.

쓰레드 영역은 프로그램의 병렬 실행에 필요한 자원을 가지고 있는데, 위에 제시했던 예시와 관련해서 생각해보자.

각 사용자의 요청에 응답을 해줘야 하는데 사용자별 나이에 따라서 응답을 다르게 해준다고 생각해보자, 사용자의 나이는 프로그램이 정적(data 영역)으로 가지고 있을 수 없고 가변적인 요소다. 따라서 쓰레드별로 따로 데이터를 저장하는 stack 영역을 두고 여기에 가변적인 state 를 저장할 수 있다.

너무 어렵게 설명한 것 같은데, 쉽게 말하면 쓰레드는 일종의 함수다. 함수의 로컬변수가 존재하듯 쓰레드도 로컬 변수가 필요한 것이고, 함수로 볼 수 있는 이유가 process 의 함수용 데이터 영역이 stack 인 것과도 일치한다.

장점

이미 여기까지 읽었다면 여러 프로세스를 두는 것보다 쓰레드 여러개의 장점이 무엇인지는 예상할 수 있겠지만 정리하자면 아래와 같다.

프로세스를 통해 스케쥴링을 실현하려면 인터럽트가 필연적이다. Context Swithching 이 발생하는 동안에는 idle 즉 cpu 가 노는 시간이 발생하여 비효율적인 자원 활용을 초래한다.

반대로 쓰레드는 모든 코드 자원을 한 프로세스 내에서 공유하기 때문에 불필요한 인터럽트를 발생시킬 필요없이 병렬 처리가 가능하다

즉 빠르고 편리하다 !!!!!

단점

당연히 장점만 있었으면 프로세스라는 개념은 사라지고 쓰레드만 남았을 것이다.

단점은 멀티쓰레딩이 가능한 프로그램을 직접 구현할 수 있어야 한다는 것이다. 이게 왜 단점 중 하냐라고 묻는다면 시스템이 복잡해질수록 프로그램을 동작하는데 필요한 데이터가 늘어날 것이다.

혹시라도 런타임상에서 가변적인 state 가 공유 영역에 있다면 해당 데이터를 쓰레드간 동기화 해줄 필요가 있다. 즉 특정 쓰레드가 공유 데이터를 가지고 작업을 수행하는 동안에는 해당 데이터는 절대 수정되면 안될 것이다(혹은 예측 가능한 값으로 수정)

실제 임계영역(critical area) 데이터를 사용해야 할 때는 locking 혹은 이와 유사한 기법의 thread-safe 를 보장하는 방식으로 구현해야한다.

또한 이러한 방식으로 구현을 했다고 문제가 해결되는게 아니라 병목이 일어나지 않도록 코드를 잘 짜야한다...