半同步半異步模式
一個架構(gòu)模式，清晰的結(jié)構(gòu),高效并發(fā)的I/O

譯者:

英文原文:?http://www.cs.wustl.edu/~schmidt/PDF/HS-HA.pdf

摘要
這篇文字介紹了半同步半異步模式，這個模式運(yùn)用在復(fù)雜的并行系統(tǒng)中，把同步和異步I/O模型集成在一起，既保持了編程簡單又保證了執(zhí)行的效率。這個模式中，高層使用同步I/O模型，簡化編程。低層使用異步I/O模型，高效執(zhí)行。各種操作系統(tǒng)和其它復(fù)雜的并行系統(tǒng)中廣泛使用這個模式，使用這個模式的操作系統(tǒng)有：UNIX, Mach，Windows NT，and VMS。

1 意圖
在系統(tǒng)中分離了同步I/O和異步I/O的兩個過程，既簡化了并行程序?qū)崿F(xiàn)的復(fù)雜，又不會影響執(zhí)行的效率。

2 動機(jī)
如圖一所示，為了說明半同步半異步模式，我們來考慮一個軟件架構(gòu)，BSD UNIX[1]的網(wǎng)絡(luò)子系統(tǒng)。BSD UNIX的內(nèi)核負(fù)責(zé)協(xié)調(diào)異步通信設(shè)備（如：網(wǎng)絡(luò)適配器、遠(yuǎn)程終端）和應(yīng)用程序之間的I/O行為。數(shù)據(jù)包隨時到達(dá)設(shè)備，產(chǎn)生硬件中斷，然后由中斷處理例程把數(shù)據(jù)交給操作系統(tǒng)內(nèi)核。這些中斷處理例程接收數(shù)據(jù)，觸發(fā)上層的網(wǎng)絡(luò)協(xié)議處理（如 IP，TCP和UDP）。應(yīng)用數(shù)據(jù)包在套接口層排隊。操作系統(tǒng)把這些數(shù)據(jù)包分發(fā)給每個用戶進(jìn)程。用戶進(jìn)程使用系統(tǒng)調(diào)用read，以同步的方式接收套接口層的數(shù)據(jù)。用戶進(jìn)程可以在任意時刻調(diào)用read，當(dāng)數(shù)據(jù)沒有到達(dá)的時候，進(jìn)程將一直阻塞等待。

在這個體系中，操作系統(tǒng)內(nèi)核響應(yīng)設(shè)備的中斷，執(zhí)行異步的I/O。而用戶級的應(yīng)用程序進(jìn)行同步的I/O。這正是“半同步半異步”這個名字的由來，這個結(jié)構(gòu)滿足下面的兩個需要：

編程實現(xiàn)簡單。異步I/O模型中，中斷隨時觸發(fā)輸入和輸出操作，編程復(fù)雜。使用異步I/O模型，當(dāng)中斷處理例程擁有線程控制權(quán)時,會產(chǎn)生非常麻煩的時序和竟?fàn)巻栴}。而且，使用中斷機(jī)制的程序要求額外的數(shù)據(jù)結(jié)構(gòu)，這個數(shù)據(jù)結(jié)構(gòu)用于在異步事件發(fā)生的時候保存進(jìn)程上下文狀態(tài)。并且，程序執(zhí)行的時候，外部的事件會在不固定的時間發(fā)生，程序不容易調(diào)試。

與其相比，使用同步I/O模型的時候，I/O操作在確定的點(diǎn)發(fā)生，編程實現(xiàn)要容易的多。此外，同步I/O操作的程序會阻塞等待I/O操作的完成。進(jìn)程運(yùn)行上下文的活動記錄自動在運(yùn)行棧中保存，不必使用獨(dú)立的數(shù)據(jù)結(jié)構(gòu)。因此，為了讓編程簡單，有強(qiáng)烈的理由使用同步I/O模型。

程序執(zhí)行高效。在中斷驅(qū)動的設(shè)備上，異步I/O模型運(yùn)用帶來了高效率。異步I/O讓通信和計算同時進(jìn)行。并且，因為程序運(yùn)行狀態(tài)的數(shù)據(jù)量相對較小，上下文切換的消耗被最小化[2]。因此，為了提高運(yùn)行的性能，也有強(qiáng)烈理由使用異步I/O模型。

與其相比，如果每種資源的事件（例如網(wǎng)卡，終端和計時器）占用一個獨(dú)立的活動對象（進(jìn)程或線程），一個完全同步I/O模型效率會低。每個活動對象包含多個資源（例如棧，寄存器），每種資源都會讓它阻塞，等待資源事件的發(fā)生。在創(chuàng)建，調(diào)度，分發(fā)和終止這些獨(dú)立的活動對象，會消耗更多的時間和空間。

3 方案
??? 編程簡單和高效率執(zhí)行是矛盾的，半同步半異步模式目的正是為了解決這個矛盾。這個模式集成了同步和異步兩種I/O模式，結(jié)構(gòu)清晰，效率高。在這個模式中，上層的任務(wù)（如：數(shù)據(jù)庫查詢，文件傳輸）使用同步I/O模型，簡化了編寫并行程序的難度。而底層的任務(wù)（如網(wǎng)絡(luò)控制器的中斷處理）使用異步I/O模型，提供了執(zhí)行效率。一般情況下，上層的任務(wù)要比下層的任務(wù)多，使用一個簡單的層次實現(xiàn)異步處理的復(fù)雜性，可以對外隱藏異步處理的細(xì)節(jié)。另外，同步層次和異步層次任務(wù)間的通信使用一個隊列來協(xié)調(diào)。???

4 應(yīng)用?
半同步半異步模式在下面的場景中使用。

× 一個系統(tǒng)中的進(jìn)程有下面的特征：
系統(tǒng)必須響應(yīng)和處理外部異步發(fā)生的事件，
如果為每一個外部資源的事件分派一個獨(dú)立的線程同步處理I/O，效率很低。
如果上層的任務(wù)以同步方式處理I/O，實現(xiàn)起來簡單。

