비선점 (No Preemption)

핵심 인사이트 (3줄 요약)

본질: 비선점 (No Preemption) 조건은 교착 상태(Deadlock)의 4대 필요조건 중 하나로, 한 프로세스가 자원을 스스로 해제(Release)하기 전까지는 다른 프로세스나 운영체제가 그 자원을 강제로 빼앗을 수 없는(Non-preemptible) 특성을 말한다.

가치: 비선점은 공유 자원의 변경(Update) 연산 도중 강제로 자원이 박탈될 경우 발생하는 데이터의 오염(Inconsistency)과 시스템 상태 손상을 방지하기 위해 필수적인 하드웨어 및 소프트웨어의 보호막 역할을 한다.

융합: 운영체제의 CPU 제어권(Preemptive Scheduling)이나 메모리(Swapping)는 강제 선점이 가능해 교착 상태에서 비교적 자유로우나, I/O 디바이스(프린터, 테이프)나 DB 커밋 중인 락(Record Lock)은 비선점 제약으로 인해 데드락 부정의 사각지대에 놓인다.

Ⅰ. 개요 및 필요성

강제 탈취(Preemption)가 가능하다면 경찰(OS)이 파워를 행사해 교통 체증 속에서 차량 하나를 크레인으로 치워버리고 얽힘을 뚫어줄 수 있다. 즉 데드락은 발생할 수 없다.

하지만, **비선점(No Preemption)**이 존재하기 때문에 데드락이 치명적 파괴력을 지닌다. 프로세스가 "내가 자발적으로 자원을 내려놓을(Release) 때까지" 건드릴 수 없으므로, 프로세스가 무한루프나 교착의 꼬리물기에 빠지는 순간 누구도 그 자원을 빼앗지 못하고 영구 마비가 찾아온다.

💡 비유: 운전 중인 자동차 핸들. 주행 중에 강제로 핸들을 뺏으면 차가 전복된다. 그래서 운전자가 차를 세우고 안전하게 내리기 전까지는 그 자리(운전대 자원)를 강제 선점할 수 없도록 강제된 보호 장치.

┌───────────────────────────────────────────────────────────────┐
│         선점 가능(Preemptible) vs 비선점(Non-preemptible) 자원│
├───────────────────────────────────────────────────────────────┤
│                                                               │
│  [선점 가능 자원 (Preemptible Resource)]                      │
│  ● 상태(Context) 저장 및 롤백이 쉬운 자원.                    │
│  ● CPU 시간 할당량 (타이머 인터럽트로 강제 스위칭).           │
│  ● 메인 메모리 프레임 (스왑 아웃 시키고 디스크 복원).         │
│  → OS가 강제 박탈(선점)해도 상관없음! 교착상태 유발 안 함.    │
│                                                               │
│  [비선점 자원 (Non-preemptible Resource) ★]                   │
│  ● 작업 도중 중단하면 복원할 수 없거나 오염되는 자원.         │
│  ● CD 레코더 (중간에 뺏으면 CD 에러남).                       │
│  ● 프린터 (절반만 출력 중 뺏으면 텍스트 뒤섞임).              │
│  ● 트랜잭션 진행 중인 DB Row Lock (갱신 무결성 파괴).         │
│  → 작업 종료(완성)까지 절대로 뺏을 수 없음! (교착상태 주적)   │
└───────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 비선점 자원은 그림을 그리고 있는 도화지 — 중간에 억지로 빼앗아버리면 그림이 엉망진창이 되기 때문에, 친구가 그림을 다 이룰 때까지 기다려야만 합니다. 그 기다림이 무한정 이어질 때 데드락 늪에 빠집니다.

Ⅱ. 아키텍처 및 핵심 원리

비선점 부정 (Prevention)의 논리와 한계

데드락을 막으려고 세 번째 조건인 비선점을 파괴(강제 박탈 도입)한다면 어떤 로직일까?

┌───────────────────────────────────────────────────────────────┐
│         비선점 부정 (Deadlock Prevention: Preemption 허용)    │
├───────────────────────────────────────────────────────────────┤
│                                                               │
│  요청 프로세스 A가 자원 R2를 원하는데,                        │
│  R2를 현재 점유하고 대기 중인 프로세스 B가 존재한다면?        │
│                                                               │
│  ■ 강탈 정책:                                                 │
│  "B! 너 아무것도 못하고 서 있을 거면 그 자원(R2) 당장 뱉어!"  │
│  → OS가 B로부터 강제로 R2 자원 수거 처리.                     │
│  → A에게 R2 할당 (스루풋 진행).                               │
│                                                               │
│  ■ 상태 보존의 지옥:                                          │
│  강제로 빼앗긴 B의 상태 복원은 누구 책임인가?                 │
│  B가 프린트 스풀을 절반 썼거나 DB 행을 업데이트 중이었으면?   │
│  → 강제 복원(Rollback/Restore) 캡슐화 비용 기하급수적 상승!   │
└───────────────────────────────────────────────────────────────┘

📢 섹션 요약 비유: 강제 뺏기(비선점 부정)는 요리 중인 냄비 압수하기 — 경찰이 와서 빈불을 뺏어가면 다음에 요리를 다시 시작해야 하는데, 이전에 넣은 소금 간(상태)이 다 깨져버려서 처음부터 다시 끓이는 게 더 골치 아파집니다.

