目錄
1. 死鎖的概念以及產生死鎖的原因
1.1 死鎖的定義
在多道程序系統中，由於多個進程的併發執行，改善了系統資源的利用率並提高了系統 的處理能力。然而，多個進程的併發執行也帶來了新的問題——死鎖。所謂死鎖是指多個進程因競爭資源而造成的一種僵局（互相等待），若無外力作用，這些進程都將無法向前推進。
下面我們通過一些實例來說明死鎖現象。
先看生活中的一個實例，在一條河上有一座橋，橋面很窄，只能容納一輛汽車通行。如果有兩輛汽車分別從橋的左右兩端駛上該橋，則會出現下述的衝突情況。此時，左邊的汽車佔有了橋面左邊的一段，要想過橋還需等待右邊的汽車讓出橋面右邊的一段；右邊的汽車佔有了橋面右邊的一段，要想過橋還需等待左邊的汽車讓出橋面左邊的一段。此時，若左右兩邊的汽車都只能向前行駛，則兩輛汽車都無法過橋。
在計算機系統中也存在類似的情況。例如，某計算機系統中只有一臺打印機和一臺輸入設備，進程P1正佔用輸入設備，同時又提出使用打印機的請求，但此時打印機正被進程P2 所佔用，而P2在未釋放打印機之前，又提出請求使用正被P1佔用着的輸入設備。這樣兩個進程相互無休止地等待下去，均無法繼續執行，此時兩個進程陷入死鎖狀態。
1.2 死鎖產生的原因
1) 系統資源的競爭
通常系統中擁有的不可剝奪資源，其數量不足以滿足多個進程運行的需要，使得進程在運行過程中，會因爭奪資源而陷入僵局，如磁帶機、打印機等。只有對不可剝奪資源的競爭纔可能產生死鎖，對可剝奪資源的競爭是不會引起死鎖的。
2) 進程推進順序非法
進程在運行過程中，請求和釋放資源的順序不當，也同樣會導致死鎖。例如，併發進程 P1、P2分別保持了資源R1、R2，而進程P1申請資源R2，進程P2申請資源R1時，兩者都會因爲所需資源被佔用而阻塞。
信號量使用不當也會造成死鎖。進程間彼此相互等待對方發來的消息，結果也會使得這些進程間無法繼續向前推進。例如，進程A等待進程B發的消息，進程B又在等待進程A 發的消息，可以看出進程A和B不是因爲競爭同一資源，而是在等待對方的資源導致死鎖。
3) 死鎖產生的必要條件
產生死鎖必須同時滿足以下四個條件，只要其中任一條件不成立，死鎖就不會發生。
- 互斥條件：進程要求對所分配的資源（如打印機）進行排他性控制，即在一段時間內某資源僅爲一個進程所佔有。此時若有其他進程請求該資源，則請求進程只能等待。
- 不剝奪條件：進程所獲得的資源在未使用完畢之前，不能被其他進程強行奪走，即只能由獲得該資源的進程自己來釋放（只能是主動釋放)。
- 請求和保持條件：進程已經保持了至少一個資源，但又提出了新的資源請求，而該資源已被其他進程佔有，此時請求進程被阻塞，但對自己已獲得的資源保持不放。
- 循環等待條件：存在一種進程資源的循環等待鏈，鏈中每一個進程已獲得的資源同時被鏈中下一個進程所請求。即存在一個處於等待狀態的進程集合{Pl, P2, …, pn}，其中Pi等待的資源被P(i+1)佔有（i=0, 1, …, n-1)，Pn等待的資源被P0佔有，如圖2-15所示。
2. 死鎖的處理策略
爲使系統不發生死鎖，必須設法破壞產生死鎖的四個必要條件之一，或者允許死鎖產生， 但當死鎖發生時能檢測出死鎖，並有能力實現恢復。
預防死鎖
設置某些限制條件，破壞產生死鎖的四個必要條件中的一個或幾個，以防止發生死鎖。
避免死鎖
在資源的動態分配過程中，用某種方法防止系統進入不安全狀態，從而避免死鎖。
死鎖的檢測及解除
無需釆取任何限制性措施，允許進程在運行過程中發生死鎖。通過系統的檢測機構及時地檢測出死鎖的發生，然後釆取某種措施解除死鎖。
預防死鎖和避免死鎖都屬於事先預防策略，但預防死鎖的限制條件比較嚴格，實現起來較爲簡單，但往往導致系統的效率低，資源利用率低；避免死鎖的限制條件相對寬鬆，資源分配後需要通過算法來判斷是否進入不安全狀態，實現起來較爲複雜。
死鎖的幾種處理策略的比較見表2-1。
| – | 資源分配策略 | 各種可能模式 | 主要優點 | 主要缺點 |
|---|---|---|---|---|
| 死鎖預防 | 保守，寧可資源閒置 | 一次請求所有資源，資 源剝奪，資源按序分配 | 適用於做突發式處理的進程，不必進行剝奪 | 效率低，進程初始化時間延長；剝奪次數過多；不便靈活申請新資源 |
| 死鎖避免 | 是”預防“和”檢測“ 的折中（在運行時判斷是否可能死鎖） | 尋找可能的安全允許順序 | 不必進行剝奪 | 必須知道將來的資源需求；進程不能被長時間阻塞 |
| 死鎖檢測 | 寬鬆，只要允許就分配資源 | 定期檢查死鎖是否已經發生 | 不延長進程初始化時間，允許對死鎖進行現場處理 | 通過剝奪解除死鎖，造成損失 |
3. 死鎖預防和死鎖避免
3.1 死鎖預防
防止死鎖的發生只需破壞死鎖產生的四個必要條件之一即可。
1) 破壞互斥條件
如果允許系統資源都能共享使用，則系統不會進入死鎖狀態。但有些資源根本不能同時訪問，如打印機等臨界資源只能互斥使用。所以，破壞互斥條件而預防死鎖的方法不太可行，而且在有的場合應該保護這種互斥性。
2) 破壞不剝奪條件
當一個已保持了某些不可剝奪資源的進程，請求新的資源而得不到滿足時，它必須釋放已經保持的所有資源，待以後需要時再重新申請。這意味着，一個進程已佔有的資源會被暫時釋放，或者說是被剝奪了，或從而破壞了不可剝奪條件。
該策略實現起來比較複雜，釋放已獲得的資源可能造成前一階段工作的失效，反覆地申請和釋放資源會增加系統開銷，降低系統吞吐量。這種方法常用於狀態易於保存和恢復的資源，如CPU的寄存器及內存資源，一般不能用於打印機之類的資源。
3) 破壞請求和保持條件
釆用預先靜態分配方法，即進程在運行前一次申請完它所需要的全部資源，在它的資源未滿足前，不把它投入運行。一旦投入運行後，這些資源就一直歸它所有，也不再提出其他資源請求，這樣就可以保證系統不會發生死鎖。
這種方式實現簡單，但缺點也顯而易見，系統資源被嚴重浪費，其中有些資源可能僅在運行初期或運行快結束時才使用，甚至根本不使用。而且還會導致“飢餓”現象，當由於個別資源長期被其他進程佔用時，將致使等待該資源的進程遲遲不能開始運行。
4) 破壞循環等待條件
爲了破壞循環等待條件，可釆用順序資源分配法。首先給系統中的資源編號，規定每個進程，必須按編號遞增的順序請求資源，同類資源一次申請完。也就是說，只要進程提出申請分配資源Ri，則該進程在以後的資源申請中，只能申請編號大於Ri的資源。
這種方法存在的問題是，編號必須相對穩定，這就限制了新類型設備的增加；儘管在爲資源編號時已考慮到大多數作業實際使用這些資源的順序，但也經常會發生作業使甩資源的順序與系統規定順序不同的情況，造成資源的浪費；此外，這種按規定次序申請資源的方法，也必然會給用戶的編程帶來麻煩。
3.2 死鎖避免
避免死鎖同樣是屬於事先預防的策略，但並不是事先釆取某種限制措施破壞死鎖的必要條件，而是在資源動態分配過程中，防止系統進入不安全狀態，以避免發生死鎖。這種方法所施加的限制條件較弱，可以獲得較好的系統性能。
3.2.1 系統安全狀態
避免死鎖的方法中，允許進程動態地申請資源，但系統在進行資源分配之前，應先計算此次資源分配的安全性。若此次分配不會導致系統進入不安全狀態，則將資源分配給進程； 否則，讓進程等待。
所謂安全狀態，是指系統能按某種進程推進順序( P1, P2, …, Pn)，爲每個進程Pi分配其所需資源，直至滿足每個進程對資源的最大需求，使每個進程都可順序地完成。此時稱 P1, P2, …, Pn 爲安全序列。如果系統無法找到一個安全序列，則稱系統處於不安全狀態。
假設系統中有三個進程P1、P2和P3,共有12 臺磁帶機。進程P1總共需要10臺磁帶機，P2和P3 分別需要4臺和9臺。假設在T0時刻，進程P1、P2 和P3已分別獲得5合、2臺和2臺，尚有3臺未分配，見表3-1。
| 進程 | 最大需求 | 已分配 | 可用 |
|---|---|---|---|
| P1 | 10 | 5 | 3 |
| P2 | 4 | 2 | |
| P3 | 9 | 2 |
則在T0時刻是安全的，因爲存在一個安全序列P2、Pl、P3，即只要系統按此進程序列分配資源，則每個進程都能順利完成。若在T0時刻後，系統分配1臺磁帶機給P3，則此時系統便進入不安全狀態，因爲此時已無法再找到一個安全序列。
並非所有的不安全狀態都是死鎖狀態，但當系統進入不安全狀態後，便可能進入死鎖狀態；反之，只要系統處於安全狀態，系統便可以避免進入死鎖狀態。
3.2.2 銀行家算法
銀行家算法是最著名的死鎖避免算法。它提出的思想是：把操作系統看做是銀行家，操作系統管理的資源相當於銀行家管理的資金，進程向操作系統請求分配資源相當於用戶向銀行家貸款。操作系統按照銀行家制定的規則爲進程分配資源，當進程首次申請資源時，要測試該進程對資源的最大需求量，如果系統現存的資源可以滿足它的最大需求量則按當前的申請量分配資源，否則就推遲分配。當進程在執行中繼續申請資源時，先測試該進程已佔用的資源數與本次申請的資源數之和是否超過了該進程對資源的最大需求量。若超過則拒絕分配資源，若沒有超過則再測試系統現存的資源能否滿足該進程尚需的最大資源量，若能滿足則按當前的申請量分配資源，否則也要推遲分配。
1) 數據結構描述
可利用資源矢量Available：含有m個元素的歎組，其中的每一個元素代表一類可用的資源數目。Available[j]=K，則表示系統中現有Rj類資源K個。
最大需求矩陣Max：爲n*m矩陣，定義了系統中n個進程中的每一個進程對m類資源的最大需求。Max[i, j]=K，則表示進程i需要Rj類資源的最大數目爲K。
分配矩陣Allocation：爲n*m矩陣，定義了系統中每一類資源當前已分配給每一進程的資源數。All0Cati0n[i, j]= K，則表示進程i當前已分得Rj類資源的數目爲K。
需求矩陣Need：爲n*m矩陣，表示每個進程尚需的各類資源數。Need[i, j]=K，則表示進程i還需要Rj類資源的數目爲K。
上述三個矩陣間存在下述關係：
Need[i, j] = Max[i, j] - Allocation[i, j]
2) 銀行家算法描述
設Requesti是進程Pi的請求矢量，如果Requesti[j]K，表示進程Pi需要Rj類資源K個。當Pi發出資源請求後，系統按下述步驟進行檢查：
①如果Requesti[j] <= Need[i, j]，便轉向步驟②；否則認爲出錯，因爲它所需要的資源數已超過它所宣佈的最大值。
②如果Requesti[j] <= Available[j]，便轉向步驟③;否則，表示尚無足夠資源，Pi須等待。
③系統試探着把資源分配給進程Pi，並修改下面數據結構中的數：
Available[j] = Available[j] - Requesti[j];
Allocation[i, j] = Allocation[i, j] + Requesti[ j];
Need[i, j] = Need[i, j] - Requesti[j];
④系統執行安全性算法，檢查此次資源分配後，系統是否處於安全狀態。若安全，才正式將資源分配給進程Pi，以完成本次分配；否則，將本次的試探分配作廢，恢復原來的資源分配狀態，讓進程Pi等待。
3) 安全性算法
①設置兩個矢量。工作矢量Work；它表示系統可提供給進程繼續運行所需的各類資源數目，它含有所個元素，在執行安全算法開始時，Work=Available; Finish：它表示系統是否有足夠的資源分配給進程，使之運行完成。開始時 Finish[i]=false；當有足夠資源分配給進程 Pi 時，再令 Finish[i]=true。
②從進程集合中找到一個能滿足下述條件的進程：Finish[i]=false; Need[i, j]<=Work[j]; 若找到，執行下一步驟，否則，執行步驟4。
③當進程Pi獲得資源後，可順利執行，直至完成，並釋放出分配給它的資源，故應執行：
Work[j]=Work[j]+Allocation[i, j];
Finish[i]=true;
go to step <2>;
④如果所有進程的Finish[i]=tme都滿足，則表示系統處於安全狀態；否則，系統處於不安全狀態。
3.2.3 銀行家算法舉例
假定系統中有5個進程{P0, P1, P2, P3, P4}和三類資源{A, B, C}，各種資源的數量分別爲10、5、7，在T0時刻的資源分配情況見表3-2。
1) T0時刻的安全性。
利用安全性算法對T0時刻的資源分配進行分析，由表3-3可知，在T0時刻存在着一個安全序列{P1, P3, P4, P2, P0}，故系統是安全的。
| 進程 / 資源情況 | Max A B C |
Allocation A B C |
Need A B C |
Available A B C |
|---|---|---|---|---|
| P0 | 7 5 3 | 0 1 0 | 7 4 3 | 3 3 2 (2 3 0) |
| P1 | 3 2 2 | 2 0 0 (3 0 2) |
1 2 2 (0 2 0) |
|
| P2 | 9 0 2 | 3 0 2 | 6 0 0 | |
| P3 | 2 2 2 | 2 1 1 | 0 1 1 | |
| P4 | 4 3 3 | 0 0 2 | 4 3 1 |
| 進程 / 資源情況 | Work A B C |
Need A B C |
Allocation A B C |
Work+Allocation A B C |
Finish |
|---|---|---|---|---|---|
| P1 | 3 3 2 | 1 2 2 | 2 0 0 | 5 3 2 | true |
| P3 | 5 3 2 | 0 1 1 | 2 1 1 | 7 4 3 | true |
| P4 | 7 4 3 | 4 3 1 | 0 0 2 | 7 4 5 | true |
| P2 | 7 4 5 | 6 0 0 | 3 0 2 | 10 4 7 | true |
| P0 | 10 4 7 | 7 4 3 | 0 1 0 | 10 5 7 | true |
2) P1請求資源
P1發出請求矢量Request1(l，, 0, 2)，系統按銀行家算法進行檢查：
- Request1(1, 0, 2) <= Need1(l, 2, 2)。
- Request1(1, 0, 2) <= Available1(3, 3, 2)。
- 系統先假定可爲P1分配資源，並修改Available、Allocation1和Need1矢量，由此形成的資源變化情況見表3-4。
- 再利用安全性算法檢查此時系統是否安全。
| 進程 / 資源情況 | Work A B C |
Need A B C |
Allocation A B C |
Work+ Allocation A B C |
Finish |
|---|---|---|---|---|---|
| P1 | 2 3 0 | 0 2 0 | 3 0 2 | 5 3 2 | true |
| P3 | 5 3 2 | 0 1 1 | 2 1 1 | 7 4 3 | true |
| P4 | 7 4 3 | 4 3 1 | 0 0 2 | 7 4 5 | true |
| P0 | 7 4 5 | 7 4 3 | 0 1 0 | 7 5 5 | true |
| P2 | 7 5 5 | 6 0 0 | 3 0 2 | 10 5 7 | true |
3) P4請求資源
P4發出請求矢量Request4(3, 3, 0)，系統按銀行家算法進行檢查：
- Request4(3, 3, 0) <= Need4(4, 3, 1)。
- Request4(3, 3, 0) > Available(2, 3, 0)，讓 P4 等待。
4) P0請求資源
P0發出請求矢量Request0(0, 2, 0)，系統按銀行家算法進行檢查：
- Request0(0, 2, 0) <= Need0(7, 4, 3)。
- Request0(0, 2, 0) <= Available(2, 3, 0)。
- 系統暫時先假定可爲P0分配資源，並修改有關數據，見表3-5。
| 進程 / 資源情況 | Allocation A B C |
Need A B C |
Available A B C |
|---|---|---|---|
| P0 | 0 3 0 | 7 2 3 | 2 1 0 |
| P1 | 3 0 2 | 0 2 0 | |
| P2 | 3 0 2 | 6 0 0 | |
| P3 | 2 1 1 | 0 1 1 | |
| P4 | 0 0 2 | 4 3 1 |
5) 進行安全性檢測。
可用資源Available(2, 1, 0)已不能滿足任何進程的需要，故系統進入不安全狀態，此時系統不分配資源。
4. 死鎖的檢測和解除
前面紹的死鎖預防和避免算法，都是在爲進程分配資源時施加限制條件或進行檢測，若系統爲進程分配資源時不釆取任何措施，則應該提供死鎖檢測和解除的手段。
資源分配圖
系統死鎖，可利用資源分配圖來描述。如圖4-1所示，用圓圈代表一個進程，用框代表一類資源。由於一種類型的資源可能有多個，用框中的一個點代表一類資源中的一個資源。從進程到資源的有向邊叫請求邊，表示該進程申請一個單位的該類資源；從資源到進程的邊叫分配邊，表示該類資源已經有一個資源被分配給了該進程。
圖4-1 資源分配示例圖
在圖4-1所示的資源分配圖中，進程P1已經分得了兩個R1資源，並又請求一個R2 資源；進程P2分得了一個R1和一個R2資源，並又請求一個R1資源。
死鎖定理
可以通過將資源分配圖簡化的方法來檢測系統狀態S是否爲死鎖狀態。簡化方法如下：
1) 在資源分配圖中，找出既不阻塞又不是孤點的進程Pi（即找出一條有向邊與它相連，且該有向邊對應資源的申請數量小於等於系統中已有空閒資源數量。若所有的連接該進程的邊均滿足上述條件，則這個進程能繼續運行直至完成，然後釋放它所佔有的所有資源）。消去它所有的請求邊和分配邊，使之成爲孤立的結點。在圖4-2(a)中，P1是滿足這一條件的進程結點，將P1的所有邊消去，便得到圖4-2(b)所示的情況。
2) 進程Pi所釋放的資源，可以喚醒某些因等待這些資源而阻塞的進程，原來的阻塞進程可能變爲非阻塞進程。在圖2-17中，進程P2就滿足這樣的條件。根據第1) 條中的方法進行一系列簡化後,若能消去圖中所有的邊，則稱該圖是可完全簡化的，如圖4-2(c)所示。
S爲死鎖的條件是當且僅當S狀態的資源分配圖是不可完全簡化的,該條件爲死鎖定理。
死鎖的解除
一旦檢測出死鎖，就應立即釆取相應的措施，以解除死鎖。死鎖解除的主要方法有：
1) 資源剝奪法。掛起某些死鎖進程，並搶佔它的資源，將這些資源分配給其他的死鎖進程。但應防止被掛起的進程長時間得不到資源，而處於資源匱乏的狀態。
2) 撤銷進程法。強制撤銷部分、甚至全部死鎖進程並剝奪這些進程的資源。撤銷的原則可以按進程優先級和撤銷進程代價的高低進行。
圖4-2 資源分配圖的化簡
3) 進程回退法。讓一（多）個進程回退到足以迴避死鎖的地步，進程回退時自願釋放資源而不是被剝奪。要求系統保持進程的歷史信息，設置還原點。
5. 關於進程和線程的知識點彙總
5.1 進程與程序的區別與聯繫
1) 進程是程序及其數據在計算機上的一次運行活動，是一個動態的概念。進程的運行實體是程序，離開程序的進程沒有存在的意義。從靜態角度看，進程是由程序、數據和進程控制塊(PCB)三部分組成的。而程序是一組有序的指令集合，是一種靜態的概念。
2) 進程是程序的一次執行過程，它是動態地創建和消亡的，具有一定的生命週期，是暫時存在的；而程序則是一組代碼的集合，它是永久存在的，可長期保存。
3) 一個進程可以執行一個或幾個程序，一個程序也可以構成多個進程。進程可創建進程，而程序不可能形成新的程序。
4) 進程與程序的組成不同。進程的組成包括程序、數據和PCB。
5.2 死鎖與飢餓
具有等待隊列的信號量的實現可能導致這樣的情況：兩個或多個進程無限地等待一個事件，而該事件只能由這些等待進程之一來產生。這裏的事件是V操作的執行（即釋放資源）。當出現這樣的狀態時，這些進程稱爲死鎖(Dead locked)。
爲了加以說明，考慮到一個系統由兩個進程P0和P1組成，每個進程都訪問兩個信號量S和Q，這兩個信號量的初值均爲1。
P0 () {
While (1){
P(S) ;
P(Q);
// …
V(S) ;
V(Q) ;
}
}
p1() {
While(1){
P(Q);
P(S);
// …
V(Q);
V(S);
}
}
假設進程P0執行P(S)，接着進程P1執行P(Q)。當進程P0執行P(Q)時，它必須等待直到進程P1執行V(Q)。類似地，當進程P1執行P(S)，它必須等待直到進程P0執行V(S)。由於這兩個V操作都不能執行，那麼進程P0和進程P1就死鎖了。
說一組進程處於死鎖狀態是指：組內的每個進程都等待一個事件，而該事件只可能由組內的另一個進程產生。這裏所關心的主要是事件是資源的獲取和釋放。
與死鎖相關的另一個問題是無限期阻塞(Indefinite Blocking)或“飢餓” (Starvation)，即進程在信號量內無窮等待的情況。
產生飢餓的主要原因是：在一個動態系統中，對於每類系統資源，操作系統需要確定一個分配策略，當多個進程同時申請某類資源時，由分配策略確定資源分配給進程的次序。有時資源分配策略可能是不公平的，即不能保證等待時間上界的存在。在這種情況下，即使系統沒有發生死鎖，某些進程也可能會長時間等待。當等待時間給進程推進和響應帶來明顯影響時，稱發生了進程“飢餓”，當“飢餓”到一定程度的進程所賦予的任務即使完成也不再具有實際意義時稱該進程被“餓死”。
例如，當有多個進程需要打印文件時，如果系統分配打印機的策略是最短文件優先，那麼長文件的打印任務將由於短文件的源源不斷到來而被無限期推遲，導致最終的“飢餓”甚至“餓死”。
“飢餓”並不表示系統一定死鎖，但至少有一個進程的執行被無限期推遲。“飢餓”與死鎖的主要差別有：
- 進入“飢餓”狀態的進程可以只有一個，而由於循環等待條件而進入死鎖狀態的進程卻必須大於或等於兩個。
- 處於“飢餓”狀態的進程可以是一個就緒進程，如靜態優先權調度算法時的低優先權進程，而處於死鎖狀態的進程則必定是阻塞進程。
5.3 銀行家算法的工作原理
銀行家算法的主要思想是避免系統進入不安全狀態。在每次進行資源分配時，它首先檢查系統是否有足夠的資源滿足要求，如果有，則先進行分配，並對分配後的新狀態進行安全性檢查。如果新狀態安全，則正式分配上述資源，否則就拒絕分配上述資源。這樣，它保證系統始終處於安全狀態，從而避免死鎖現象的發生。
5.4 進程同步、互斥的區別和聯繫
併發進程的執行會產生相互制約的關係：一種是進程之間競爭使用臨界資源，只能讓它們逐個使用，這種現象稱爲互斥，是一種競爭關係；另一種是進程之間協同完成任務，在關鍵點上等待另一個進程發來的消息，以便協同一致，是一種協作關係。
5.5 作業和進程的關係
進程是系統資源的使用者，系統的資源大部分都是以進程爲單位分配的。而用戶使用計算機是爲了實現一串相關的任務，通常把用戶要求計算機完成的這一串任務稱爲作業。
1) 批處理系統中作業與進程的關係（進程組織）
批處理系統中的可以通過磁記錄設備或卡片機向系統提交批作業，由系統的SPOOLing 輸入進程將作業放入磁盤的輸入井中，作爲後備作業。作業調度程序（一般也作爲獨立的進程運行)每當選擇一道後備作業運行時,首先爲該作業創建一個進程(稱爲該作業的根進程)。該進程將執行作業控制語言解釋程序解釋該作業的作業說明書。父進程在運行過程中可以動態地創建一個或多個子進程，執行說明書中的語句。
例如，對一條編譯的語句，該進程可以創建一個子進程執行編譯程序對用戶源程序進行編譯。類似地，子進程也可以繼續創建子進程去完成指定的功能。因此，一個作業就動態地轉換成了一組運行實體——進程族。當父進程遇到作業說明書中的“撤出作業”的語句時，將該作業從運行狀態改變爲完成狀態，將作業及相關結果送入磁盤上的輸出井。作業終止進程負責將輸出井中的作業利用打印機輸出，回收作業所佔用的資源，刪除作業有關數據結構，刪除作業在磁盤輸出井中的信息，等等。作業終止進程撤除一道作業後，可向作業調度進程請求進行新的作業調度。至此，一道進入系統運行的作業全部結束。
2) 分時系統中作業與進程的關係
在分時系統中，作業的提交方法、組織形式均與批處理作業有很大差異。分時系統的用戶通過命令語言逐條地與系統應答式地輸入命令，提交作業步。每輸入一條（或一組）命令，便直接在系統內部對應一個（或若干個）進程。在系統啓動時，系統爲每個終端設備建立一個進程（稱爲終端進程)，該進程執行命令解釋程序，命令解釋程序從終端設備讀入命令解釋執行用戶輸入的每一條命令。對於每一條終端命令，可以創建一個子進程去具體執行。若當前的終端命令是一條後臺命令，則可以和下一條終端命令並行處理。各子進程在運行過程中完全可以根據需要創建子孫進程。終端命令所對應的進程結束後，命令的功能也相應處理完畢。用戶本次上機完畢，用戶通過一條登出命令即結束上機過程。
分時系統的作業就是用戶的一次上機交互過程，可以認爲終端進程的創建是一個交互作業的開始，登出命令運行結束代表用戶交互作業的終止。
命令解釋程序流程扮演着批處理系統中作業控制語言解釋程序的角色，只不過命令解釋程序是從用戶終端接收命令。
3) 交互地提交批作業
在同時支持交互和批處理的操作系統中，人們可以用交互的方式準備好批作業的有關程序、數據及作業控制說明書。
比如，可用交互式系統提供的全屏幕編輯命令編輯好自編的一個天氣預報程序，用編譯及裝配命令將程序變成可執行文件，用調試命令進行程序調試。在調試成功後，用戶每天都要做如下工作：準備原始天氣數據，運行天氣預報執行文件處理原始數據，把結果打印出來等。這時，用交互系統提供的全屏幕編輯命令編輯好將要提交的作業控制說明書文件，如Windows系統的BAT文件和Linux系統的sh文件。然後用一條作業提交命令將作業提交給系統作業隊列中。系統有專門的作業調度進程負責從作業隊列中選擇作業，爲被選取的作業創建一個父進程運行命令解釋程序，解釋執行作業控制說明書文件中的命令。