프로그램 창 하나가 멈췄다고 CPU 전체가 멈춘 것은 아니다. 실행 파일, 실행 중인 프로세스, 프로세스 안의 스레드와 운영체제의 스케줄링을 구분해야 어디에서 지연과 충돌이 생겼는지 찾을 수 있다.
한 프로세스 안의 두 스레드는 같은 자원을 공유할 수 있고, 스케줄러의 실행 순서에 따라 경쟁이 드러난다.
program process thread는 어떤 관계일까?
program은 저장된 명령과 데이터의 묶음이고, process는 그 프로그램이 실행되며 메모리와 운영체제 자원을 할당받은 상태다. 같은 프로그램을 두 번 실행하면 서로 다른 프로세스가 생길 수 있다.
thread는 프로세스 안에서 스케줄링되는 실행 흐름이다. 같은 프로세스의 스레드는 주소 공간과 일부 자원을 공유하므로 데이터를 주고받기 쉽지만, 동시에 같은 값을 수정하면 충돌할 수 있다.
| 단위 | 주로 구분되는 것 | 공유 가능성이 큰 것 |
|---|---|---|
| 프로세스 | 주소 공간, 자원과 보호 경계 | 파일·네트워크 등 명시적 통신 자원 |
| 스레드 | 실행 흐름, 스택과 레지스터 상태 | 프로세스의 코드·힙·열린 자원 |
정확한 자원 모델은 운영체제와 런타임마다 다르므로 “스레드는 무조건 가볍다”는 식으로 단정하지 않는다.
scheduling과 context switch는 무엇을 할까?
scheduling은 CPU 같은 자원을 어떤 작업에 어떤 순서로 배정할지 정하는 과정이다. 실행 가능한 작업이 CPU보다 많으면 운영체제는 일정한 정책에 따라 번갈아 실행한다.
context switch는 실행 중인 작업의 레지스터·실행 위치 같은 문맥을 저장하고 다른 작업의 문맥을 복원하는 전환이다. 전환에는 비용이 있으므로 스레드를 많이 만들었다고 처리량이 계속 증가하지는 않는다.
preemption은 실행 중인 작업이 스스로 양보하지 않아도 운영체제가 실행권을 회수할 수 있는 선점 방식이다. 우선순위와 시간 할당량은 응답성을 높일 수 있지만, 특정 작업이 오래 기회를 얻지 못하는 starvation도 고려해야 한다.
concurrency와 parallelism은 같은 말일까?
concurrency는 여러 작업이 겹치는 시간 동안 진행되도록 다루는 구조이고, parallelism은 여러 작업이 실제로 동시에 실행되는 상태다. 하나의 CPU 코어에서도 빠르게 전환하며 동시성을 만들 수 있지만 실제 병렬 실행은 아닐 수 있다.
공유 값을 두 스레드가 동시에 읽고 수정하면 실행 순서에 따라 결과가 달라지는 race condition이 생길 수 있다. 재현이 일정하지 않아 로그 한 번으로 정상이라고 결론 내리기 어렵다.
mutex semaphore deadlock은 어떻게 연결될까?
critical section은 동시에 실행하면 안 되는 공유 자원 접근 구간이다. mutex는 보통 한 실행 주체만 임계 구역에 들어가게 상호 배제하고, semaphore는 정해진 개수의 허용량으로 동시 접근을 제한한다.
여러 작업이 서로 가진 자원을 기다리며 진행하지 못하면 deadlock이다. 잠금 순서를 고정하고, 잠금 범위를 작게 유지하며, 실패 시 해제되는지 확인해야 한다. 동기화를 추가하면 정확성이 좋아질 수 있지만 대기와 경합 비용도 생긴다.
핵심 요약
프로그램은 저장된 코드, 프로세스는 실행 중인 자원 단위, 스레드는 프로세스 안의 실행 흐름이다. 스케줄러는 실행 순서를 정하고 문맥 교환으로 작업을 전환한다. 공유 상태에는 race condition이 생길 수 있으므로 mutex·semaphore 같은 동기화가 필요하지만, 잘못된 잠금은 deadlock과 성능 저하를 만든다.