× 一個或多個任務(wù)必須在單獨(dú)的控制線程中執(zhí)行，其它任務(wù)可以在多線程中執(zhí)行。
例如，X Window和Sun RPC 的庫函數(shù)許多是不可重入的。多個控制線程不能安全地同時調(diào)用這些函數(shù)。然而，為了使多個CPU提高服務(wù)的質(zhì)量，有必要使用并行，不同的線程同時執(zhí)行批量數(shù)據(jù)的傳輸或數(shù)據(jù)庫的查詢。使用半同步半異步模式，可以在多線程中分離出單獨(dú)的線程。在不改變現(xiàn)有代碼的情況下，這個分離可以讓不可重入的函數(shù)在并行環(huán)境正確執(zhí)行。

5 結(jié)構(gòu)和組成單元
圖二顯示了半同步半異步模式的組成結(jié)構(gòu)。這些組成單元如下描述

×同步任務(wù)層（用戶級的進(jìn)程）
本層的任務(wù)完成上層的I/O操作，使用同步I/O模型，通過隊列層的隊列中傳輸數(shù)據(jù)。和異步層不同，同步層的任務(wù)使用活動對象[3]執(zhí)行，這些活動對象有自己運(yùn)行棧和寄存器狀態(tài)。當(dāng)執(zhí)行同步I/O的時候，他們會被阻塞/睡眠。

×隊列層（套接口層）
這個層在同步任務(wù)層和異步任務(wù)層之間，提供了同步控制和緩存的功能。異步任務(wù)的I/O事件被緩存到消息隊列中，同步任務(wù)層在隊列中提取這些事件（相反方向亦然）。

×異步任務(wù)層
處理低層的事件，這些事件由多個外部的事件源產(chǎn)生（例如網(wǎng)卡，終端）。和異步任務(wù)不同，此層的實體是被動對象，沒有自己的運(yùn)行棧，要求不能被阻塞。

×外部事件源（網(wǎng)絡(luò)接口）
外部設(shè)備產(chǎn)生事件，產(chǎn)生的事件先被異步任務(wù)層接收和處理。

6 協(xié)作
圖三展現(xiàn)了一個動態(tài)的過程：當(dāng)外部事件到達(dá)后，半同步半異步模式的各個組成單元協(xié)作和處理。把協(xié)作的過程分成下面三個階段：

×異步階段。通過中斷機(jī)制或異步事件通知，外部的事件源和異步任務(wù)層完成交互。

×排隊階段。隊列層的隊列提供了一個同步控制機(jī)制，響應(yīng)輸入事件，緩存同步層和異步層之間的消息，

×同步階段。同步任務(wù)層在隊列層提取消息。注意，同步層和異步層專遞數(shù)據(jù)的協(xié)議是獨(dú)立的，和隊列層具體處理通信的方式無關(guān)。
在圖三中，同步層和異步層之間的通信使用生產(chǎn)者/消費(fèi)者模型。理解這個模型的關(guān)鍵是：完成同步任務(wù)的是活動對象。他們可以在任意時刻阻塞調(diào)用read或在 write。如果數(shù)據(jù)沒有準(zhǔn)備好，這些活動對象可以一直等待。相反的，異步任務(wù)層的實體是被動對象。他們不能被阻塞。這些對象被通知或外部對象觸發(fā)。

7 結(jié)果
半同步半異步模式有下面的優(yōu)點(diǎn)

×上層的任務(wù)被簡化，這是因為不需要再面對底層的異步I/O。復(fù)雜的并發(fā)控制，中斷處理和計時操作都委托給異步任務(wù)層。異步層負(fù)責(zé)處理底層的細(xì)節(jié)，如，異步系統(tǒng)編程的中斷處理。異步任務(wù)層管理與硬件相關(guān)的組件間（如DMA，內(nèi)存管理，設(shè)備寄存器）的交互。

×不同層可以使用不同的同步策略。每一層不必使用相同的并行控制方式。例如，在單線程的BSD UNIX內(nèi)核中，異步任務(wù)層使用低級的機(jī)構(gòu)（如修改CPU的中斷級別）。與此不同，用戶級的進(jìn)程使用高級的同步機(jī)構(gòu)（如使用信號量，消息隊列，條件變量，記錄鎖）。

×層間的通信被限制在單獨(dú)的一點(diǎn)，因為所有的交互使用隊列層協(xié)調(diào)。隊列層對兩層之間的消息進(jìn)行緩存。如果直接通信，同步和異步任務(wù)層直接訪問對方的內(nèi)存，就必須使用復(fù)雜的鎖和時序控制。

×在多處理器環(huán)境中提高了性能。使用同步的I/O可以簡化編程和提高性能。例如，長時間的數(shù)據(jù)傳輸（如從數(shù)據(jù)庫中加載一個大的醫(yī)學(xué)圖象）使用同步I/O效率更高。因為一個處理器單獨(dú)為一個線程使用，可以更有效的使用CPU的指令和數(shù)據(jù)的緩存。

半同步半異步模式有下面的缺點(diǎn)

× 跨邊界導(dǎo)致的性能消耗，這是因為同步控制，數(shù)據(jù)拷貝和上下文切換會過度地消耗資源。在同步和異步任務(wù)層之間使用隊列層傳送數(shù)據(jù)的時候，這種消耗往往會發(fā)生。特別是，許多使用半同步半異步模式的操作系統(tǒng)，把隊列層放到用戶和內(nèi)核域的邊界上。到跨越這個邊界的時候，往往會有明顯的性能消耗。例如，BSD UNIX的套接口層，在很大比例上造成了TCP/IP網(wǎng)絡(luò)的過載[4]。

×上層任務(wù)缺少異步I/O的實現(xiàn)。依賴與系統(tǒng)接口的設(shè)計，可能導(dǎo)致上層無法直覺使用低層的異步I/O設(shè)備。因此，如果外部的設(shè)備支持異步的重疊的I/O方式，系統(tǒng)的I/O結(jié)構(gòu)會防礙應(yīng)用程序高效的使用。

