이전 포스팅에서 프로세스와 스레드 개념을 공유했습니다.
프로세스와 쓰레드를 이해했다면, 이제 CPU 가 어떻게 이들을 번갈아 실행하는 지에 대해서 정리해보고자 합니다.
먼저 컨텍스트는 말 그대로 "작업의 실행 상태 정보" 를 의미합니다.
CPU가 어떤 작업을 실행하려면 최소한 프로그램 카운터 (PC), CPU 레지스터 값,
스택 포인터, 메모리 맵 정보, 프로세스 상태 등이 필요한데, 이 모든 정보가
PCB(Process Control Block) 에 저장됩니다.
+------------------------+
| Process ID |
| Process State |
| Program Counter (PC) |
| CPU Registers |
| Memory Management Info |
| I/O Status Info |
+------------------------+
CPU 는 실행을 멈출 때 이 정보를 저장하고, 다시 실행할 때 복원합니다. 이 저장 & 복원 과정이 바로 컨텍스트 스위칭 입니다.
컨텍스트 스위칭은 타이머 인터럽트 (Time Slice 종료), I/O 요청 (Blocking),
우선순위 높은 프로세스 등장, 명시적 yield 등에서 발생합니다.
특히 I/O가 많은 애플리케이션은 컨텍스트 스위칭이 매우 자주 일어납니다.
컨텍스트 스위칭이 일어나는 과정을 예로 들어보면,
// 컨텍스트 스위칭 흐름도
Running (A)
↓ (Interrupt)
Save A State
↓
Scheduler Select B
↓
Restore B State
↓
Running (B)
CPU 는 실제로 동시에 실행하는 것이 아니라 아주 빠르게 번갈아 실행하는 것입니다.
겉보기엔 단순해 보이지만, 실제로는 꽤 비쌉니다.
첫 번째, 레지스터 저장/복원 비용 (CPU 내부 상태를 전부 메모리에 쓰고 다시 읽음)
두 번째, 캐시 오염 (이전 작업의 캐시 데이터가 무효화 됨)
세 번째, TLB flush (프로세스가 바뀌면 메모리 매핑 정보가 달라짐)
네 번째, 커널 모드 전환 (유저 모드와 커널 모드 전환 비용 발생)
// 캐시 영향 시각화
Before Switching:
[Cache] → A의 데이터로 가득 참
After Switching:
[Cache] → B 실행 → A 데이터 무효화
그래서 컨텍스트 스위칭은 단순한 함수 호출이 아니고, CPU 파이프라인과 캐시까지 영향을 줍니다.
컨텍스트 스위칭을 줄이기 위해 실무에서 고려할 수 있는 건, 불필요한 쓰레드 생성을 줄이고 비동기 I/O 활용, 쓰레드 풀 사용, 락 최소화, CPU bound 작업 분리 등이 있습니다. 특히 서버 환경에서는 스위칭 비용이 곧 성능 비용이 됩니다.
프로세스 스위칭과 쓰레드 스위칭은 비용 차이가 있습니다.
프로세스 스위칭은 주소 공간이 변경되고, TLB flush 등이 발생하기 때문에 비용이 높습니다.
반면 스레드 스위칭은 같은 프로세스 내에서 일어나므로 주소 공간이 유지되고,
TLB flush 가 보통 발생하지 않아서 상대적으로 비용이 낮습니다.
핵심적으로 프로세스는 메모리 공간 자체가 다르고, 쓰레드는 같은 메모리를 공유하기 때문에 쓰레드 기반 모델이 더 가볍습니다. 하지만 쓰레드는 동기화 비용이 있어서, 프로세스는 격리 비용, 쓰레드는 동기화 비용으로 서로 다른 트레이드오프를 가집니다.
겉으로 보이기엔 여러 작업이 동시에 실행되는 것처럼 보이지만, 실제로 CPU는 한 순간에 하나만 실행합니다. (대신 엄청 빠르게 교체)
// 타임 슬라이스 개념
| A | B | C | A | B | C | A | ...
CPU가 타임 슬라이스 단위로 쪼개서 실행하는데, 이것이 동시성의 본질입니다.
"컨텍스트 스위칭은 CPU가 작업을 교체하기 위해 상태를 저장하고 복원하는 과정" 입니다.
그리고 이 과정은 공짜가 아닙니다.
프로세스 스위칭은 비싸고, 쓰레드 스위칭은 상대적으로 가볍습니다.
하지만 많아지면 결국 성능을 갉아먹습니다.
동시성은 공짜가 아니기 떄문에,
컨텍스트 스위칭 비용을 이해하는 것이 진짜 성능 최적화의 시작입니다.