[Interview] - 프로세스(Process)/쓰레드(Thread) (업데이트)

uHan2·2021년 4월 20일
0

Interview

목록 보기
5/5

비록 시작은 코딩일기지만, 그 끝은 창대하게
어엿한 개발자 블로그로 성장할 수 있도록.


Interview :: 프로세스(Process)/쓰레드(Thread)

프로세스(Process)/쓰레드(Thread) 의 기본적인 내용을 간단히 정리해보자


Process

Process 란 쉽게 말해 컴퓨터에서 계속 실행되고 있는 프로그램이다. 정확히 말하면 메모리에 적재되어 실행되고 있는 프로그램의 인스턴스이며 OS 로부터 자원 을 할당받는 작업의 단위이다.

할당 받는 자원

  • CPU 제어권
  • Code, Data, Stack, Heap의 구조로 되어 있는 독립된 메모리 영역
  • 운영에 필요한 주소 공간
  • 기타 필요한 파일

OS 로 부터 자원을 할당 받으면 다음과 같은 그림으로 표현 가능하다.

각각의 Process 는 메모리 영역(Code, Data, Stack, Heap) 을 독립적으로 갖게 된다.
기본적으로 Process 당 최소 한 개의 Thread(Main Thread) 를 갖는다.
각각의 Process 자체도 별도의 주소 공간에서 실행되며, 다른 Process 의 변수나 자료구조에 접근할 수 없다. 접근을 위해서는 Process 간의 통신 (IPC, Inter Process Communication) 을 사용해야 한다.

PCB(Process Control Block)

Process 에는 PCB(Process Control Block) 라는 중요한 OS의 자료구조가 있다.
OSProcess를 관리하기 위해 Process의 생성과 동시에 고유한 PCB 를 생성한다. PCB 에는 특정 Process 에 대한 중요한 정보를 저장 하고있다.

PCBContext Switching 때문에 필요하다. Process 는 CPU를 할당받아 작업을 처리하다가도 Process 전환 (Context Switching) 이 발생하면 진행하던 작업을 저장하고 CPU를 반환해야 하는데, 이때 작업의 진행 상황을 모두 PCB 에 저장하게 된다. 그리고 다시 CPU를 할당받게 되면 PCB 에 저장 되어있던 내용을 불러와 이전에 종료됐던 시점부터 다시 작업을 수행한다.

PCB 에 저장되는 정보

  • 프로세스 식별자(Process ID, PID) : 프로세스 식별번호
  • 프로세스 상태 : new, ready, running, waiting, terminated 등의 상태를 저장
  • 프로그램 카운터 : 프로세스가 다음에 실행할 명령어의 주소
  • CPU 레지스터
  • CPU 스케쥴링 정보 : 프로세스의 우선순위, 스케줄 큐에 대한 포인터 등
  • 메모리 관리 정보 : 페이지 테이블 또는 세그먼트 테이블 등과 같은 정보를 포함
  • 입출력 상태 정보 : 프로세스에 할당된 입출력 장치들과 열린 파일 목록
  • 어카운팅 정보 : 사용된 CPU 시간, 시간제한, 계정번호 등

Context Switching

앞서 언급한 Context SwitchingCPU 에서 여러 Process 를 돌아가면서 작업을 처리하는 과정을 의미한다.
구체적으로, 동작 중인 process 가 대기를 하면서 해당 Process의 상태(Context)를 보관하고, 대기하고 있던 다음 순서의 Process가 동작하면서 이전에 보관했던 Process의 상태를 복구하는 작업을 말한다.


Thread

Thread 는 Process 내에서 실행되는 여러 흐름의 단위이다. Thread 는 Process가 OS로 부터 할당받은 자원을 이용한다.
앞서 살펴본 Process 그림에서 하나의 Process 를 자세히 보면 다음과 같다.

