[프로세스 vs 스레드 - 2] 프로세스 & 멀티프로세싱

---

[프로세스 vs 스레드 - 1] 프로세스와 스레드

본 글은 위의 글에서 이어지는 글입니다.

---

서  론

필자는 학부생 때 프로세스의 개념을 받아들이는 것이 조금 힘들었다.

프로세스가 그냥 소스 코드를 실행시키면 그게 프로세스라고 하는데, 그게 무슨 뜻인가?

그러면 소스 코드가 여러 개면……?

 

거기에 프로세스가 가지는 수많은 특성들까지 외우려고 드니,

더더욱이 와닿지 않았던 문제점이 있었다.

 

그러나 프로세스를 이해하는 것은 매우 간단하다.

 

위의 수많은 프로그래밍 언어로, 어떠한 프로그램을 만든다 가정하자.

소스 코드가 여러 개로 나뉘어서 모듈별로 개방-폐쇄의 원칙을 지킬 수도 있고,

아니면 개발 기한의 압박이나 경험의 부족으로 하나의 소스 코드에 모든 코드를 때려 넣을 수도 있다.

 

그러나 중요한 것은 실행을 시킬 때이다.

멀티프로세싱 코드를 짠 것이 아니라면, 보통 하나의 개발 산출물을 실행시키면 학부생 시절 때에 개발하는 단위에서는, 하나의 프로세스만 실행시킨다.

 

예를 들어, Python으로 AI 비전 소스코드를 개발했다고 쳤을 때,

소스 코드 자체는 아마,

 

1. 모든 것을 실행시키는 main.py

2. 모델을 이닛시키고 전체적인 flow를 담당할 process.py

3. 입력된 사진 파일이나 카메라 스트리밍을 통해 나온 이미지 배열을 detect할 detection.py

 

정도로 나누어 코딩할 것이다.

 

그러나 결국 실행하는 것은

$ python3 main.py

이 한 줄일 뿐이다.

그렇다면 이것은 프로세스가 1개인 프로그램이다.

 

스레드가 몇 개냐는 중요치 않다.

스레드가 10개, 100개, 1000개라도 프로세스는 한 개일 뿐인 것이다.

---

프로세스의 기본적인 특징

프로세스는 독립적이고, 스레드와는 다르게 동시에 실행이 가능하다.

 

여기서 정말 헷갈렸던 것은,

어떤 곳에서는 스레드가 동시성이 없다고 하고, 또 어떤 곳에서는 스레드도 동시성이 있다고 하는 것이었다.

(그래서 스레드는 동시성이 있도록 보여지기만 할 뿐, 그렇지 않다는 글도 많다.)

 

정확히 말하자면,

CPU는 1개의 코어 당 1~2개의 물리 스레드를 갖고,

논리 스레드는 물리 스레드의 갯수를 초과하는 순간 동시성을 잃게 된다.

 

예를 들어, intel이나 라이젠에서 개발하는 CPU 중에 8코어 16스레드를 갖는 CPU가 있다고 쳐보자.

 

어떠한 프로세스가 여기서 4코어 8스레드라는 CPU 전체의 50%의 자원을 할당받아 점유하게 되었다면,

논리 스레드는 최소 8개까지는 동시성을 지닐 수 있다.

단, 논리 스레드는 보통 (그리고 항상) 그 이상으로 넘어가기 때문에 동시에 진행되지 않는다.

그리고 보통 한 개의 프로세스가 저렇게 많은 CPU 자원을 할당 받는 경우도 잘 없다.

 

그것에 비해 여러 개의 프로세스는 운영체제에 의해 여러 CPU 코어와 여러 CPU 물리 스레드를 할당 받고, CPU 스케줄링에 의해 타이트하게 동시 실행을 하게 된다.

 

그래서 보통,

멀티프로세싱 = 동시성 O 병렬성 O

멀티스레딩 = 동시성 X 병렬성 O

 

라고 말하는 것이다.

 

일반적으로 멀티스레딩이라는 것은 1프로세스 멀티스레딩을 말하는 것이고,

일반적으로 멀티프로세싱이라는 것은 멀티프로세싱 멀티스레딩을 말하는 것이기 때문이다.

---

그러면 멀티프로세싱이 무조건 더 빠른 것 아닌가?

 

반응형

그렇지 않다.

일단 멀티프로세싱은 컨텍스트 스위칭이 없어서 멀티스레딩보다 일반적으로는 더 빠를 수 있으나,

데이터 영역을 프로세스간 쉐어링하지 않기 때문에 IPC(Inter Process Communication)라는 기법을 통해 통신해야 하고,

이때 생각보다 시간이 많이 소요된다.

 

그러니 공용으로 사용해야 하는 데이터양이 너무 많으면,

멀티스레딩보다 멀티프로세싱이 느릴 수도 있다는 소리다.

 

또한, 공용으로 사용해야 하는 데이터가 많으면 해당 데이터에 대한 오염이 일어날 확률도 높다.

락이나 세마포어를 잘 걸어야 하는데,

이게 초보 개발자가 하기가 정말 어렵다.

 

잘못하면 데이터가 오염되기 십상이다.

 

레이스 컨디션이나 임계 구역 진입 설정도 까다로워서,

잘못하면 아무 것도 안하고 평생 멈춰있는 프로그램을 만들 수도 있는 것이다.

 

대부분 멀티프로세싱의 구현보다는 멀티스레딩의 구현이 훨씬 더 간편하기도 하다.

 

그러나 파이썬의 경우는 이 이야기가 전혀 맞지 않는데,

그것은 추후 포스팅에서 더 깊게 다뤄볼 예정이다.

GIL이라는 파이썬만의 강력한 도구가 본인의 발목을 강하게 잡기 때문이다.

---

다음 편에 계속…….

---