Ⅲ. 융합 비교 및 다각도 분석

자원 종류	상태 되감기 비용	선점(Preemption) 여부	데드락 위협도
프로세서 (CPU)	PCB 문맥 저장 (초저비용)	예 (타임 슬라이스)	제로에 수렴
GPU 코어 스트림	일부 명령어 버퍼 오버헤드	VRAM 블록 단위	극히 적음
DBMS 파일/레코드	Rollback Log 추적의 고비용	락 타임아웃 외 불가	매우 큼 (격리성 필수)
뮤텍스 동기화 락	C++ 소멸자 및 락 오너 구조 파괴 불가	원칙적 완전 불가	데드락 알고리즘 주요 포커스

📢 섹션 요약 비유: 잃을 게 없는 CPU 자원과 달리, 엄청나게 복잡한 과정 중간인 DB 레코드 업데이트나 프린팅 엔진은 함부로 빼앗았다가는 그 동안 해온 작업 전체를 망가뜨리므로 비선점 제약이 가장 강력하게 강제됩니다.

Ⅳ. 실무 적용 및 기술사적 판단

실무 시나리오:

타임아웃(Timeout)을 통한 반(Semi)-선점 시뮬레이션: 개발자가 Lock.tryLock(5초) 메서드를 써서, 5초 안에 락을 못 얻으면 자기 함수 내부 로직(나머지 점유 자원)을 싹 초기화하고 Exception을 던진다. 남이 강제로 내 걸 뺏지는 않지만(비선점 보장), 스스로 락을 포기(자발적 Release)하게 유도하여 데드락 순환고리를 깬다. 자율적 백오프(Backoff) 패턴.
트랜잭션 Victim 강제 선정 (RDBMS): RDBMS 트랜잭션 매니저는 데드락 트리 탐지 시 가장 롤백 비용(이전 변경 레코드 수)이 적은 후보를 단숨에 쳐내어 Deadlock found when trying to get lock 에러를 주입, 희생양(Victim)을 만든다. DBMS 단의 롤백 능력이 있기에 과감히 비선점 조건을 찢어버릴 수단.

안티패턴:

사용자 입력 모듈(Blocking I/O)을 내포한 뮤텍스 구간: 유저가 키보드 입력을 줄 때까지 블로킹된 함수 호출은 다른 스레드가 뮤텍스 자원을 쓸어가지 못하게 비선점 락과 중대하게 스매싱되어 영원한 동면을 유발한다. "절대, 유저 응답을 락 안에서 대기하지 말라."

📢 섹션 요약 비유: 혼자 5분이나 요리할 때 자발적 포기(타임아웃)는 스스로 요리 세트 포기하고 뒷주방 가는 착한 규칙 — 아무도 내 냄비를 강제로 안 밀치니 기분 안 상하고 고착 상태만 없애줍니다.

Ⅴ. 기대효과 및 결론

접근 방식	"강제 자원 박탈" 수단 보유 (선점)	"자원 탈취 불가" (비선점 존중)
자원 무결성 보장	파괴 확률 높음 (어플리케이션이 롤백 부담)	시스템 레벨 완벽한 방어
데드락 회피	최고 솔루션 (OS가 언제든 끊음)	데드락 가능성을 다른 조건으로 방어해야 함
구현 난이도	롤백 로그 처리 오버헤드 폭발 (DBMS 급만 가능)	단순 명쾌 (수동 코딩에 접목 유리)

비선점 조건은 데드락을 완성하는 4인방 중, 시스템의 "데이터 무결성과 일관성"을 구원하기 위해 OS계가 눈물을 머금고 끌어안은 딜레마다. 강제로 빼앗아 치워버릴 수 없는 이 한계 때문에, 현대의 개발 공학은 타임아웃 롤백이나 락 순서(Lock Ordering)와 같은 우회 기법으로 교착 악몽에서 탈출해야만 한다.

📌 관련 개념 맵

개념	관계
시분할 스케줄링 (Time Sharing)	CPU의 초강력 강제 선점 구조. 데드락 멸균 환경
컨텍스트 스위칭 (Context Switching)	억지로 선점하기 위한 '상태 되감기' 기술. 지원 안 되는 자원은 비선점 유지 필수
롤백 (Rollback)	선점 당한 대상을 우아하게 예전 상태로 살려주기 위해 치르는 고비용 이면
기아 상태 (Starvation)	지속되는 양보(자발적 선점)가 누적될 때 터지는 또 다른 형태의 블로킹

👶 어린이를 위한 3줄 비유 설명

비선점은 "내 장난감을 내가 스스로 내려놓기 전엔 아무도 강제로 뺏어갈 수 없다!"는 강력한 룰이에요.
내가 쌓던 레고 성(작업 중간 상태)을 힘으로 확 뺏으면 엉망이 되니까 꼭 필요한 룰이지만,
저 친구도, 나도 서로 안 놓으려고 "내가 쥐고 있는 한 넌 못 가져" 하면서 버티다 보면 아무도 게임을 할 수 없는 영구 멈춤(데드락)이 찾아옵니다!