Process Lifecycle & PCB

1. Overview

프로세스 생애주기 및 PCB(Process Lifecycle & PCB, PLP)는 고정된 코드 덩어리인 '프로그램'이 어떻게 살아 움직이며 하드웨어 자원을 소비하는 '프로세스'로 승격되고 관리되는지에 대한 OS의 물리 행정 체계입니다.

하나의 컴퓨터에서 수백 개의 프로그램이 동시에 도는 환상은 OS가 각 프로그램을 짧은 시간 동안 번갈아 실행시키기 때문에 유지됩니다. 학습자는 프로세스가 생성(New)되어 준비(Ready), 실행(Running), 대기(Wait), 종료(Terminated)로 전이되는 물리적 상태 변화를 배웁니다. 또한, CPU가 다른 프로그램으로 눈을 돌릴 때 현재의 모든 '기억(레지스터, 스택)'을 담아두는 물리적 저장소인 **프로세스 제어 블록(Process Control Block, PCB)**의 구조를 심도 있게 다룹니다. 이를 통해 시스템이 어떻게 수많은 작업을 혼선 없이 '동물적'으로 관리하는지 그 하부 구조를 이해합니다.

2. Scope & Boundaries

In-Scope

• Process States: New, Ready, Running, Waiting, Terminated 전이 전개 물리
• PCB Internals: PID, PC, Register Save Area, Memory Limits, Open Files 정보의 물리적 배치
• Process Creation: fork, exec, spawn의 물리적 메모리 복제 및 덮어쓰기 로직
• Context Switch Physics: PCB 간의 레지스터 데이터 물리 교체 과정 및 오버헤드

Out-of-Scope

• 스레드(Thread) 간의 세부적인 공유 메모리 메커니즘 (03-02-02 노드에서 분담)
• CPU 스케줄링 알고리즘의 수리적 최적화 상세 (03-02-03 노드에서 분담)

Boundaries

• PLP vs. Thread: PLP가 '독립된 자원(메모리)을 가진 실행 단위'의 생성을 다룬다면, 스레드는 '자원을 공유하는 실행 흐름'에 집중하여 구분합니다.

3. Counterexample

• 단순히 "프로그램이 실행되는 것"을 PLP라고 정의하는 것은 부족합니다. 유저 모드에서 커널 모드로 바뀐다고 해서 반드시 **문맥 교환(Context Switch)**이 일어나는 것은 아님(시스템 콜은 같은 프로세스 맥락)을 물리적으로 증명할 수 있어야 하며, 왜 **좀비 프로세스(Zombie Process)**가 CPU 자원은 쓰지 않으면서도 커널의 PCB 슬롯이라는 유한한 물리 자원을 왜 낭비하게 되는지 설명하지 못한다면 PLP의 정수를 이해하지 못한 것입니다.

4. Prerequisites

• Bare-metal Memory Mapping (Basic): 텍스트, 데이터, 스택 영역의 하드웨어 배치 기초가 필수입니다. (02-05-01 BMM)
• Interrupts, Exceptions, and Trap Handling (Recommended): CPU 제어권 탈취 물리 이해가 권장됩니다. (03-01-03 IET)

5. Learning Map

1. The Sleeping Code: 하드디스크의 정적인 바이너리가 메모리로 불려오는 물리적 적재를 배웁니다.
2. Birth of a Ghost: 커널이 고유 번호(PID)를 부여하고 관리 장부(PCB)를 개설하는 과정을 익힙니다.
3. The State Machine: 준비 큐에서 기다리다 CPU를 점유하고, 다시 쫓겨나는 물리적 순환을 분석합니다.
4. Relay Race: 바통(PCB)을 넘기며 CPU를 번갈아 쓰는 문맥 교환의 물리적 지연을 완성합니다.

6. Learning Topics

Basic

Core: 프로세스의 정의와 메모리 구조 (Process Anatomy)

• Why to Learn: 프로그램이 실행될 때 메모리의 어느 공간에 무엇이 담기는지 알아야 디버깅과 최적화가 가능하기 때문입니다.
• What to Learn:
  • Text Section: 실행 코드가 담긴 읽기 전용 물리 공간
  • Data/BSS Section: 전역 변수와 정적 데이터의 물리적 배치
  • Heap & Stack Space: 런타임에 동적으로 자라나는 양방향 물리 영역
• How to Learn:
  • 간단한 C 코드를 컴파일하고 nm이나 objdump 도구를 써서 섹션별 물리 주소 분포 확인 실습
  • 재귀 함수 호출 시 스택 메모리가 물리적으로 어떻게 쌓이고 넘치는지(Overflow) 시각화
• Implement: 현재 실행 중인 내 프로그램의 텍스트, 데이터, 스택 시작 주소를 출력하는 코드

Recommended

Core: 프로세스 제어 블록과 문맥 저장 (PCB Mechanics)

