行程、執行緒與作業系統如何管理執行
本頁為依教材與考古題整理的原創摘要；考古題答案經技術覆核，但不是官方答案。
第一次接觸也沒關係
這堂先懂這些詞
先記住白話意思，不必急著背英文。看到正文時，再把正式名稱接回來。
上下文切換
也會看到：context switch、情境切換系統保存目前工作的執行狀態，再載入另一項工作的狀態。
- 生活例子：
- 像客服先記下 A 客戶談到哪，再打開 B 客戶紀錄接著處理。
- 別搞混：
- 切換本身有成本，頻繁切換不會免費增加效能。
行程間通訊
也會看到：IPC、inter-process communication、shared memory、message passing不同 process 透過訊息、管道或明確共享記憶體交換資料。
- 生活例子：
- 像不同店面透過電話傳話，或共同使用一塊有規則管理的公告板。
- 別搞混：
- 不同 process 預設不共用整個位址空間；共享記憶體也仍需同步。
行程與執行緒
也會看到：process、thread、行程、執行緒行程是有獨立資源的執行容器，執行緒是容器內可被排程的工作路線。
- 生活例子：
- 一間餐廳像一個行程，裡面的多位廚師像多條執行緒。
- 別搞混：
- 共享同一行程資源不代表執行緒彼此不會衝突。
排程器
也會看到：scheduler、CPU scheduler、排程演算法作業系統決定哪個可執行工作何時取得 CPU 的機制。
- 生活例子：
- 像診所叫號，依規則安排下一位看診者。
- 別搞混：
- 排程器不是工作自己決定何時執行，也不保證每個工作立刻執行。
系統呼叫與執行模式
也會看到：system call、user mode、kernel mode一般程式用 system call 請核心代辦需要較高權限的工作。
- 生活例子：
- 像住戶不能直接進機房，只能請管理員代為操作。
- 別搞混：
- 切到 kernel mode 不等於換成另一個行程，也不是應用程式永久取得最高權限。
從作業系統的資源管理角色出發，辨認 process 與 thread 的資源邊界，理解 user mode、kernel mode、IPC 與 context switch，並能排除考題中常見的混淆敘述。
先抓住這幾件事
- 說明作業系統在行程生命週期與資源管理中的責任。
- 比較 process 與 thread 的位址空間、執行狀態與溝通成本。
- 解釋 user mode、kernel mode 與 system call 的控制轉移。
- 依 context switch 的保存與恢復流程判斷系統成本。
先想像這個場景
一間忙碌的餐廳
把一個 process 想成一間有自己廚房、食材和設備的餐廳；同一間廚房裡可以有多位廚師同時工作，就像一個 process 裡有多條 threads。廚師共享廚房，所以傳遞材料很快，但兩個人同時改同一張訂單也可能互相覆蓋。
先別急著往下看，花十秒想一想：
兩位廚師都看得到同一張訂單，是否代表他們可以同時修改，而且一定不會出錯？
把故事換成電腦語言
| 生活中的角色 | 對應到 | 技術概念 |
|---|---|---|
| 各自獨立的餐廳與廚房 | 不同 processes 的受保護位址空間與資源 | |
| 同一間廚房裡的多位廚師 | 同一 process 裡共享 code、heap 與資源的 threads | |
| 每位廚師自己的工作小抄與手上進度 | 每條 thread 獨立的 stack、program counter 與 registers | |
| 分店之間透過電話或外送單傳話 | processes 透過 IPC 或明確 shared memory 交換資料 | |
| 暫停一位廚師，讓另一位接著工作 | 保存與恢復 execution state 的 context switch |
題目出現這些字，先想到
- 同一個 process、共享 code 與 heap：先想到 threads。
- 各自擁有 stack、program counter、registers：仍然是在描述每條 thread 的獨立狀態。
- 不同 processes 要交換資料：先找 pipe、message passing、socket 或 shared memory。
- system call 進入 kernel：一定有 mode switch，但不一定換了執行主體。
1.作業系統是資源管理者
作業系統（Operating System, OS）是管理電腦硬體和軟體資源、為使用者和應用程式提供服務的系統軟體。它的四大核心功能： (1) Process management（行程管理）— 建立、排程、同步、終止行程。決定哪個行程何時使用 CPU。 (2) Memory management（記憶體管理）— 追蹤哪些記憶體區域正在使用、分配和回收記憶體、虛擬記憶體管理。 (3) File system management（檔案系統管理）— 建立/刪除檔案和目錄、讀寫控制、空間管理。 (4) I/O management（輸入輸出管理）— 管理裝置驅動程式、緩衝、排程 I/O 請求。 【OS 的兩個角色】 • Resource manager：公平且高效地在多個程式之間分配 CPU 時間、記憶體空間、I/O 裝置等有限資源。 • Abstraction provider：隱藏硬體的複雜細節，提供簡單一致的介面（如「open file」而不是「移動磁碟臂到 track 37, sector 5」）。 【OS 的類型】 • Batch OS：一次執行一個工作，無互動。歷史上最早的形式。 • Time-sharing OS（多工 OS）：多個使用者/程式交替使用 CPU，每個獲得一小段時間（time slice），營造出同時執行的假象。 • Real-time OS（RTOS）：保證在特定時間限制內完成任務。分為 hard real-time（絕對不能超時，如飛行控制）和 soft real-time（允許偶爾超時，如影音播放）。 • Distributed OS：管理多台互聯電腦上的資源。 【考試連結】(1) OS 的四大功能是常考的列舉題。(2) 分辨 batch、time-sharing、real-time OS 的特徵。(3) Kernel 是 OS 的核心，常駐記憶體；Shell 是使用者介面（CLI 或 GUI），不要混淆。
- 行程管理包含建立、終止、暫停、恢復與同步行程。
- CPU scheduling 決定下一個可執行工作，但排程演算法細節屬另一子主題。
- deadlock handling 與 IPC 也是作業系統協調多個行程的重要工作。
- Android 使用 Linux kernel；Linux 是 Unix-like，但不能把整個 Unix 家族一概視為開源。
2.Process：正在執行的程式實例
Process（行程/進程）是一個正在執行的程式實例（a program in execution）。同一個程式可以產生多個 process（例如開三個瀏覽器視窗就是三個 process）。每個 process 有獨立的： (1) Address space（位址空間）— 包含 code（程式碼）、data（全域變數）、heap（動態配置記憶體）、stack（函式呼叫和區域變數）。 (2) PCB（Process Control Block）— OS 用來管理 process 的資料結構，包含 process ID（PID）、program counter、register values、process state、memory management info、I/O status、scheduling info。 【Process 的狀態轉換】 • New → Ready：process 被建立，等待 CPU。 • Ready → Running：scheduler 選中此 process，分配 CPU。 • Running → Ready：time slice 用完（preemption），回到等待佇列。 • Running → Waiting/Blocked：需要等待 I/O 完成或其他事件。 • Waiting → Ready：等待的事件完成（如 I/O done）。 • Running → Terminated：執行完畢或被終止。 【Process 建立】在 Unix 中，fork() 建立一個新 process（child），它是 parent process 的幾乎完整副本。exec() 把 child 的程式碼替換成新的程式。因此 Unix 中啟動新程式的典型方式是 fork() + exec()。在 Windows 中，CreateProcess() 同時完成建立和載入新程式。 【Inter-Process Communication（IPC）】Process 之間的 address space 是隔離的，無法直接存取彼此的記憶體。需要特殊的 IPC 機制：Shared memory（共享記憶體段）、Message passing（透過 OS 傳遞訊息）、Pipe（單向資料流）、Socket（跨機器通訊）。 【考試連結】(1) Process 的五個狀態和轉換條件。(2) PCB 包含什麼資訊。(3) fork() 和 exec() 的差異。(4) Process 和 Program 的差異 — Program 是靜態的指令集合，Process 是動態的執行實例。
- 同一個 program 可以同時產生多個彼此獨立的 processes。
- 每個 process 有自己的執行狀態與受保護的 virtual address space。
- 父子 processes 若要交換資料，需使用 pipe、message passing、socket 或明確設定的 shared memory。
- multiprocessing 可利用多核心平行執行，提高 throughput，但也增加協調成本。
3.Thread：共享資源的執行路徑
Thread（執行緒/線程）是 process 內的一條執行路徑。一個 process 可以包含多個 threads，它們共享 process 的 address space（code, data, heap, open files），但每個 thread 有自己的 stack、program counter、registers。 【Thread vs Process】 | | Process | Thread | | 建立成本 | 高（需配置獨立 address space） | 低（共享已有的 address space） | | 切換成本 | 高（需切換 address space） | 低（只需切換 stack 和 register） | | 資源共享 | 獨立（需 IPC） | 共享（直接存取相同的 heap/data） | | 隔離性 | 高（一個 crash 不影響其他） | 低（一個 thread crash 可能影響整個 process） | 【多執行緒的好處】 (1) Responsiveness — GUI 程式中，一個 thread 處理 UI，另一個 thread 做背景計算，UI 不會卡住。 (2) Resource sharing — 同一 process 的 threads 共享記憶體，通訊不需要 IPC 的 overhead。 (3) Scalability — 在多核 CPU 上，不同 threads 可以真正平行執行在不同 core 上。 【User-level vs Kernel-level Threads】 • User-level thread：由使用者空間的 thread library 管理，OS kernel 不知道它們的存在。優點是建立和切換快（不需要 system call）。缺點是一個 thread 做 blocking I/O 會阻塞整個 process。 • Kernel-level thread：由 OS kernel 管理和排程。一個 thread blocking 不影響其他 threads。現代 OS（Linux、Windows）主要使用 kernel-level threads。 【Thread safety 問題】多個 threads 共享記憶體帶來 race condition 風險 — 當多個 threads 同時讀寫共享資料，結果取決於執行順序，可能產生錯誤。需要 synchronization 機制（mutex、semaphore）來保護 critical section。 【考試連結】(1) Thread 和 process 的比較表。(2) Thread 共享什麼、不共享什麼（共享 code/data/heap/files，不共享 stack/PC/registers）。(3) User-level vs kernel-level threads 的差異。
- thread 通常比 process 更 lightweight，建立與切換成本較低。
- 同一 process 的 threads 可直接讀寫共享資料，不代表讀寫天然安全。
- 每個 thread 的 stack 分離，否則函式呼叫與區域狀態會互相破壞。
- process isolation 較強；thread sharing 較快，兩者是隔離與成本的取捨。
4.User mode、Kernel mode 與 System Call
現代 CPU 至少有兩種執行模式，用來保護 OS kernel 不被使用者程式破壞： 【User mode（使用者模式）】一般應用程式在 user mode 下執行，只能存取自己的 address space 中被允許的區域。不能執行特權指令（如直接存取硬體、修改 page table、停止 CPU），也不能存取 kernel 的記憶體。 【Kernel mode（核心模式/特權模式）】OS kernel 在 kernel mode 下執行，可以存取所有記憶體和硬體，執行所有指令包括特權指令。 【Mode switching】 • User → Kernel：當應用程式需要 OS 的服務時（如讀寫檔案、分配記憶體、網路通訊），透過 system call（系統呼叫）從 user mode 轉換到 kernel mode。System call 是應用程式和 OS kernel 之間的介面。 • Kernel → User：OS 完成服務後，切回 user mode 把結果交給應用程式。 其他觸發 kernel mode 的方式：硬體中斷（interrupt，如鍵盤按鍵、磁碟完成讀寫）和異常（exception/trap，如除以零、page fault）。 【常見 System Calls】 • Process 管理：fork(), exec(), wait(), exit() • File 管理：open(), read(), write(), close() • Device 管理：ioctl(), read(), write() • Memory 管理：mmap(), brk() • Communication：pipe(), socket(), send(), recv() 【為什麼需要兩種模式？】如果應用程式可以直接存取硬體或其他 process 的記憶體，一個 buggy 或惡意的程式就能破壞整個系統。Mode bit 確保只有 OS kernel 能執行危險操作，應用程式必須「請求」OS 代為執行。 【考試連結】(1) User mode 和 kernel mode 的差異。(2) System call 的角色 — 應用程式進入 kernel mode 的唯一合法途徑。(3) Interrupt 和 exception 也會觸發 mode switch，但它們不是 system call。
- 不同 processes 通常各有自己的 user virtual address space，而不是全部應用共用一個。
- kernel code 在 kernel mode 執行，可管理硬體與受保護資源。
- system call、interrupt 或 exception 都可能使 CPU 進入核心處理流程。
- 只有當執行主體也更換時，才需要完整的 process/thread context switch。
5.Context Switch 保存了什麼
Context switch（上下文切換）是 OS 在兩個 process（或 thread）之間切換 CPU 使用權的過程。每次切換都需要保存當前 process 的狀態並載入下一個 process 的狀態。 【Context 包含什麼】需要保存的狀態（稱為 context）包含： • Program Counter（PC）— 下一條要執行的指令位址 • CPU registers — 包括通用暫存器、stack pointer、frame pointer • Process state — running/ready/waiting • Memory management info — page table base register、TLB 相關 • Scheduling info — 優先權、時間片剩餘 這些資訊保存在 PCB（Process Control Block）中。 【Context switch 的步驟】 (1) OS 把當前 process（P1）的 context 保存到 P1 的 PCB。 (2) OS 更新 P1 的 state（running → ready 或 waiting）。 (3) OS 從下一個 process（P2）的 PCB 載入 context（PC、registers 等）。 (4) OS 更新 P2 的 state（ready → running）。 (5) CPU 從 P2 的 PC 位置繼續執行。 【Context switch 的成本】Context switch 是純粹的 overhead — 在切換過程中 CPU 沒有在做有用的計算。成本包括：(1) 保存和載入 registers 的時間。(2) TLB flush — 切換到新 process 的 address space 後，舊的 TLB entries 無效，需要重新從 page table 載入，初期會有較多 TLB miss。(3) Cache pollution — 新 process 的資料不在 cache 中，初期會有較多 cache miss。 【Thread context switch vs Process context switch】Thread context switch 只需要切換 stack、PC 和 registers（因為同一 process 的 threads 共享 address space），不需要切換 page table 和 flush TLB。所以 thread context switch 比 process context switch 快得多。 【考試連結】(1) Context switch 保存什麼到哪裡（context → PCB）。(2) 為什麼 context switch 是 overhead。(3) Thread 和 process context switch 的成本差異。(4) Context switch 的頻率取決於 time slice 的長度 — time slice 越短，context switch 越頻繁，overhead 越高，但互動性越好。
- context switch 的核心定義是保存與恢復 execution state。
- 在 CPU cores 之間移動工作可能伴隨 switch，但不是定義本身。
- 單純從 user mode 進入 kernel mode，若仍執行同一工作，不必然是 context switch。
- 過度切換會增加 scheduler、cache 與 TLB 等額外成本。
一起拆題目
範例 1：某瀏覽器的兩個分頁由不同 processes 執行。因為它們有同一 parent，所以是否自然共享 memory、stack 與 program counter？
- 先辨認執行單位是兩個 processes，而非同一 process 的 threads。
- process 有各自受保護的位址空間與執行狀態。
- parent-child 關係不會取消隔離；共享資料必須使用 IPC 或明確 shared memory。
所以答案是：不會。兩個 processes 各有自己的受保護位址空間；各 process 內的 threads 分別持有 stack、program counter 與 registers，只有透過明確 IPC 機制才交換資料。
範例 2：同一 process 中兩個 threads 同時修改購物車總額。共享 heap 是否代表不需要同步？
- threads 確實共享 process 的 heap，因此都能看到同一筆資料。
- 讀取、計算、寫回可能由多個機器指令組成。
- 兩條執行路徑交錯時可能遺失更新，形成 race condition。
所以答案是：不是。共享讓溝通便宜，但仍需 mutex、atomic operation 或其他同步方法保護複合更新。
範例 3：程式呼叫 read() 讀檔，CPU 進入 kernel mode，完成後回到同一 thread。這一定是 process/thread context switch 嗎？
- read() 是 system call，必須進入 kernel mode。
- mode switch 描述 privilege level 改變。
- 若核心沒有改排程到另一個 thread，執行主體仍相同，沒有完整保存／恢復另一個 execution context。
所以答案是：不一定。這一定發生 mode switch，但只有 scheduler 實際換到另一個 thread/process 時才是 process/thread context switch。
範例 4：排程器準備把 CPU 從 P1 切換到 P2。請列出最關鍵的動作。
- 保存 P1 的 program counter、stack pointer 與 registers。
- 更新 P1 狀態並選定 P2。
- 必要時切換 address-space mapping。
- 恢復 P2 的 registers 與 program counter，讓 P2 從上次位置繼續。
所以答案是：context switch 的核心是保存 P1 execution state、恢復 P2 execution state；process switch 可能再加上位址空間切換。
這裡最容易選錯
- 把 program 與 process 當成同義詞；前者是靜態內容，後者是執行實例。
- 誤以為同一 parent 建立的 processes 自動共享 stack、registers 與全部 memory。
- 只記得 threads 共享 memory，卻忘記每條 thread 有獨立 stack、program counter 與 registers。
- 把 lightweight 說成 process 的特性；一般而言 thread 才較 lightweight。
- 把 mode switch、system call 與 context switch 全部混為一談。
- 看到共享位址空間便認為不需同步，忽略 race condition。
換你快速判斷
先在心中作答，再展開答案。答不出來時，回頭找本課的對照關係。
1program 與 process 有什麼差別？
program 是靜態的指令與資料；process 是 program 的一次執行實例，具有執行狀態、位址空間與作業系統管理的資源。
同一 program 可以同時啟動多個 processes，各自有不同 PID 與執行狀態。
2同一 process 的 threads 共享與不共享哪些重要狀態？
通常共享 code、heap 與開啟的 process resources；每個 thread 各有 stack、program counter 與 register state。
共享降低溝通成本，獨立 execution state 則讓每條 thread 能在不同位置執行。
3為什麼 threads 通常比 processes lightweight？
threads 共用所屬 process 的位址空間與多數資源，建立、溝通與切換通常不需配置或更換完整 process context。
較低成本不代表沒有成本，也不代表共享資料天然安全。
4不同 processes 如何交換資料？
透過作業系統提供或協調的 IPC，例如 pipe、message queue、socket，或明確建立的 shared memory。
process isolation 是預設保護邊界；IPC 是有控制地跨越邊界。
5user mode 與 kernel mode 的核心差異是什麼？
user mode 權限受限，不能直接操作受保護硬體與 kernel memory；kernel mode 可執行特權操作並管理系統資源。
應用程式以 system call 請求核心代為執行受保護服務。
6system call 一定會造成 process/thread context switch 嗎？
不一定。system call 一定涉及進入 kernel 的控制轉移，但若完成後仍回到同一 thread，可能只有 mode switch，沒有換 execution context。
只有排程到另一個 thread/process 時，才需保存目前狀態並恢復另一個狀態。
7context switch 的核心動作是什麼？
保存目前 process/thread 的 execution state，並恢復下一個 process/thread 的 execution state。
典型狀態包含 program counter、stack pointer 與 registers；process switch 可能還要更換位址空間。
8作業系統在 process management 中通常負責哪些工作？
建立與刪除、暫停與恢復、同步與溝通 processes，並協助處理 deadlock 與資源分配。
題目若列出這些職責，通常都屬於作業系統的 process management 範圍。
最後用考古題驗證
本課連結的題目都已通過可重現的技術覆核，可逐題練習與判分。
開始本課考古題練習參考來源
- Computer Science: An Overview, 13th Edition — J. Glenn Brookshear
- 作業系統 — 周志遠