XNU 커널과 GCD·Swift Concurrency Who actually makes the kernel thread?

한 문장으로: 당신은 “작업(Task/block)”을 제출하고, libdispatch는 “스레드 달라”고 커널에 요청하며, 실제 커널 스레드를 만들고 재사용하는 결정권자는 XNU의 workqueue 매니저다. 개발자→libdispatch→커널의 세 층이 각각 무엇을 책임지는지가 이 부록의 뼈대다.

8.3XNU의 이중 구조 — BSD proc + Mach task/thread ⊕ 확장

macOS·iOS의 커널 XNU(“X is Not Unix”)는 두 혈통의 합성이다: 최하층의 Mach 마이크로커널(태스크·스레드·가상 메모리·IPC 담당)과 그 위의 BSD 층(POSIX API·프로세스 개념·파일 시스템·시그널 담당). 그래서 하나의 “프로세스”·“스레드”가 두 개의 구조체로 이중 표현된다.

핵심은 Mach task는 자원 컨테이너일 뿐, CPU에 올라가는 것은 언제나 Mach thread라는 점이다. 이는 4장 §1의 “프로세스는 자원, 스레드는 실행 흐름” 구분이 커널 구조에 그대로 박제된 형태다.

8.4pthread_workqueue — GCD는 커널에 스레드를 “요청”만 한다 ⊕ 확장

4장 §5.4는 GCD를 큐·QoS·main queue 같은 API 표면에서 다뤘다. 그 아래에서 실제 스레드는 누가 만드는가? 답의 핵심은: libdispatch(사용자 공간)는 pthread_create를 직접 부르지 않는다. 대신 커널의 workqueue 서브시스템에게 일꾼 스레드를 요청하고, 생성 여부는 커널이 결정한다.

※ 아래 등장하는 함수들은 공개 API가 아니라 SPI(System Programming Interface — 애플 내부/시스템 라이브러리 전용 비공개 인터페이스로, 앱에서 직접 호출하면 심사에서 거부된다)다. 여기서는 “libdispatch가 커널과 어떻게 대화하는가”를 보여주는 개념 예시로만 쓴다.

/* (1) 부팅 시 딱 한 번: "워커 스레드의 진입점은 이 함수다" 라고 커널에 등록 */
pthread_workqueue_setdispatch_np(_dispatch_worker_thread);
/*     ↑ 실제 생성이 아니라 '콜백 등록'일 뿐 */

/* (2) 큐에 일이 쌓였고 처리할 스레드가 부족할 때: "N개 더 줘" 라고 요청 */
pthread_workqueue_addthreads_np(priority, /*numthreads=*/1);
/*     ↑ 이 호출은 syscall로 커널에 내려가고,
         실제 pthread(=Mach thread) 생성은 커널의 workqueue 매니저가 수행 */

과거 pthread는 개별 작업 항목을 커널에 넘기는 _np API(additem류)로 스케줄링까지 관여할 수 있었지만, 현대 XNU에서는 그 권한이 커널로 이동했다. libdispatch는 “스레드 몇 개 필요”만 말하고, 어떤 작업을 어느 스레드에 태울지·몇 개를 실제로 만들지는 커널이 시스템 전체 관점에서 정한다.

8.4.1 DispatchQueue.global().async 한 줄의 전체 경로

8.4.2 Overcommit — 코어 수를 넘겨 만들 때

일반(non-overcommit) 글로벌 큐에서 커널은 대략 “동시에 실행 가능한 워커 수 ≒ 활성 코어 수”를 상한으로 삼는다 — CPU를 실제로 쓰는 작업이라면 코어보다 많은 스레드는 문맥 교환 낭비이기 때문이다. 그런데 워커가 블로킹 시스템 콜(디스크 I/O, 락 대기)에 걸리면 그 스레드는 CPU를 안 쓰면서 자리를 차지한다. 이때 다른 작업이 굶지 않도록 커널은 overcommit 정책으로 코어 수를 넘겨 새 워커를 만든다.

8.4.3 왜 이렇게까지 — 큐잉 15명령 vs 스레드 생성 수백 명령

GCD로 작업 하나를 큐에 넣는 데는 원자적 큐 삽입 약 15개 명령이면 충분한 반면, 전통적 pthread_create는 커널 진입 + 스택 매핑 + 자료구조 할당으로 수백 개 명령이 든다. 그래서 GCD의 규칙은 “스레드를 만들지 말고 작업을 제출하라”이며, 만들어진 KT는 커널이 캐싱해 재사용한다 — 매번 새로 만드는 Thread{}(§8 본문의 NSThread 안티패턴)와 정반대다.

8.5Clutch 스케줄러 — QoS를 실제 실행 순서로 바꾸는 곳 ⊕ 확장

커널이 워커 스레드를 만들었다면, 어느 스레드를 먼저, 그리고 어떤 코어에 올릴지는 스케줄러가 정한다. 현대 XNU는 Clutch 스케줄러를 쓰는데, 이는 애플의 비대칭 멀티코어(AMP)를 잘 다루려고 다듬어진 설계다(§8.5.1). 4장 §5.4에서 개발자가 지정한 QoS(.userInteractive … .background)가 여기서 실제 우선순위로 번역된다.

Clutch의 발상: 개별 스레드가 아니라 스레드 그룹(같은 목적으로 협력하는 스레드들, 예컨대 한 앱의 한 QoS 대역)을 스케줄 단위로 본다. 그리고 각 그룹에 interactivity score를 매긴다.

interactivity_score ∝  자발적 블로킹 시간(voluntary blocking)
                       ───────────────────────────────────────
                              CPU 사용 시간(CPU usage)