Thread 는 Process 내에서 각각 Stack과 Register를 독립적으로 할당받고 Code, Data, Heap 영역은 공유한다. 같은 Process 안의 Thread 끼리들은 주소 공간이나 Heap 공간과 같은 자원을 공유하면서 실행된다(Process 는 다른 Process 의 메모리에 직접 접근할 수 없다). 그리고 한 Thread가 Process의 자원을 변경하면, 다른 이웃 Thread(sibling Thread) 도 그 변경 결과를 즉시 볼 수 있다.

Java Thread

Java Thread 라고 해서 크게 다르진 않고 일반 Thraed와 거의 동일하다.
JVM이 OS의 역할을 한다.
Java에는 별도의 Process가 존재하지 않고 Thread 만 존재하며 JVM에 의해 스케줄되는 실행 단위 코드 블록이다. Thread가 몇 개 존재하는지, 프로그램 코드의 메모리 위치가 어디인지, 상태가 어떤지, 우선순위는 어떻게 되는지 등 Thread 와 관련된 많은 정보들 또한 JVM 이 관리한다.


Multi Process

Multi Process 는 말 그대로 하나의 Application을 여러 개(Multi)의 Process 로 구성하여 각각의 Process 로 하나의 Task를 처리하도록 하는 것이다.

Multi Process 로 구성하게 되면 여러 개의 자식 Process 중 하나에 문제가 발생했을 때 해당 Process 만 죽고 그 외의 다른 영향을 끼치지 않는 장점이 있다.

하지만, Context Switching 과정이 많아져 Overhead 가 발생하게 되고 Process 끼리는 IPC 를 사용하지 않으면 각각의 Process 사이의 변수를 공유할 수 없다는 단점이 있다.


Multi Thread

Multi Thread 또한 말 그대로 하나의 Applicatoin을 여러 개(Multi)의 Thread 로 구성하여 각각의 Thread 로 하나의 Task를 처리하도록 하는 것이다. Windows, Linux 등 많은 OS들이 Multi Process를 지원하고 있지만 Multi Thread를 기본으로 하고 있다. Web Server 가 대표적인 Multi Thread Application 이다.

Multi Thread 구성하게 되면 다음과 같은 장점이 있다.

  • 시스템 자원 소모 감소 (자원의 효율성 증대)
    • Process를 생성하여 자원을 할당하는 System Call 이 줄어들어 자원을 효율적으로 관리할 수 있다.
  • 시스템 처리량 증가 (처리 비용 감소)
    • Thread 간 Data를 주고 받는 것이 간단해지고 System 자원 소모가 줄어들게 된다.
    • Thread 사이의 작업량이 작아 Context Switching이 빠르다.
  • 간단한 통신 방법으로 인한 프로그램 응답 시간 단축
    • Thread는 Process 내의 Stack 영역을 제외한 모든 메모리를 공유하기 때문에 통신의 부담이 적다.

하지만 다음과 같은 단점이 있다.

  • 주의 깊은 설계가 필요하다.
  • 디버깅이 까다롭다.
  • Single Process 시스템의 경우 효과를 기대하기 어렵다.
  • 다른 Process에서 Thread를 제어할 수 없다. (즉, Process 밖에서 Thread 각각을 제어할 수 없다.)
  • Multi Thread의 경우 자원 공유의 문제가 발생한다. (동기화 문제)
  • 하나의 Thraed에 문제가 발생하면 전체 Process가 영향을 받는다.

Multi Process vs Multi Thread

둘 중 무엇이 더 우월하다 하긴 어려운 것 같다. (그래도 Multi Thread를 더 추천한다는 글을 많이 보긴 했다.)

이 두 가지는 동시에 여러 작업을 수행한다는 점에서 같지만 적용해야 하는 시스템에 따라 적합/부적합이 구분된다. 따라서 대상 시스템의 특징에 따라 적합한 동작 방식을 선택하고 적용해야 한다.


Reference

profile
For the 1% inspiration.

0개의 댓글