Ready, running, blocked — và giá của context switch

TL;DR: Một thread không phải lúc nào cũng chạy. Nó luân phiên qua ba trạng thái: running (đang chiếm một CPU core), ready (sẵn sàng chạy nhưng đang chờ tới lượt vì core bận), và blocked (đang chờ một sự kiện — thường là I/O — nên tạm thời không cần CPU). Điểm quan trọng nhất: thread blocked không tốn CPU — kernel lấy nó ra khỏi core và cho thread khác chạy, đó là lý do một server có thể phục vụ hàng nghìn kết nối đang chờ mạng chỉ với vài core. Mỗi lần đổi thread trên một core là một context switch: kernel lưu register của thread cũ, nạp register của thread mới. Chi phí trực tiếp (lưu/khôi phục register) chỉ vài µs, nhưng chi phí gián tiếp thường lớn hơn: thread mới bắt đầu với cache lạnh và TLB có thể vừa bị flush, nên vài chục nghìn lần truy cập bộ nhớ đầu tiên chậm hơn bình thường.

Bạn chạy một service, và khi soi bằng vmstat 1, cột cs (context switches per second) báo 80.000. Bạn nghĩ "app mình có mấy chục thread thôi mà, sao đổi tới 80.000 lần mỗi giây?". Rồi bạn nhận ra: mỗi context switch tốn vài µs trực tiếp, cộng thêm phần cache và TLB nguội đi sau đó. 80.000 lần một giây, mỗi lần vài µs, là hàng trăm mili-giây CPU mỗi giây chỉ để đổi việc — chưa làm được việc gì có ích. Đây là chi phí ẩn mà người ta hay quên khi thấy app chậm và phản xạ "thêm thread đi".

Bài này trả lời hai câu: một thread đi qua những trạng thái nào và vì sao chờ I/O không đốt CPU; và mỗi lần đổi thread trên một core thật sự tốn những gì — không chỉ lưu register, mà cả cache nóng và TLB bạn đã học ở khoá Bộ nhớ. Học xong, bạn Trace được vòng đời một thread qua ready/running/blocked và định giá được cái mất thật của mỗi lần chuyển context.

1. Analogy — bếp ăn một lò

Hình dung một bếp ăn chỉ có một lò (một CPU core) và nhiều đầu bếp (thread) cùng muốn nấu.

• Đầu bếp đang đứng ở lò xào là running — chiếm lò, đang làm việc thật.
• Đầu bếp đã sẵn nguyên liệu, đứng xếp hàng chờ lò trống là ready — làm được ngay nếu tới lượt, chỉ thiếu chỗ.
• Đầu bếp đã đặt ship nguyên liệu và đang chờ shipper giao là blocked — chưa làm gì được cho tới khi hàng tới, nên nhường lò cho người khác thay vì đứng ì chiếm chỗ.

Điểm hay của bếp thông minh: khi một đầu bếp phải chờ shipper (blocked), quản lý bếp không để lò trống — kéo ngay một đầu bếp đang xếp hàng (ready) vào lò. Nhờ vậy một lò phục vụ được nhiều đầu bếp, miễn là ai cũng có lúc phải chờ ship. Đó chính là vì sao vài core chạy được hàng trăm thread I/O-bound.

Nhưng mỗi lần đổi người ở lò tốn công: người cũ phải cất dụng cụ, ghi lại đang nấu tới bước nào; người mới bày dụng cụ ra, đọc lại công thức. Đó là context switch — và cái tốn nhất không phải động tác cất/bày (register), mà là người mới phải "làm nóng" lại: nêm nếm lại, tìm lại đồ trong bếp (cache và TLB nguội).

2. Ba trạng thái và các chuyển tiếp

Một thread (và một tiến trình nói chung) luôn ở đúng một trong ba trạng thái, và di chuyển giữa chúng theo các chuyển tiếp có tên:

stateDiagram-v2
    [*] --> Ready: tao thread
    Ready --> Running: scheduler chon (dispatch)
    Running --> Ready: het time slice (preempt)
    Running --> Blocked: goi I/O / cho su kien
    Blocked --> Ready: I/O xong / su kien den
    Running --> [*]: ket thuc (exit)

Đọc từng chuyển tiếp:

• Ready → Running (dispatch): scheduler chọn một thread ready và trao nó một core. Đây là lúc một context switch xảy ra để nạp trạng thái thread được chọn.
• Running → Ready (preempt): thread đang chạy hết phần thời gian được cấp (time slice — bài 03), timer interrupt cướp CPU, thread bị đẩy về hàng ready dù nó vẫn muốn chạy tiếp. Nó không làm gì sai; chỉ là tới lượt người khác.
• Running → Blocked: thread tự nguyện rời CPU vì gọi một thao tác phải chờ — đọc file, chờ gói tin mạng, chờ một lock. Nó không thể tiến thêm cho tới khi sự kiện xảy ra, nên chờ trên core là vô nghĩa.
• Blocked → Ready: sự kiện thread chờ đã tới (dữ liệu I/O sẵn sàng, lock được nhả). Thread chưa chạy ngay — nó quay lại hàng ready và chờ scheduler chọn. Đây là chỗ nhiều người nhầm: I/O xong không có nghĩa là thread chạy tức thì.
• Running → Exit: thread hoàn thành, được thu dọn.

