요즘 운영체제의 대해 공부하다가 스레드 부분에서 이해가 안 가는 부분이 있었다.
책에 보면 이렇게 설명되어 있다.
스레드란?
- 프로세스의 실현 가능한 가장 작은 단위
- 프로세스는 여러 스레드를 가질 수있다.
- code, data, stack, heap을 각각 생성하는 Process와는 달리 Thread는 code, data, heap을 스레드들끼리 공유한다.
위의 설명만보고는 엥? 하게 되는 나의,,,,실력이었다.
글로만 봐서는 이해가 잘 가지 않아 검색으로 알아보았다.
간단한 비유로 설명하자면
빌딩 건물 자체가 CPU라면 Process는 사무실을 임대하여 들어가는 회사 사무실이라 할 수 있다.
빌딩 주인에게 몇 평 사무실이 필요하다고 이야기를 하면 사무실 공간을 할당받는다.
사무실 안에는 여러 명의 직원이 있다. 직원들은 각자 독립적으로 본인들의 일을 한다.
그리고 같은 사무실에 있는 직원들은 서로 프린터와 회의실, 자료들을 서로 공유한다.
프린터, 회의실, 자료들은 스레드가 서로 공유하는 heap, stack, code라고 할 수 있다.
같은 빌딩(CPU)에 있다고 해서 다른 회사 사무실에 가서 프린트를 하는 경우는 없다.
CPU는 상가 빌딩, Process는 회사의 사무실, Thread는 직원이라고 비유 할 수 있다.
위의 책의 내용에 내가 해석한 것을 주석으로 붙인다면
스레드란?
- 프로세스의 실현 가능한 가장 작은 단위 // 사무실에서 일하는 직원 1명
- 프로세스는 여러 스레드를 가질 수 있다. // 사무실에는 여러 직원이 일 할 수 있다.
- 코드, datat, stack, 힙을 각각 생성하는 프로세스와는 달리 스레드는 코드, 데이터, 힙을 스레드들끼리 공유한다. //다른 사무실끼리는 프린터, 회의실, 자료를 공유하지 않으나, 같은 사무실 직원들끼리는 공유한다.
싱글 스레드는 직원 1명이 일할 때 다른 직원은 일을 할 수 없다,,, 사무실에 자리가 하나인 샘이다.
매우 비효율적이다.
멀티스레드 Multi Thread
- 프로세스 내의 여러 개의 스레드를 멀티스레딩으로 해결
- 스레드끼리 자원을 공유하기 때문에 효율성이 높다.
- 단점 : 한스레드에 문제가 생긴다면, 다른 스레드에도 영향을 끼쳐 스레드로 이루어져 있는 프로세스에 영향
여기서 궁금증 하나
CPU는 하나의 일만 처리할 수 있는데 어떻게 멀티로 스레드를 돌릴 수 있는 거지?
CPU의 코어가 여러 개라서 여러 개로 나눠 멀티스레딩 할 수 있다.
포프 님의 멀티스레딩 영상 발견
멀티스레드의 자세한 내용이 궁금하여 여러 가지 검색하고 찾아보던 중
포프 TV라는 채널을 발견하여 아래 영상을 보게 되었다.
멀티스레드의 역사를 시간순으로 설명하여 이해가 굉장히 쉽다.
게임 업계에 오래 계신 분이라 게임을 비유하여 설명하는데, 지금 나의 현업에서도 적용해 볼 수 있을 거 같다.
위 영상 내용을 정리해 보자면 이렇다.
90년대
single CPU, 코어나 하나였다. 코어가 하나였지만 그때도 멀티스레딩을 하였다.
(흠,,, 과연 이를 멀티스레드라고 할 수 있을까?)
일부분만 논블로킹 연산이 있었다.
예시를 들어 설명하자면
블로킹은 업로드를 누르면 5분 있다가 "업로드가 완성되었습니다.라는 안내문구를 보기 전까지는 컴퓨터에서 아무 동작 하지 못하였다.
논 블록킹은 업로드 중 잠시 멈추고 사용자가 다른 동작을 수행한 뒤 다시 뒤에서 업로드를 하는 것, 사용자에게 멈추는 것을 숨기기 위해 멀티스레딩을 했었다. networking, file I/O
이로 인해서 추가적으로 과부하가 일어나지만 스무스한 UX가 가능했었다.
장점은 오로지 UX,,,,,
단점은 오버헤드가 발생한다.
작업대는 하나고 메인 직원과 I/O직원이 한 작업대에서 번갈아 가면서 작업하는 것과 같다.
main 직원이 책상에서 일하다가 main의 작업이 끝나자마자 main직원을 치우고 I/O가 가서 일하고,,
main -> I/O -> main -> I/O 계속 번갈아 가면서 작업하다고 생각을 해보자.
main이 끝나자마자 I/O가 가서 작업대에 가서 일을 하면 바로 업무를 시작할 수 있을까?
전에 얼마만큼 했는지 찾아보는 것, 그 행위를 Context Switch라고 한다.
Context Switch가 많이 발생하면 오버헤드가 발생한다.
진짜로 2가지 일을 동시에 하는 것이 아니라 성능이 좋지도 않았다.
90년대를 정리하자면
90년대는 Single 코어라서 논블록킹 연산을 통해 멀티스레딩 같은 UX를 제공하였다.
하지만 많은 Context Switch를 발생시켜 오버헤드가 발생할 수 있는 단점이 있다.
성능도 좋지 않았다.
2000년대 중반
CPU하나 안에 코어를 2개 달았다. 제대로 멀티스레드를 해야 하는 순간이 왔다.
Main Thread(update), Render Thread 이렇게 두 개로 나누어 준다.
update Thread가 데이터를 받아 Render Thread에 복사해 주면 Render Thread는 화면에 열심히 그리고, Update Thread는 다음 프레임을 받아 오는 것으로 두 개로 분리하였다.
그렇다면,,,, 코어가 4개로 늘어나면 어떻게 할 것인가?
Process별로 나눠서 멀티스레딩을 수행하였다.
Revisiting game loop
프로세스 기반으로 Thread를 나누기보다는 데이터를 기반으로 Thread를 나누자
수천, 수백 개의 object가 존재하고 object들은 비슷하다.
- 물체의 물리 계산
- 물체마다 애니메이션 존재
- 화면을 차지하는 바운딩 박스(화면에 보이는 부분) 계산
- 렌더링 계산
모든 물체에 적용되는 계산이 비슷하다. 물체와 물체와 연관된 계산이 800개이고 코어가 8개라면 한 코어에 100개씩 Thread로 나누어 연산을 수행한다.
계산, object(물체) 별로 나누어 여러 코어에서 수행한다.
나의 현업에서 적용해 보자면
SDTM Dataset을 변환할 때 환자별로 데이터를 나누어 코어마다 변환을 수행하는 것이 효율적일 것 같다.
한 환자에 대한 dataset이 나오도록 환자별 변환이 마치면, 환자 번호별로 리스팅 하여 최종 dataset을 만들면 매우 빠르고 효율적 일 것 같다.
포프 TV 님의 영상을 통해 멀티스레딩의 역사부터 들으니 쉽게 이해가 되었다.
이분 영상 굉장히 재밌고 유용한 게 많으니 꼭 한번 유튜브 들어가서 보세요
후회하지 않는 시간 보내실 수 있을 겁니다:)