일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |
- 최적화
- Basic
- CSS-in-JS
- 기본
- react server component
- async
- vanilla-extract
- 리액트네이티브
- 컴포넌트
- front-end mocking
- styled-component
- 목킹
- 캐쉬
- 리액트쿼리
- amplify
- Cache
- JavaScript
- SWC
- mock service worker
- 비동기
- next hydration
- 개발자
- thread
- next.js
- mockoon
- 쓰레드
- sprinkles
- Concurrent Mode
- react-native
- 기초
- React
- 동기
- react-query
- Critical Rendering Path
- Babel
- 리액트
- link
- 아키텍처
- MSW
- 자바스크립트
- Today
- Total
Don’t worry about failures
Process & Thread 본문
1. 개념정리
1-1. 프로그램 ( Program )
어떤 작업을 위해 운영체제 위에서 실행할 수 있는 파일.
ex ) 웹 브라우저, 카카오톡
1-2. 프로세스 ( Process )
운영 체제 위에서 실행중인 프로그램
프로그램 명령어와 데이터들이 메모리에 올라오고 실행 중 또는 실행 대기중인 상태
1-3. 프로세서 ( Processor )
프로세스가 동작될 수 있도록 하는 하드웨어(=cpu)
( 동작: 프로그램의 자원들이 메모리에 올라오고, 실행 되어야 할 코드의 메모리 주소를 CPU의 레지스터로 올리는 것 )
1-4. 쓰레드 ( Thread )
프로세스 내에서 실행되는 여러 흐름의 단위
이렇게 개념만 보기 보다는 조금 더 시각적으로 봐보자.
현재 작업관리자 화면이다. 탭 이름에서 알 수 있듯이 프로세스는 하나하나의 실행중인 프로그램이라는 것을 알 수 있다.
그리고 재미있는 것을 발견했다. 구글 크롬의 경우 프로세스를 확인해보니 다른 작업을 하지 않았지만, 많은 프로세스가 열려있었다.
구글 크롬의 경우 하나의 페이지 안에서 부분 부분별로 프로세스가 열리는 것을 알 수 있었다. 카카오톡 또한 카톡방 하나에 하나의 내부 프로세스가 할당되는 것을 알 수 있었다. 이에 따라 많은 크롬 탭을 열고 많은 카톡방을 열게되면 메모리에 부담이 된다.
몇개 열어 놓기만 했는데 1기가 넘는 메모리를 사용하고 있다. 여기에 영상 틀고 뭐하고 뭐하면,, 금방 올라가는 것을 알 수 있다.
2. 프로세스
이제 본격적으로 프로세스에 대해 알아보자.
하나의 프로세스는 Stack, Heap, Data, Text ( 또는 Code )로 구성이 되어 OS로부터 메모리가 할당이 된다.
여기서 중요한 사실은 CPU ( 프로세서 )는 하나의 프로세스만 실행이 가능하다는 것이다.
위의 사진(작업관리자)에서 확인 했을 경우 동시에 여러개의 프로세스가 열려있고, 우리는 유튜브를 보며, 카톡을 하기도 하고 문서 작업도 할 수가 있다. 하지만 하나의 cpu는 하나의 프로세스만 진행을 한다?
가능한 이유는 운영체제가 짧은 시간에 수십번에서 수천번씩 프로세스를 교체하며, 실행을 돌리고 있기 때문에 가능하다. 우리는 이 때문에 여러 개의 작업이 동시에 가능하다고 느끼는 것이다. ( 멀티 테스킹 )
이렇게 운영체제가 순간적으로 프로세스를 교체해 가며, 실행을 하기 위해서는 프로세스의 상태, PCB( Process Control Block) 를 파악하고 있어야한다.
프로세스의 상태에 대한 내용까지 다루기에 글이 너무 길어질거같아 참고 링크만 첨부하기로 한다.
(https://enlqn1010.tistory.com/30)
PCB ( Process Control Block )
어떤 프로세스가 어디까지 진행이 되었는지에 대한 정보. 즉 프로세스를 제어하기 위한 정보 모음
- 프로세스 식별자 ( Process ID )
- 프로세스 상태
- 다음에 진행할 명령어의 주소
- 이전에 작업하던 작업 내용 ( 레지스터 )
- CPU 스케줄링 정보 (우선 순위, 최종 실행시각, CPU 점유시간 등)
- 프로세스의 주소 공간 등
이렇게 프로세스는 여러 프로세스가 실행이 될때 계속해서 프로세스가 스윗칭 된다는 것을 알 수 있다.
위의 flow와 같이 스윗칭될 때마다 해당 되는 시점에서 PCB 등에 대한 정보를 넘겨주고 이에 대한 로딩이 필요하게 된다. 이러한 변경되는 순간 순간을 context switching이라고 한다.
이러한 Context Switching마다 비효율이 발생하게 된다. 우선, 언뜻봐도 변경될때마다 정보를 주고 받고 하는 행위가 비효율 초래할 것이라 느낌이 온다.
조금 더 자세히 살펴 보면,
비효율 1.
프로세스는 위에서 언급했듯이 Stack, Heap, Data, Code의 영역으로 메모리를 할당 받게 된다. 이 할당 받은 메모리는 다른 프로세스와의 공유가 되지 않는다. 이렇기 때문에 context switching이 일어날때마다 옮겨지는 메모리 영역 정보들이 다시 로딩이 이루지게 된다.
비효율 2.
context switching이 일어나면서 이전 프로세스에 있는 정보를 공유를 하기 위해서는 통신에 대한 어떠한 활동이 필요하게 된다.
이와 같이 하나의 프로그램 안에서 여러 프로세스를 열게되면, 메모리적으로, 시간적으로 비효율이 발생되는 것을 알 수 있다.
이를 보완하고자 멀티 쓰레드의 개념이 나온다.
3. 쓰레드
쓰레드는 개념에서 알 수 있듯이 프로세스 내에 흐름의 단위이다. 예를 들면, 하나의 웹브라우저에서 게임을 설치를 하고 설치하는 도중에 그 게임에 대한 설명 등 찾아보고 게임 아이템을 찾아보는 등 하나의 프로세스 내에서 여러 작업을 동시에 할 수 있게 해주는 것이 쓰레드이다.
가장 중요한 것은 Heap, Data, Code에 대한 정보를 공유를 하고 Stack에 대한 정보만 switching 시키며 지역변수 값만 변경하며 프로세스가 진행이 된다. 이와 같은 flow를 가지게 되면 context switching에 있어 불필요한 데이터 로딩, switching의 비효율을 줄여줄 수 있게 된다.
멀티 쓰레드 주의점
- 디버깅이 까다로움 ( 같은 변수를 사용하고 있기 때문에 어디서 어떻게 발생되는지 찾기가 어려움 )
- 한 프로세스 안의 스레드가 문제 생기면, 같은 프로세스 안의 스레드도 같이 문제 생김
- 같은 데이터를 공유하기 때문에 데이터 동기화에 신경을 써야함
위의 문제와 같이 잘못된 쓰레드의 구성은 오히려 혼란을 줄 수 있다. 이에 따라 lambda, closure, Functional programming, actor 등 다양한 도구나 프로그래밍 방식들이 개발자들을 도와주고 있다.
결론은 멀티쓰레드, 멀티 프로세스은 적재적소에 맞게 잘 사용하는 것이 중요하다.
'cs' 카테고리의 다른 글
멀티태스킹 멀티프로세싱.. (0) | 2024.03.13 |
---|---|
쓰레드에 대해 (0) | 2024.03.13 |
CORS에 대해 (0) | 2021.06.20 |
컴파일러와 인터프리터 (0) | 2021.06.05 |
cs 기초 ( Intro ) (0) | 2021.06.05 |