8 實現(xiàn)
這一節(jié)描述如何實現(xiàn)半同步半異步模式，系統(tǒng)中分成了同步任務(wù)層和異步任務(wù)層，兩層之間使用隊列層通信。
???
8.1 找到消耗時間的長時任務(wù)，使用同步I/O實現(xiàn)他們。
使用同步I/O方式，可以讓系統(tǒng)任務(wù)的實現(xiàn)簡單化，而系統(tǒng)中經(jīng)常有會時間長的任務(wù)，如執(zhí)行大量流數(shù)據(jù)碰[5]傳輸，或者是等待服務(wù)器響應(yīng)的數(shù)據(jù)查詢。

使用活動對象[3]模型實現(xiàn)這些長時任務(wù)?；顒訉ο髶碛凶约旱倪\(yùn)行棧和寄存器狀態(tài)，在執(zhí)行同步I/O的時候可以被阻塞。實現(xiàn)活動對象結(jié)構(gòu)，要求一個控制線程的切換機(jī)制，需要一個地方存放和恢復(fù)線程的狀態(tài)（如寄存器的值，棧指針），這些功能足夠?qū)崿F(xiàn)一個非搶占的，沒有內(nèi)存保護(hù)的線程機(jī)構(gòu)?！坝脩艏壘€程”包一般實現(xiàn)了此類的功能（譯者：操作系統(tǒng)都實現(xiàn)了這個功能）。
然而，在一個要求健壯的多任務(wù)系統(tǒng)中，要使用進(jìn)程或線程的方式實現(xiàn)活動對象，需要更多的功能。這種情況下，每種線程需要自己的線程（或進(jìn)程）空間，這些空間被處理器的內(nèi)存管理單元（MMU）管理。當(dāng)線程（或進(jìn)程）切換的時候，新的地址空間信息需要加載到MMU中。切換時還需要清空高速緩存，特別是高速緩存使用虛擬地址的情況下。除了地址空間，一個操作系統(tǒng)進(jìn)程還可能包含一個“用戶ID”。這個標(biāo)識告訴操作系統(tǒng)這個進(jìn)程的訪問權(quán)限和占用的系統(tǒng)資源。
為了防止一個單獨(dú)的線程（或進(jìn)程）永久的占用系統(tǒng)，要有搶占的機(jī)制。經(jīng)常使用計時器實現(xiàn)，計時器周期性的產(chǎn)生時鐘中斷。在中斷處理期間，操作系統(tǒng)檢查當(dāng)前的進(jìn)程是否應(yīng)該被搶占。如果應(yīng)該被搶占，就保存當(dāng)前進(jìn)程的狀態(tài)，加載下一個進(jìn)程的狀態(tài)運(yùn)行。
??????
8.2 找到短時任務(wù)，使用異步I/O實現(xiàn)
系統(tǒng)中的一些任務(wù)不能阻塞過長的時間。這些任務(wù)一般和外界事件完成一個短期的交互過程（如圖形用戶界面或中斷驅(qū)動的網(wǎng)絡(luò)接口器），為了提高效率和保證響應(yīng)速度，這些外部事件的處理一定不能阻塞。
實現(xiàn)這樣的短期任務(wù)，要使用被動對象[6]模型。被動對象使用別人的控制線程（調(diào)用者的線程或者一個獨(dú)立的中斷棧）。因為他們不能常時間的等待，不能被阻塞。不阻塞的主要目標(biāo)是保證其響應(yīng)時間（如高優(yōu)先級的硬件中斷，如時鐘中斷）。
實現(xiàn)一個結(jié)構(gòu)清晰的異步I/O框架，有多種方式。

× 使用反應(yīng)堆模式[6]實現(xiàn)多路事件的處理，反應(yīng)堆模式使用一個單線程的處理循環(huán)，把多路的事件派發(fā)給多個處理者。這個模式組合了單線程處理循環(huán)的簡單性和面向?qū)ο缶幊烫峁┑目蓴U(kuò)展性。反應(yīng)堆模式在一個線程（或進(jìn)程）中進(jìn)行順序的消息處理，常用來消除多線程同步和加鎖處理的復(fù)雜性。
一個反應(yīng)堆可以使用在同步或者異步的事件源上。但是它支持的事件處理者的行為要求是異步的。也就是說，為了不影響其它事件源的響應(yīng)效率，事件處理者是不能阻塞的。

×實現(xiàn)一個多級的中斷處理機(jī)構(gòu)。這種機(jī)構(gòu)下，當(dāng)更高級別的任務(wù)（如硬中斷）要求處理的時候，當(dāng)前的進(jìn)程可以被中斷。為了防止共享的狀態(tài)訪問時被破壞，異步層使用的數(shù)據(jù)結(jié)構(gòu)必須被保護(hù)（例如提升處理器級別或使用信號量）。

× 例如，在一個操作系統(tǒng)內(nèi)核中，硬件中斷的服務(wù)時間很大程度上決定了對多級中斷處理機(jī)構(gòu)的需要。如果這個時間能夠顯著的減少，可以把所有的處理放到硬中斷的層次上，這樣就可以避免軟中斷的過度資源消耗。TCP/IP的實現(xiàn)中，就減少輸入包的協(xié)議處理時間化費(fèi)，讓所有的包處理過程可以在兩級中斷機(jī)構(gòu)實現(xiàn)。

8.3 實現(xiàn)一個隊列層
隊列層包含了一個同步控制點(diǎn)，緩存同步任務(wù)和異步任務(wù)之間交換的消息。在實現(xiàn)隊列層的時候，要注意下面幾點(diǎn)：

× 并行控制。如果同步任務(wù)和異步任務(wù)的執(zhí)行是并行的（如論使用多CPU還是硬件中斷），為了避免爭用，共享的隊列的狀態(tài)變化必須是連續(xù)的。因此，實現(xiàn)隊列層的時候，經(jīng)常使用并行控制機(jī)制，如信號量，互斥體和條件變量等。當(dāng)消息在隊列中插入或刪除的時候，并行控制保證隊列的內(nèi)部數(shù)據(jù)結(jié)構(gòu)不被破壞。