Chú ý: không có chuyển tiếp trực tiếp Blocked → Running. Một thread vừa được đánh thức luôn phải đi qua Ready trước — vì có thể mọi core đang bận với thread khác.

3. Vì sao blocked không tốn CPU?

Đây là ý quan trọng nhất của bài, và là nền cho bài 04 (chọn số thread).

Khi thread gọi một thao tác chờ, ví dụ đọc từ socket chưa có dữ liệu:

int n = socket.getInputStream().read(buffer);   // chua co du lieu -> BLOCK

Kernel không để thread "quay vòng chờ" (busy-wait) đốt CPU. Thay vào đó:

1. Kernel chuyển thread sang trạng thái blocked và lấy nó ra khỏi core.
2. Kernel ghi nhận: "khi dữ liệu tới trên socket này, đánh thức thread đó".
3. Scheduler chọn một thread ready khác và trao core cho nó. Core không hề rảnh — nó làm việc có ích cho thread khác.
4. Khi card mạng nhận dữ liệu, phần cứng phát một interrupt; kernel xử lý và chuyển thread từ blocked về ready. Tới lượt, nó chạy tiếp từ đúng dòng read().

Hệ quả trực tiếp: thời gian một thread nằm blocked không tính vào thời gian CPU của nó. Một server có 1.000 kết nối, phần lớn đang chờ mạng, chỉ cần vài core — vì tại mỗi thời điểm chỉ một nhúm thread thật sự cần CPU, số còn lại đang blocked, không tranh core. Đây chính là lý do workload I/O-bound hưởng lợi từ việc có nhiều thread hơn số core (bài 04 sẽ định lượng).

4. Context switch — phần trực tiếp

Mỗi lần một core chuyển từ thread này sang thread khác là một context switch. Phần "hiển nhiên" của nó là lưu và khôi phục trạng thái CPU:

1. Lưu context thread cũ: kernel chép toàn bộ register hiện tại (program counter, stack pointer, các register dữ liệu) vào cấu trúc mô tả thread cũ (trong kernel). Đây là ảnh chụp "thread cũ đang ở đâu" để sau này chạy tiếp đúng chỗ.
2. Chọn thread mới: scheduler quyết ai chạy tiếp (bài 03).
3. Khôi phục context thread mới: nạp register đã lưu của thread mới vào CPU. Nếu là process khác, còn phải đổi con trỏ trỏ tới bảng ánh xạ trang (page table) sang address space của process mới.
4. CPU tiếp tục thực thi thread mới từ đúng lệnh nó dừng lần trước.

Phần này — thuần lưu/nạp register và chuyển vào kernel rồi ra — rẻ về mặt trực tiếp: cỡ vài µs trên CPU hiện đại (biên độ, tuỳ kiến trúc và kernel; đo được bằng lmbench hay microbenchmark). Nếu context switch chỉ có phần này, 80.000 lần/giây cũng không quá đáng ngại.

Nhưng câu chuyện chưa hết. Chi phí thật nằm ở phần không nhìn thấy trong danh sách trên.

5. Chi phí gián tiếp — cache lạnh và TLB flush

Đây là phần nối thẳng về khoá Bộ nhớ, và là lý do context switch đắt hơn con số "vài µs" gợi ý.

Khi thread cũ chạy, nó đã "làm nóng" cache: dữ liệu và lệnh nó hay dùng nằm sẵn trong L1/L2/L3 (cache và độ trễ). Nó cũng đã nạp các ánh xạ địa chỉ ảo → vật lý vào TLB (MMU và TLB). Khi context switch sang thread mới:

• Cache trở nên "lạnh" với thread mới. Thread mới có bộ dữ liệu riêng, chưa nằm trong cache. Những lần truy cập đầu của nó là cache miss — mỗi miss xuống RAM tốn cả trăm ns thay vì vài ns. Và tệ hơn: thread mới chạy dần dần đẩy dữ liệu của thread cũ ra khỏi cache, nên khi thread cũ được chạy lại, nó cũng phải làm nóng cache từ đầu.
• TLB có thể bị flush. Nếu đổi sang một process khác (address space khác), các ánh xạ TLB của process cũ không còn đúng nữa. Nhiều kiến trúc phải xoá (flush) TLB, và thread mới phải nạp lại từng ánh xạ qua page walk (kernel/MMU dò bảng trang nhiều tầng để dịch địa chỉ) — mỗi lần vài chục ns cho tới khi TLB nóng lại.

Chi phí gián tiếp này không cố định — nó phụ thuộc working set (lượng dữ liệu nóng) của các thread. Với thread có working set lớn, việc làm nóng lại cache có thể tốn hàng chục µs, lớn hơn phần trực tiếp nhiều lần. Đây là lý do OSTEP nhấn mạnh rằng chi phí context switch không chỉ là lưu/khôi phục register, mà gồm cả "chi phí làm nguội cache và TLB" — và chính chi phí này khiến time slice không nên quá ngắn (bài 03).