· 자주 자발적으로 블록(입력·네트워크 대기) → 점수 높음 → "상호작용형"
· CPU만 오래 태움(계산·디코딩)           → 점수 낮음 → "배치형"

효과: 별도 설정 없이도 “터치에 반응하는 스레드”가 “백그라운드 계산 스레드”보다 자연스럽게 우선한다. 예컨대 이미지 라이브러리가 다운로드·디코딩(CPU 집약, 낮은 interactivity)을 도는 동안에도 메인 스레드의 UI 갱신(높은 interactivity)이 부드럽게 끼어드는 이유가 이 설계다 — QoS는 “의도”만 표현하고, 실제 반응성은 커널이 실측 행동으로 보정한다.

8.5.1 AMP — 왜 비대칭 코어가 Clutch를 부르나 ⊕ 확장

4장 §2.3의 멀티코어는 대칭(SMP)이었다 — 코어가 전부 같아, 스케줄러는 “어느 코어든” 올리면 됐다. 그러나 애플 실리콘·모바일 SoC는 비대칭 멀티코어(AMP, asymmetric multiprocessing)다: 성능은 높지만 전력을 많이 먹는 P코어(Performance)와, 느리지만 전력 효율이 좋은 E코어(Efficiency)가 섞여 있다(ARM big.LITTLE의 계보). 그래서 스케줄러에 새로운 질문이 생긴다 — “먼저 실행할까”뿐 아니라 “어느 종류의 코어에 올릴까?”

이제 8.5의 interactivity score가 왜 중요한지가 분명해진다: 대칭 코어라면 “순서”만 정하면 되지만, 비대칭 코어에서는 “어느 코어”까지 정해야 하고, 그 판단 기준이 그룹의 상호작용성이다. 상호작용형(UI·입력)은 P코어로 올려 지연을 줄이고, 배치형(디코딩·동기화)은 E코어로 밀어 배터리를 아낀다. 반응성과 전력을 동시에 잡는 이 균형이 모바일에서 특히 중요하다.

8.6Turnstile — 우선순위 역전을 막는 다단계 전파 ⊕ 확장

QoS가 있으면 새 문제가 생긴다: 우선순위 역전(priority inversion). 높은 QoS 스레드가, 낮은 QoS 스레드가 쥐고 있는 락을 기다리는데, 그 낮은 스레드가 CPU를 못 받아 락을 못 놓으면 → 높은 스레드도 무한정 대기한다.

XNU의 turnstile이 이를 우선순위 상속(priority inheritance)으로 푼다: 대기 중인 스레드의 우선순위를 락 보유자에게 임시로 전파(propagate)한다. T_low가 잠깐 T_high의 우선순위로 승격 → 빨리 실행해 락을 놓음 → T_high가 즉시 진행. 이를 위해 커널 스레드는 우선순위 큐를 둘 유지한다.

struct thread {
    int  base_pri;   /* Base priority  — 당신이 지정한 QoS가 번역된 값 */
    int  sched_pri;  /* Scheduled priority — turnstile 부스트 등이 반영된 '실제' 실행 우선순위 */
    ...
    priority_queue  base_inheritor_queue;   /* 유저측 상속(예: 우선순위 지정 SPI) */
    priority_queue  sched_inheritor_queue;  /* 커널측 상속(turnstile 부스트) */
};
/* 두 값이 다를 수 있다:  base_pri = utility(낮음),  sched_pri = userInteractive(임시 부스트) */

8.6.1 Multi-hop — GCD가 특히 필요로 하는 것

GCD에서는 대기 사슬이 한 단계로 끝나지 않는다. 예를 들어 DispatchQueue.main.sync { … }로 메인 스레드가 어떤 큐를 기다리는데, 그 큐의 블록이 실행되려면 새 워커 스레드 생성이 끝나야 하고, 그 생성은 또 다른 스레드가 담당한다. Turnstile은 이 사슬을 따라 우선순위를 여러 단계로 연쇄 전파한다.

8.7Swift Concurrency의 Task ↔ 커널 스레드 — 근본적 비대칭 ⊕ 확장

지금까지가 커널 스레드(무거운 것)의 이야기였다. Swift Concurrency의 Task는 그 위에 얹힌 가벼운 것이며, 둘의 관계는 1:1이 아니다. 이것이 4장 §9(goroutine·virtual thread·async/await)에서 본 M:N 부활의 애플 판본이다.

핵심은 await의 의미다. Task가 await를 만나 대기 상태가 되면, 그 Task는 실행 중이던 커널 스레드를 붙잡은 채 잠들지 않는다 — 상태를 힙의 async frame에 저장하고 스레드를 양보한다. 그 KT는 즉시 다른 Task를 실행한다. 대기가 풀리면 Task는 아무 유휴 KT에서나 재개된다(재개된 스레드가 이전과 다를 수 있다).

이 부록은 스레드와 Task의 관계까지만 다룬다. actor가 어떻게 데이터 레이스(4장 §6)를 컴파일 타임에 막는지, Sendable·구조적 동시성·MainActor의 실전 적용은 별도 코스에서 이어진다.

8.83-way 비교 — Linux · Windows · macOS/iOS로 §8을 닫는다 ⊕ 확장

8.9 용어 사전 ⊕ 확장

이 부록의 XNU·애플 특화 용어를 한자리에 모았다(스레드 일반 용어는 본문 §10.5 용어 사전 참조). 오른쪽 절 링크로 설명으로 이동한다.

① 커널 구조 (Mach · BSD)

② 스레드 생성 (GCD ↔ 커널)

③ 스케줄링 (Clutch · Turnstile)

④ Swift Concurrency