×層到層之間的流量控制。在隊列層緩存消息，系統(tǒng)不能提供無限的資源。因此，必須控制同步和異步層之間傳輸?shù)臄?shù)據(jù)量。例如，在層到層的流控制下，避免同步層的數(shù)據(jù)量超過網(wǎng)絡(luò)接口能夠傳輸?shù)臉O限。
同步任務(wù)可以被阻塞。因此，可以使用下面的策略：如果其排隊超過一定的量，可以讓任務(wù)阻塞。當(dāng)異步任務(wù)層把排隊數(shù)降低到一定的水平，就可以重新喚醒同步任務(wù)繼續(xù)執(zhí)行。相對地，異步層地任務(wù)不能被阻塞，當(dāng)處理過量地數(shù)據(jù)時，隊列層要根據(jù)策略丟棄消息。這種情況下，如果使用了一個可靠的，面向連接的網(wǎng)絡(luò)協(xié)議，發(fā)送者最終會發(fā)現(xiàn)傳輸超時，要求重新傳輸數(shù)據(jù)。

×數(shù)據(jù)拷貝消耗。一些系統(tǒng)（如BSD UNIX），把隊列層放到了用戶和內(nèi)核之間的保護(hù)邊界上。為了分離不同的保護(hù)域，一般使用拷貝數(shù)據(jù)的方法。然而，這增加了系統(tǒng)總線和內(nèi)存的負(fù)擔(dān)。當(dāng)大數(shù)據(jù)量的消息傳輸?shù)臅r候，這可能會降低很大的性能。
一種減少數(shù)據(jù)拷貝的方式：分配一個專用的內(nèi)存區(qū)，這個內(nèi)存區(qū)被同步任務(wù)層和異步任務(wù)層共享[7]。這樣，兩層之間可以高效率的交換數(shù)據(jù)，不需要拷貝。例如 [8]，存在一個I/O子系統(tǒng)，使用輪詢的中斷機(jī)制改進(jìn)連續(xù)的I/O流處理，最小化跨邊界數(shù)據(jù)傳送消耗。這種方法同時提供了一個緩存管理系統(tǒng)，準(zhǔn)許高效率的頁影射，一個由用戶進(jìn)程，內(nèi)核，設(shè)備使用的共享內(nèi)存機(jī)構(gòu)。

9 例子代碼
這節(jié)說明兩個使用半同步半異步模式的例子，這是在BSD UNIX中兩個不同部分。這些例子將說明：半同步半異步模式如果讓用戶進(jìn)程同步操作，讓內(nèi)核進(jìn)程異步操作。第一個例子，在網(wǎng)絡(luò)子系統(tǒng)中使用這個模式，在以太網(wǎng)上處理通過TCP/IP協(xié)議棧輸入的數(shù)據(jù)。第二個例子，在文件系統(tǒng)上使用這個模式，在磁盤控制器上實現(xiàn)一個中斷驅(qū)動的輸出過程。

9.1 BSD網(wǎng)絡(luò)子系統(tǒng)的例子
這個例子說明了如何把半主動半自動模式應(yīng)用與read系統(tǒng)調(diào)用，實現(xiàn)同步的操作。異步地接收和處理到達(dá)網(wǎng)絡(luò)接口的數(shù)據(jù)，同步完成read的調(diào)用。圖一 說明了BSD UNIX中，這個模式的參與者和結(jié)構(gòu)。關(guān)于BSD UNIX網(wǎng)絡(luò)子系統(tǒng)的完整解釋，請參考[9].

9.1.1同步調(diào)用
考慮一個用戶進(jìn)程，創(chuàng)建了一個被動模式的TCP流套接口，從連接的套接口描述子中接收TCP數(shù)據(jù)。對用戶進(jìn)程來說，read系統(tǒng)調(diào)用就是一個同步的操作，進(jìn)程調(diào)用然后數(shù)據(jù)返回。當(dāng)read被調(diào)用時，它進(jìn)入操作系統(tǒng)內(nèi)核，進(jìn)入網(wǎng)絡(luò)套接口的實現(xiàn)代碼。最終，控制線程會進(jìn)入soreceive函數(shù)，這個函數(shù)完成半同步部分的處理。soreceive負(fù)責(zé)把套接口隊列的數(shù)據(jù)傳遞給用戶。它必須能夠處理多種類型的套接口（如數(shù)據(jù)報套接口和流套接口）。下面是簡化后的樣子，重點(diǎn)強(qiáng)調(diào)了同步和異步任務(wù)層之間的邊界。
/* Receive data from a socket. */
int soreceive ( ... )
{
??? for (;;) {
??????? sblock (...); /* lock socket recv queue */
??????? /* mask off network interrupts to protect queue */
??????? s = splnet ();
??????? if (not enough data to satisfy read request) {
??????????? sbunlock (...); /* unlock socket queue */
??????????? /***** Note! *****
??????????? * The following call forms the boundary
??????????? * between the Sync and Async layers. */
??????????? sbwait (...); /* wait for data */
??????????? splx (s); /* drop splnet */
??????? }
??????? else
??????????? break;
??? }
??? splx (s); /* drop splnet */
??? /* copy data to user’s buffer at normal priority */
??? uiomove (...);
??? s = splnet (); /* mask off network interrupts */
??? sbunlock (...); /* unlock socket queue */
??? splx (s); /* restore spl */
??? return (error code); /* returns 0 if no error */
}

上面的代碼展示了同步的用戶進(jìn)程和異步的內(nèi)核進(jìn)程之間的邊界。用戶進(jìn)程可以阻塞等待數(shù)據(jù)，內(nèi)核卻不能被掛起，因為其它的用戶進(jìn)程或硬件設(shè)備需要它的服務(wù)。

soreceive處理read的請求有多種方式，這取決于套接口的屬性和當(dāng)前隊列中的數(shù)據(jù)。

×完全同步。如果用戶請求的數(shù)據(jù)已經(jīng)在套接口隊列中，數(shù)據(jù)將被立即取出，同步地完成操作。

×半同步半異步。如果請求的數(shù)據(jù)還沒有到達(dá)內(nèi)核，內(nèi)核將調(diào)用sbwait函數(shù)，讓用戶進(jìn)程阻塞至數(shù)據(jù)到達(dá)。

