-
Process & Thread (OS)CS/OS 2021. 1. 17. 18:06
기본기의 중요성은 항상 느끼고 있는데요.
막상 제대로 알고 있는가 생각했을 때 그렇진 않은 것 같아 하나씩 정리합니다.
Process
운영체제로부터 자원을 할당받은 작업의 단위
Thread
프로세스가 할당받은 자원을 이용하는 실행 흐름의 단위
Program
파일이 저장되어 있지만 메모리에는 올라가 있지 않은 상태
간단하게 Process, Program의 차이부터 보면 아래와 같습니다.
Process는 자원을 할당받아 메모리에 올라간 상태로 실행된 상태를 의미합니다.
Program은 자원을 아직 할당받지 못한 Process가 되기 전의 상태로 이해하시면 됩니다.
즉, Program이 메모리에 적재되고 실행되면 Process가 됩니다.
그림 1. Process, Program Process 특징
- Code, Data, Stack, Heap으로 구성된 독립적인 메모리 영역을 할당 받음
- 프로세스당 최소 1개의 (main)Thread 소유
- 프로세스 간 통신(IPC, 파이프/소켓 등)을 이용하면 서로의 변수나 자료구조에 접근 가능
그림 2. Process, Thread Thread 특징
- 각 Thread는 자신만의 Stack과 Register를 소유
- 하나의 Process 내의 Thread는 Process에 할당된 자원, 메모리를 공유 (Code, Data, Heap)
- 즉, 커널의 도움 없이 상호 간 통신 가능
- 프로세스보다 생성 및 종료/전환 시간이 짧다.
- 한 순간에 하나의 Thread만 실행 가능
각 구조와 특징을 간략히 알아봤습니다.
또한, Thread는 하나의 실행 단위이며, 독립적인 작업을 수행해야 하므로 각각 Stack과 register 값(PC)을 갖고 있습니다.
그렇다면, Stack과 PC(resgister)의 어떤 기능이 독립적인 작업 수행을 돕는지 알아야겠네요.
PC (Register)
프로그램 카운터(Program counter, PC)는 마이크로프로세서(중앙 처리 장치) 내부에 있는 레지스터 중의 하나로서, 다음에 실행될 명령어의 주소를 가지고 있어 실행할 기계어 코드의 위치를 지정한다. 때문에 명령어 포인터라고도 한다. (wiki)
Stack
Stack은 익히 알고 있는 LIFO 구조의 스택을 의미합니다. 스택은 내부적으로 함수를 저장해 두었다가 호출 시 빼내는 용도로 사용됩니다.
즉, 함수 내 필드 및 파라미터에 대한 정보를 저장하는 메모리 공간입니다.
자바 JVM의 stack area 또한 매개변수와 지역변수 등을 저장하는 역할을 하죠.
이렇게 Stack 메모리 공간을 독립적으로 갖도록 함으로써 Thread는 자체적으로 함수를 호출(실행)할 수 있게 됩니다.또한 PC를 통해 명령어가 어디까지 실행되어있는지 지속적으로 체크하고 다음 명령을 수행하며 진행되겠죠.
Thread/Process는 차이점이 존재했지만 사실상 포함관계였습니다. (물론 명확하게 구분해 두시는 것이 좋습니다.)
여러 개의 Thread/Process 환경 Multi-Thread, Multi-Process도 비슷한 특징을 가질지 알아보겠습니다.
Multi-Process, context-switching
Multi-process
여러 개의 Process가 하나의 메모리를 공유하고 각 Process가 하나의 작업을 처리하도록 운영하는 것.
장점
각 프로세스는 독립적이므로 Process 하나에 문제가 생겨도 전체 Process 작동엔 문제없음.
단점
여러개의 process가 필요하므로 그만큼 많은 자원이 필요.
Multi-Process는 각 프로세스가 독립적으로 그리고 동시에 진행됩니다.
즉, 병렬(Concurrency)로 진행됩니다.
당연하게도 A 작업처럼 완료된 경우엔 이후에 제외하고 진행합니다.
추가로 스케줄링을 통해 Multi-processing 없이 context-switching을 통해 여러 프로세스를 동작시키는 방법도 존재합니다.
대략적으로 그려보면 아래와 같습니다.
그림 3. context-switching 여기서 Context-switching 이란, 현재 진행하는 작업의 상태를 저장하고 다음 작업을 읽어와 적용하는 과정입니다.
작업의 상태는 아래와 같은 정보와 함께 Register에 저장되어 PCB로 관리됩니다.
그림 4. PCB 구조 도식화 Context-switching이 무엇인지 어떻게 동작하는지는 알았는데, 왜 overhead가 발생할까요?
그림 3의 B -> C로 전환되는 부분에 interrupt 발생 및 process state 전환이 보입니다.
물론, 각 process의 전환 과정에 모두 공통적으로 포함되는 사항입니다.
이를 조금 풀어서 써보면 아래와 같습니다.
- Process B의 작동이 멈추고 Process C의 작동이 진행됩니다.
- 즉, Process B는 running -> ready, Process C는 ready -> running으로 변경되는 것을 의미합니다.
- 위의 과정들이 process 상태가 전환되는 과정이며
- process 전환을 하기 위해선 interrupt 요청이 들어와야 합니다.
- 물론 I/O event에 의한 context switching도 있으며, 이때도 PCB는 필요하겠죠.
- 5의 상태 전이는 running -> wait 입니다.
Context-switching은 위와 같이 interrupt 요청, 이후 상태 전환 그리고 PCB를 통해 프로세스에 대한 정보들을 저장해야 합니다.
위 목록의 4번에 이어 문맥 교환을 조금 더 자세히 보겠습니다.
- PCB에는 현재 진행 중이었던 Process B의 정보가 저장되어있습니다.
- Process C로 전환하기 위해 PCB(register)에 C의 정보를 저장합니다.
- CPU register 교체
- 그런데, B의 정보도 이후에 Process B 동작을 위해 사용될 수 있습니다. (그림 3의 끝부분)
- 따라서 PCB를 양도한 후 B의 정보는 메모리(cache)에 저장합니다.
Context-switching은 이렇게 다양한 과정들과 정보 교환이 연속적으로 이뤄지기 때문에 overhead가 발생합니다.
Multi-Thread
하나의 응용프로그램을 여러 개의 스레드로 구성하고 각 스레드가 하나의 작업을 처리 (병행성)
Multi-Process보단 Multi-Thread의 사용 사례가 많습니다.
(e.g. web server)
장점
Process를 생성해 자원을 할당할 필요 없으므로 System call의 감소 (자원의 효율성 증대)
Thread 사이 작업량이 적어 문맥 교환이 빠른 편 (thread 간 자원 공유)
단점
디버깅이 어려움 (Thread scheduling 불가)
공유 자원 문제 발생
Thread는 한순간에 하나의 thread만 작동 가능하기 때문에 번갈아가며 동작하겠죠.
그럼에도 불구하고 왜 Multi-Thread를 주로 사용할까요.
Multi-Thread가 주로 사용되는 이유
Thread는 Stack과 register에 대한 정보를 갖고, 그 외 Process에 포함된 Data/Code/Heap을 공유합니다.
따라서, Multi-Process 환경에서 문맥 교환은 보셨다시피 PCB, CPU, 메모리 등 정보 교환에 많은 비용이 발생합니다.
하지만, Multi-Thread 환경에서도 TCB라는 것이 존재하나 Stack의 정보만 주고받으면 되므로 훨씬 간단합니다.
해야 할 작업이 적으니 Process보다 Thread의 문맥 교환 속도도 더 빠르겠죠.
이렇게 잘 유의해서 구성한다면, Process보다 공간/시간적으로 상당히 이점이 있기 때문입니다.
물론 공유 자원에 대한 동기화 작업을 제대로 하지 않으면 충돌이 발생할 수 있습니다. 잘못된 결과를 얻거나..
Process scheduling/state 등의 내용도 필요할 테니.. 조만간 정리하겠습니다.
매번 정리를 하면 새로운 것을 알게 되고 막연했던 것들이 하나씩 스며드는 것 같아 기분이 좋네요.
사실 약간의 내용 보충을 더 하고 싶지만 일단락하겠습니다. ㅎㅎ..
참고 자료
반응형'CS > OS' 카테고리의 다른 글
Process Memory Area (0) 2021.05.27 Multi Threaded Programming (0) 2021.02.18 Process State & Scheduling (0) 2021.01.31