• Why to Learn: 수만 번의 중단 속에서도 프로그램이 죽지 않고 이어질 수 있는 하드웨어 보관함이기 때문입니다.
• What to Learn:
  • Register State: EIP(RIP), ESP, 범용 레지스터의 물리적 덤프
  • Resource Ownership: 열려 있는 파일, 입출력 장치 정보의 커널 관리
  • Process ID (PID): 커널 장부에서 프로세스를 식별하는 물리적 키
• How to Learn:
  • 커널 소스(리눅스의 task_struct 등)에서 PCB를 구성하는 멤버 변수들의 역할 분석 실습
  • 디버거를 사용하여 프로세스 중단 시 레지스터 값이 PCB 영역으로 사상되는 물리 과정 추적
• Implement: 레지스터 세트와 상태 값을 담을 수 있는 최소한의 PCB 구조체 모델링

Practical

Core: 프로세스 생성과 소멸의 물리 (Creation & Termination)

• Why to Learn: 부모와 자식 프로세스가 자원을 어떻게 '물리적으로 복제'하고 나누는지 알아야 시스템 자원 고갈을 막을 수 있습니다.
• What to Learn:
  • Forking Mechanics: 부모의 주소 공간을 자식에게 복사하는 물리적 과정
  • Copy-on-Write (COW): 쓰기 전까지는 복사를 미뤄 물리 메모리를 아끼는 지능적 기법
  • Termination Cleanup: 프로세스 종료 시 점유하던 하드웨어 자원의 물리적 회수 시퀀스
• How to Learn:
  • fork() 직후 부모와 자식의 변수 주소값이 논리적으로는 같으나 물리적으로는 어떻게 분리되는지 검증 실습
  • 자식 프로세스가 종료되었으나 부모가 확인하지 않을 때(Zombie) 커널 메모리에 남는 자취 분석
• Implement: 자식 프로세스를 생성하고 종료 신호를 받아 자원을 완전히 해제하는 부모-자식 협력 코드

Advanced

Core: 문맥 교환 오버헤드와 물리 최적화 (Context Switch Physics)

• Why to Learn: 시스템 성능의 주범인 '의미 없는 CPU 낭비'를 수치로 환산하고 줄이기 위함입니다.
• What to Learn:
  • Switch Pipeline Stall: 문맥 교환 시 CPU 파이프라인이 멈추는 물리적 타격
  • TLB Flush Cost: 주소 공간이 바뀌며 하드웨어 주소 변환 캐시가 초기화되는 비용
  • Hardware Acceleration: 하드웨어가 문맥 교환을 직접 도와주는 특수 명령어 연동
• How to Learn:
  • 프로세스 개수를 늘려가며 시스템 전체의 'Context Switch/sec' 수치와 실제 유효 연산율의 물리적 상관관계 도출 실습
  • 사용자 모드와 커널 모드 진입 시의 캐시 히트율 변화 수리적 분석
• Implement: 두 프로세스가 서로 의미 없는 데이터를 주고받으며(Ping-pong) 발생하는 문맥 교환 지연 시간을 측정하는 벤치마크 툴

7. Terminology

8. References

Primary

• [P2] SWEBOK v4.0 - Software Construction / Runtime Efficiency (Execution) — Performance context.
• [P1] CS2023 - OS/Operating System Principles (Processes) — Core requirements.

Secondary

• [Operating Systems: Three Easy Pieces] Remzi — The virtualization of the CPU.
• [Understanding the Linux Kernel] Bovet & Cesati — task_struct internal details.

Industry

• [Linux Manual: fork(2) & execve(2)] — System call implementation rules.
• [Microsoft: Process and Thread Internals (Windows Sysinternals)] — Windows process structure.

9. Final Checklist

Primary

• '프로그램'과 '프로세스'의 물리적 차이점(정적 상태 vs 동적 자원 점유 상태)을 명확히 설명 가능한가? (P1)
• 프로세스가 'Running'에서 'Waiting'으로 전이되는 트리거가 왜 주로 'I/O 요청이나 이벤트 대기'인지 물리적 필연성을 입증할 수 있는 가? (P1)

Secondary

• '문맥 교환' 과정에서 왜 CPU의 캐시 메모리 오염(Cache Pollution)이 발생하여 시스템이 잠시 느려지는지 소통 가능한가?
• fork() 시스템 콜이 실행되는 동안 커널 내부에서 발생하는 '메모리 페이지 맵 복제' 과정을 가시적으로 도출할 수 있는 가?

Industry

• 대규모 서버 설계 시, 과도한 프로세스 생성(Forking)이 왜 커널 스케줄러의 부하를 물리적으로 높여 서비스 지연을 초래하는지 제안할 수 있는 가? (SFIA)
• '좀비 프로세스'가 너무 많아질 때, 커널이 더 이상 새로운 프로세스를 만들지 못하는 물리적 한계점(PID exhaustion)을 기술할 수 있는 가?