一旦sbwait讓進(jìn)程進(jìn)入隨眠狀態(tài)，操作系統(tǒng)的調(diào)度者會立即把上下文切換到其它進(jìn)程運(yùn)行。但原來的用戶進(jìn)程看起來，read系統(tǒng)調(diào)用是同步執(zhí)行的。當(dāng)包含數(shù)據(jù)的包到達(dá)內(nèi)核時，將被異步處理，見9.1.2的描述。當(dāng)足夠多的數(shù)據(jù)到達(dá)隊列后，內(nèi)核將喚醒原來的進(jìn)程進(jìn)行處理。

9.1.2 異步數(shù)據(jù)接收和協(xié)議處理
當(dāng)異步數(shù)據(jù)包到達(dá)網(wǎng)絡(luò)接口的時候，半異步部分啟動。所有輸入的包在中斷處理例程中處理。中斷處理，沒有進(jìn)程上下文也沒有控制線程，這期間是不能睡眠（被阻塞）的。因此，一個中斷處理例程必須借用調(diào)用者所在的控制線程（例如，它的運(yùn)行棧和寄存器）執(zhí)行。BSD UNIX 內(nèi)核使用這個策略，借用發(fā)起系統(tǒng)調(diào)用的用戶線程。

許多中斷驅(qū)動的計算機(jī)給中斷分配優(yōu)先級。例如，在SPARC體系中，一共有15個中斷級別，最低的是Level 1 最高的是Level 15。其它的處理器有不同的級別數(shù)（例如，Motorola 68030有7個中斷級別）。在BSD UNIX中，設(shè)計了與機(jī)器無關(guān)的中斷級別，叫SPL級別（SPL這個詞原于古老的PDP-11機(jī)器上的UNIX系統(tǒng)），把每個處理器特有的級別將影射到這個SPL級別上。例如，最高的網(wǎng)絡(luò)中斷級別為SPLIMP，時鐘中斷為SPLCLOCK，最高的系統(tǒng)中斷級別是SPLHIGH。每一個中斷級別對應(yīng)一個函數(shù)名字，這個函數(shù)完成處理器對應(yīng)中斷級別的設(shè)置。所以，函數(shù)splimp調(diào)用后，將把所有的網(wǎng)絡(luò)硬件中斷排除在外。所有的spl*函數(shù)返回上一個處理器級別，這個值供恢復(fù)使用。

傳統(tǒng)的BSD UNIX版本使用兩級的中斷結(jié)構(gòu)進(jìn)行數(shù)據(jù)包的處理。硬件級關(guān)鍵處理在高級別（SPLIMP）上完成，較不關(guān)鍵的軟件處理在低級別（SPLNET）上完成。這種兩個級別的體系，防止軟件協(xié)議處理的過度消耗對硬中斷處理造成延時。兩個級別的包處理體系自然分成了兩部分：硬件相關(guān)的處理和軟件協(xié)議處理。當(dāng)一個包到達(dá)網(wǎng)絡(luò)接口時，產(chǎn)生那個接口級別的中斷，所有網(wǎng)絡(luò)接口的中斷優(yōu)先級<=SPLIMP。操作系統(tǒng)處理硬件的中斷，把進(jìn)入的數(shù)據(jù)包交給協(xié)議層處理（如IP協(xié)議）。當(dāng)硬中斷的處理完成，并且沒有其它的未處理完的高級別中斷，較低級別的軟件中斷（SPLNET）開始進(jìn)行剩余的協(xié)議的處理。BSD的內(nèi)核被小心的設(shè)計，保證在軟中斷處理的過程中，如果又發(fā)生硬中斷，不會造成數(shù)據(jù)丟失和緩存被破壞的情況。

考慮一個例子，一個主機(jī)安裝了AMD LANCE的以太網(wǎng)卡，這個設(shè)備的驅(qū)動名字叫“l(fā)e”。當(dāng)數(shù)據(jù)到達(dá)的時候，中斷處理中l(wèi)erint函數(shù)被調(diào)用。它的工作是確認(rèn)和清除中斷，從包中提取數(shù)據(jù)，把數(shù)據(jù)拷貝到名字為mbuf的內(nèi)存緩存區(qū)。如下：
int lerint (...)
{
/* perform hardware sanity checks */
while (inbound buffers to process) {
???? /* get length and clear interrupt ... */
???? /* read the packet into mbufs */
???? ether_input (interface, ether_type, packet);
???? /* free buffer */
}
}

mbuf被傳遞給以太函數(shù)ether_init
int ether_input (char *intf, int etype, struct mbuf *packet)
{
?? switch (etype) {
????? case ETHERTYPE_IP:
????? /* schedule network interrupt */
?????? schednetisr (NETISR_IP);
?????? inq = &ipintrq;
????? break;
????? /* etc... */
?? }
?? s = splimp ();
?? /* Try to insert the packet onto the IP queue. */
?? if (IF_QFULL (inq)) {
????? /* queue full, drop packet */
????? IF_DROP (inq);
????? m_freem (packet);
?? }else
????? /* queue packet for net interrupt */
????? IF_ENQUEUE (inq, m);
????? splx (s);
}

每一個網(wǎng)絡(luò)協(xié)議擁有一個數(shù)據(jù)包隊列（例如，IP 包隊列），ether_input函數(shù)先檢測應(yīng)該使用哪一個網(wǎng)絡(luò)協(xié)議，把數(shù)據(jù)包入隊到正確的協(xié)議的隊列中。然后，一個軟中斷發(fā)生，這個中斷是較低的SPLNET級別。到了這里，硬件中斷的處理已經(jīng)完成，中斷服務(wù)例程退出。

硬中斷完成后，當(dāng)沒有更高級別中斷的時候，SPLNET級別的軟中斷發(fā)生。如果輸入的數(shù)據(jù)包是一個IP數(shù)據(jù)包，內(nèi)核將調(diào)用IP中斷例程（ipintr）。在這個例程中進(jìn)行IP協(xié)議的處理（如：消息頭解析，包轉(zhuǎn)發(fā)，分解和重組）。如果數(shù)據(jù)包確定要發(fā)給本機(jī)的進(jìn)程，把數(shù)據(jù)包傳遞給傳輸層。傳輸層會進(jìn)行更多的協(xié)議處理（如TCP協(xié)議級的重組和確認(rèn)）。最終傳輸層把數(shù)據(jù)放到套接口隊列中，調(diào)用sbwakeup，這個調(diào)用將喚醒原來的用戶進(jìn)程，這個進(jìn)程之前在 soreceive調(diào)用中阻塞。當(dāng)這些工作完成，軟中斷的包處理完成。