flowchart LR
  A["Thread A chay<br/>cache + TLB nong cho A"] -->|context switch| B["Thread B chay<br/>cache lanh, TLB co the flush"]
  B -->|"B lam viec"| C["Cache dan nong cho B<br/>day du lieu cua A ra"]
  C -->|context switch| D["Thread A chay lai<br/>cache lai lanh cho A"]

Nói cách khác: mỗi context switch không chỉ "mất vài µs", mà còn để lại một cái đuôi — thread vừa vào chạy chậm hơn bình thường trong một quãng ngắn vì phải làm nóng lại cache/TLB. Càng switch nhiều, càng ít thời gian chạy ở tốc độ đầy đủ.

6. Vì sao đổi thread cùng process rẻ hơn đổi process?

Nhớ lại bài 01: thread cùng process chia sẻ address space. Điều này biến thành lợi thế cụ thể ở context switch.

Khi đổi giữa hai thread cùng process, page table không đổi, nên các ánh xạ trong TLB vẫn đúng — không cần flush. Cache dữ liệu cũng có thể còn dùng lại được phần nào vì hai thread chia sẻ heap. Khi đổi giữa hai process khác nhau, phải trỏ CPU sang page table mới, và (trên nhiều kiến trúc) flush TLB — thread mới nạp lại ánh xạ từ đầu.

7. Pitfall của riêng concept này

❌ Nhầm 1 — tưởng thread blocked vẫn đốt CPU:

✅ Thread blocked bị kernel lấy khỏi core; nó không tiêu CPU trong lúc chờ. Bằng chứng: mở top, chạy một chương trình đang sleep hay chờ mạng — cột CPU của nó gần 0. Chỉ khi bạn busy-wait (while (!ready) {}) thread mới vừa "chờ" vừa đốt 100% core. Blocking đúng cách nhường CPU; busy-wait thì không.

❌ Nhầm 2 — tưởng I/O xong là thread chạy lại ngay lập tức:

✅ Blocked → Running không có đường trực tiếp. Khi I/O xong, thread về ready và chờ scheduler chọn. Nếu các core đang bận, nó xếp hàng — độ trễ đánh thức (wakeup latency) là có thật và tăng khi hệ thống tải nặng. Đây là một nguồn latency đuôi (tail latency) mà người ta hay bỏ sót.

❌ Nhầm 3 — tưởng "thêm thật nhiều thread" luôn tăng thông lượng:

CPU-bound task, may 4 core:
  4 thread  -> 4 core chay full, it context switch
  400 thread -> van chi 4 core chay, nhung context switch tang vot
             -> phan lon thoi gian dot vao switch + lam nong lai cache

✅ Với workload CPU-bound, thêm thread quá số core chỉ làm tăng context switch — mỗi switch tốn trực tiếp + làm nguội cache — mà không thêm sức tính toán (vẫn 4 core). Thông lượng giảm. Bài 04 định lượng vì sao, và khi nào thêm thread mới thật sự giúp (I/O-bound).

8. 📚 Deep Dive

9. Liên hệ các bài khác

• Bài 01 — Thread vs process: vì thread cùng process chung address space, đổi giữa chúng không flush TLB — nền cho mục 6.
• Bài 03 — Scheduler và time slice: ai quyết chuyển tiếp Running → Ready, và vì sao time slice không nên quá ngắn (để chi phí context switch không nuốt hết thời gian có ích).
• Bài 04 — CPU-bound vs I/O-bound: dùng ý "blocked không tốn CPU" để giải thích vì sao I/O-bound nên nhiều thread còn CPU-bound thì không.
• Cache và độ trễ (khoá Bộ nhớ) và MMU và TLB: cơ chế cache miss và TLB flush — gốc của chi phí gián tiếp.

10. Tóm tắt

• Thread luôn ở một trong ba trạng thái: running (trên core), ready (chờ tới lượt), blocked (chờ sự kiện).
• Chuyển tiếp có tên: dispatch (ready→running), preempt (running→ready), block (running→blocked), wakeup (blocked→ready). Không có Blocked → Running trực tiếp.
• Blocked không tốn CPU: kernel lấy thread khỏi core và chạy thread khác; nền để hiểu I/O-bound scaling.
• Busy-wait (while quay vòng) thì vẫn running và đốt core — ngược với blocking đúng cách.
• Context switch trực tiếp (lưu/nạp register) cỡ vài µs; gián tiếp (cache lạnh, TLB flush) thường lớn hơn, có thể hàng chục µs tuỳ working set.
• Đổi thread cùng process rẻ hơn đổi process vì không đổi address space, không flush TLB (CPU tag PCID/ASID giảm nhẹ nhưng không xoá đòn này).
• Switch quá nhiều (nhiều thread hơn cần thiết) đốt CPU vào việc đổi việc thay vì làm việc.

11. Tự kiểm tra

Bài tiếp theo: Scheduler — ai được chạy tiếp theo