下面的代碼對ipintr的處理流程進(jìn)行了說明，從tcp_input,到sowakeup，組成了同步和異步層的邊界，第一個函數(shù)ipintr，處理輸入的數(shù)據(jù)包。
int ipintr (...)
{
?? int s;
?? struct mbuf *m;
?? /* loop, until there are no more packets */
?? for (;;) {
???? s = splimp ();
???? IF_DEQUEUE (&ipintrq, m); /* dequeue next packet */
???? splx(s);
???? if (m == 0) return; /* return if no more packets */
???? if (packet not for us) {
???????? /* route and forward packet */
???? } else {
??????? /* packet for us... reassemble */
??????? /* call protocol input, which is tcp_input() */
??????? (*inetsw[ip_protox[ip->ip_p]].pr_input)(m, hlen);
???? }
?? }
}

在我們的例子中，要處理的是一個TCP/IP的包，inetsw函數(shù)會根據(jù)判斷結(jié)果調(diào)用tcp_input函數(shù)。這個函數(shù)處理一個輸入的TCP數(shù)據(jù)包。
int tcp_input (m, iphlen)
{
?? /* lots of complicated protocol processing... */
?? /* We come here to pass data up to the user */
?? sbappend (&so->so_rcv, m);
?? sowakeup((so), &(so)->so_rcv);
?? /* ... */
}

函數(shù)sowakeup將喚醒在read調(diào)用中睡眠的用戶進(jìn)程，這個進(jìn)程之前一直在等待數(shù)據(jù)包的到達(dá)。在下面一節(jié)的討論中將會看到，這個函數(shù)組成了同步和異步層的邊界。

9.1.3 同步階段的完成
當(dāng)數(shù)據(jù)添加到隊列后，如果有一個用戶進(jìn)程正在睡眠中等待這個數(shù)據(jù)，sowakeup函數(shù)將被調(diào)用。
void sowakeup (so, sb)
{
?? /* ... */
?? if (a user process is asleep on this queue) {
????? /***** Note! *****
????? The following call forms the boundary
????? between the Async and Sync layers. */
????? wakeup ((caddr_t) &sb->sb_cc);
?? }
}

當(dāng)一個進(jìn)程陷入睡眠后，進(jìn)程會和一個“Handle”綁定在一起。要喚醒這個睡眠的進(jìn)程，wakeup以這個Handle為參數(shù)。一個等待事件的線程，一般使用和這個事件相關(guān)的數(shù)據(jù)結(jié)構(gòu)的地址作為Handle。在我們的例子中，套接口接收隊列的地址（sb->sc_cc）作為Handle。

如果套接口隊列上沒有等待數(shù)據(jù)的進(jìn)程，什么也不會發(fā)生。在我們的例子中，如9.1.1的說明，原來的進(jìn)程阻塞在soreceive調(diào)用上。內(nèi)核將要喚醒這個進(jìn)程，它循環(huán)檢測是否有足夠多的數(shù)據(jù)到達(dá)供read使用。如果足夠的數(shù)據(jù)到達(dá)，soreceive把數(shù)據(jù)拷貝到用戶的緩沖區(qū)，系統(tǒng)調(diào)用read將會返回。

對應(yīng)用戶進(jìn)程，read調(diào)用看起來就是同步的。然而，這不過是半同步半異步模式造成的幻覺。特別地，異步進(jìn)程和上下文的切換，在用戶進(jìn)程睡眠的過程中默默地發(fā)生。注意，內(nèi)核不會阻塞，會一直在干活，總有一些東西在運(yùn)行，哪怕是空閑進(jìn)程行。

9.2 磁盤控制器的例子
這個例子說明了在BSD UNIX的文件子系統(tǒng)中使用半主動半被動模式的情況。上面的例子說明了這個模式中，數(shù)據(jù)在網(wǎng)絡(luò)接口卡輸入通過TCP/IP的協(xié)議棧一直傳遞到用戶進(jìn)程。下面這個例子將說明如何輸出數(shù)據(jù)，數(shù)據(jù)來自用戶的進(jìn)程，通過了BSD UNIX 的I/O子系統(tǒng)， 最后到達(dá)磁盤。
訪問UNIX的磁盤類的存儲設(shè)備，有兩種方式。一種是通過/dev下的塊設(shè)備文件，另外一種是通過字符設(shè)備文件。通過塊設(shè)備文件訪問的時候，要通過一個軟件實現(xiàn)的磁盤塊緩存區(qū)。與此相反，通過字符設(shè)備（叫“raw”I/O）訪問的時候，會繞過緩存系統(tǒng)直接進(jìn)行I/O操作。掛接一個文件系統(tǒng)前，Raw I/O往往用來做完整性檢查。一些用戶級別的數(shù)據(jù)庫，想自己實現(xiàn)磁盤緩存機(jī)制，也會使用raw I/O。

9.2.1 同步調(diào)用
如果一個進(jìn)程打開一個字符設(shè)備文件（例如：/dev/rdk0a），進(jìn)行一個寫動作，當(dāng)設(shè)備驅(qū)動真正完成寫動作后才會結(jié)束。這是半同步的處理部分，多數(shù)原始磁盤設(shè)備有一個write動作的執(zhí)行入口點(diǎn)，入口點(diǎn)作為一個全局I/O的例程存儲在全局的cdevsw向量中。如下所示。
/* Do a write on a device for a user process. */
int raw_write (dev_t dev, struct uio *uio)
{
??? return physio (cdevsw[major(dev)].d_strategy,
?????????????????? (struct buf *) NULL,
?????????????????? dev, B_WRITE, minphys, uio);
}

這個函數(shù)同步調(diào)用了physio，physio在用戶進(jìn)程的請求下完成物理I/O動作，物理I/O直接從裸設(shè)備寫入到用戶緩存區(qū)，繞過系統(tǒng)的高速緩存。如下實現(xiàn)
int physio (int (*strategy)(),
??????????? struct buf *bp,
??????????? dev_t dev,
??????????? int flags,
??????????? u_int (*minphys)(),
??????????? struct uio *uio)
{
??? struct iovec *iovp;
??? struct proc *p = curproc;
??? int error, done, i, nobuf, s, todo;
??? /* ... */
??? /* read and write, from above */
??? flags &= B_READ | B_WRITE;
??? bp->b_flags = B_BUSY | B_PHYS | B_RAW | flags;
??? /* call driver's strategy to start the transfer */
??? (*strategy) (bp);
??? /***** Note! *****
???? The following call forms the boundary
???? between the Sync and Async layers. */
???? while ((bp->b_flags & B_DONE) == 0)
???????? /* Wait for the transfer to complete */
???????? tsleep ((caddr_t) bp, PRIBIO + 1, "physio", 0);
???? /* ... */
}

這個physio例程使用一個用戶緩沖區(qū)，一個設(shè)備和設(shè)備的strategy函數(shù)指針作為參數(shù)。這個例程的任務(wù)是：發(fā)起一個讀或?qū)懖僮?#xff0c;然后立即返回。因為執(zhí)行用戶緩沖去的指針是用戶提供的，第一步必須認(rèn)。一旦確認(rèn)，就把緩沖區(qū)封裝到一個buf的結(jié)構(gòu)體中。buf結(jié)構(gòu)體的標(biāo)志被設(shè)置說明其是一個寫還是一個讀操作。同時有標(biāo)志說明了這是一個raw I/O的操作。當(dāng)buf的結(jié)構(gòu)體設(shè)置好，就傳遞到strategy，這個例程調(diào)度I/O操作并返回。下一步，physio睡眠直到I/O操作完成。

9.2.2 異步處理
帶緩存的和raw I/O的請求，都是同步的進(jìn)入設(shè)備的驅(qū)動，通過strategy函數(shù)。
void strategy (struct buf *bp)
{
/* ... */
s = splbio (); /* protect the queues */
/* sort the buffer structure into the
driver's queue (e.g., using disksort()) */
if (drive is busy) { splx (s); return; }
????? /* flow control is here.... if the
????? drive is busy the request stays in the queue */
????? /* start first request on the queue */
????? /* done! */
????? splx (s);
????? return;
}
strategy被設(shè)計成通用的函數(shù)，大部分設(shè)備的I/O都使用這個接口。上面的例子假定驅(qū)動一次只處理一個請求。一個設(shè)備可能在一個時間處理多個請求，在這種情況下，需要使用多個列表保存哪一個緩存區(qū)是激活的，哪一個正在等待I/O。???????????
??????????
9.2.3 同步完成階段。
當(dāng)磁盤控制器完成操作后，會產(chǎn)生中斷。這將觸發(fā)一個中斷處理例程，這個例程聯(lián)系了同步任務(wù)層和異步任務(wù)層。如下面的代碼
int intr (void *v)
{
???? struct buf *bp;
???? /* get current request into "bp" */
???? /***** Note! *****
????? The following ties the Async layer back
????? into the Sync layer. */
???? biodone (bp); /* Wakeup the sleep in physio(). */
???? /* start next request on queue */
???? return (1); /* done */
}

這個中斷處理函數(shù)，完成中斷服務(wù)并清除硬件中斷。查看驅(qū)動的狀態(tài)表檢測一個I/O是不是完成。一個I/O的請求使用異步buf結(jié)構(gòu)描述，一旦boidone函數(shù)被調(diào)用，將通知高一級的內(nèi)核軟件，write請求已經(jīng)完成。這會導(dǎo)致進(jìn)程的tsleep調(diào)用返回。

10 變化
使用半同步半異步模式的傳統(tǒng)方式是：來自異步任務(wù)層的輸入使用“pash-driver”的I/O，來自同步任務(wù)層的輸入使用“pull-driver”的I/O，處理輸出使用相反的方式。在一些系統(tǒng)中有下面的變化。

×組合異步通知和同步I/O。當(dāng)數(shù)據(jù)在排隊層緩存后，通知同步層。UNIX的SIGIO就是實現(xiàn)的這種信號驅(qū)動的I/O。在這種情況下，一個信號發(fā)給上層的用戶進(jìn)程，然后用戶進(jìn)程使用read讀出數(shù)據(jù)。

×當(dāng)要求異步處理的時候新產(chǎn)生線程。組合異步通知和同步I/O的另外一種方式，當(dāng)異步事件發(fā)生的時候產(chǎn)生一個新的線程。

× 在上層任務(wù)中使用異步I/O。一些系統(tǒng)擴(kuò)展了原來的模型，準(zhǔn)許把傳遞數(shù)據(jù)的通知發(fā)給上層任務(wù)。UNIX SYSTEM V 的第4版本使用這種方法擴(kuò)展了信號接口。一個緩沖區(qū)指針作為信號處理函數(shù)的參數(shù)傳遞。Windows NT 使用重疊I/O的方式實現(xiàn)了相似的結(jié)構(gòu)。這種結(jié)構(gòu)中，一個異步事件中包含一個重疊的IO結(jié)構(gòu)，結(jié)構(gòu)中包含完成事件的標(biāo)識和對應(yīng)的數(shù)據(jù)。

× 底層任務(wù)實現(xiàn)同步的I/O。單線程的操作系統(tǒng)（如BSD UNIX）。通常只對上層的任務(wù)使用混合的同步/異步模型。在這些系統(tǒng)中，底層的任務(wù)必須嚴(yán)格的使用異步I/O。如果使用線程實現(xiàn)上下文切換，系統(tǒng)準(zhǔn)許在內(nèi)核中使用同步的I/O。在高性能的媒體系統(tǒng)中，使用一個內(nèi)核線程在固定的時間輪詢共享內(nèi)存特定的域，使用這種輪詢的中斷機(jī)制，可以減少上下文切換。
如果異步任務(wù)層擁有自己的控制線程，他可以自動運(yùn)行把消息通過隊列層傳遞給同步任務(wù)層。微內(nèi)核操作系統(tǒng)一般使用這種設(shè)計。在微內(nèi)核中使用一個獨(dú)立的進(jìn)程和用戶進(jìn)程交換數(shù)據(jù)。

11 Known Uses
×The BSD UNIX networking subsystem [1] and the original System V UNIX STREAMS communication framework [12] use the Half-Sync/Half-Async pattern to structure the concurrent I/O architecture of user processes and the OS kernel. All I/O in these kernels is asynchronous and triggered by interrupts. The Queueing layer is implemented by the Socket layer in BSD and by STREAM heads in System V STREAMS. I/O for user processes is synchronous. Most UNIX applications are developed as user processes that call the synchronous higher-level read/write interfaces. This design shields developers from the complexity of asynchronous OS handled by the kernel. There are provisions for notifications (via the SIGIO signal) that asynchronously trigger synchronous I/O.
×The multi-threaded version of Orbix 1.3 (MT-Orbix) [13] uses several variations of the Half-Sync/Half-Async pattern to dispatch CORBA remote operations in a concurrent server. In the Asynchronous layer of MTOrbix a separate thread is associated with each HANDLE that is connected to a client. Each thread blocks synchronously readingCORBArequests from the client. When a request is received it is formatted and then enqueued at the Queueing layer. An active object thread in the Synchronous layer then wakes up, dequeues the request, and processes it to completion by performing an upcall on the CORBA object implementation.
×The Motorola Iridium system uses the Half-Sync/Half-Async pattern in an application-level Gateway that routes messages between satellites and ground control stations [14]. The Iridium Gateway implements the Half-Sync/Half-Async pattern with the ADAPTIVE Service eXecutive (ASX) framework [15]. The Reactor [6] class category from the ASX framework implements an object-oriented demultiplexing and dispatching mechanism that handles events asynchronously. The ASX Message Queue class implements the Queueing layer, and the ASX Task class implements active objects in the Synchronous task layer.
×The Conduit communication framework [16] from the Choices OS project [17] implements an object-oriented version of the Half-Sync/Half-Async pattern. User processes are synchronous active objects, an Adapter Conduit serves as the Queueing layer, and the Conduit micro-kernel operates asynchronously.?

12 Related Patterns
×The Synchronous task layer uses the Active Object pattern[3].（這個模式，我也已經(jīng)翻譯了）
×The Asynchronous task layer may use the Reactor pattern [6] to demultiplex events from multiple sources of events.
×The Queueing layer provides a Facade [18] that simplifies the interface to the Asynchronous task layer of the system.
×The Queueing layer is also a Mediator [18] that coordinates the exchange of data between the Asynchronous and Synchronous task layers.

Acknowledgements
We would like to thank Lorrie Cranor and Paul McKenney for comments and suggestions for improving this paper.

References

[1] S. J. Leffler,M.McKusick,M. Karels, and J.Quarterman, The Design and Implementation of the 4.3BSD UNIX Operating System. Addison-Wesley, 1989.

[2] D. C. Schmidt and T. Suda, "Measuring the Performance of Parallel Message-based Process Architectures," in Proceedings of the Conference on Computer Communications (INFOCOM),(Boston, MA), pp. 624-633, IEEE, April 1995.

[3] R. G. Lavender and D. C. Schmidt, "Active Object: an Object Behavioral Pattern for Concurrent Programming," in Proceedings of the 2nd Annual Conference on the Pattern Languages of Programs, (Monticello, Illinois), pp. 1-7, September 1995.

[4] N. C. Hutchinson and L. L. Peterson, "The x-kernel: An Architecture for ImplementingNetwork Protocols," IEEE Transactions on Software Engineering, vol. 17, pp. 64-76, January 1991.

[5] D. C. Schmidt, T. H. Harrison, and E. Al-Shaer, "Object-Oriented Components for High-speed Network Programming,"in Proceedings of the 1st Conference on Object-Oriented Technologies and Systems, (Monterey, CA),USENIX, June 1995.

[6] D. C. Schmidt, "Reactor: An Object Behavioral Pattern for Concurrent Event Demultiplexing and Event Handler Dispatching," in Pattern Languages of Program Design (J. O.Coplien and D. C. Schmidt, eds.), Reading, MA: Addison-Wesley, 1995.

[7] P. Druschel and L. L. Peterson, "Fbufs: A High-Bandwidth Cross-Domain Transfer Facility," in Proceedings of the 14th Symposium on Operating System Principles (SOSP), Dec.1993.

[8] C. Cranor and G. Parulkar, Design of Universal Continuous Media I/O, in Proceedings of the 5th InternationalWorkshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV (Durham, New Hampshire),pp. 83-86, Apr. 1995.

[9] W. R. Stevens, TCP/IP Illustrated, Volume 2. Reading, Massachusetts:AddisonWesley, 1993.

[10] H. Custer, Inside Windows NT. Redmond, Washington: MicrosoftPress, 1993.

[11] D. L. Black, "Scheduling Support for Concurrency and Parallelism in the Mach Operating System, IEEE Computer,vol. 23, pp. 23-33,May 1990.

[12] D. Ritchie, A Stream Input-Output System,"AT&TBell Labs Technical Journal, vol. 63, pp. 311-314,Oct. 1984.

[13] C. Horn, "The Orbix Architecture," tech. rep., IONA Technologies,August 1993.

[14] D. C. Schmidt, A Family of Design Patterns for Applicationlevel Gateways," The Theory and Practice of Object Systems (Special Issue on Patterns and Pattern Languages), vol. 2, no. 1, 1996.

[15] D. C. Schmidt, "ACE: an Object-Oriented Framework for Developing Distributed Applications, Proceedings of the 6th USENIX C++ Technical Conference, (Cambridge, Massachusetts),USENIX Association, April 1994.

[16] J. M. Zweig, "The Conduit: a Communication Abstraction in C++," in Proceedings of the 2nd USENIX C++ Conference,pp. 191-203,USENIX Association, April 1990.

[17] R. Campbell, N. Islam, D. Raila, and P. Madany, "Designing and Implementing Choices: an Object-Oriented System in C++," Communications of the ACM, vol. 36, pp. 117-126,Sept. 1993.

[18] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software.Reading,MA: Addison-Wesley, 1995.

總結(jié)

以上是生活随笔為你收集整理的半同步半异步模式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。