半同步半異步模式
一個架構模式，清晰的結構,高效并發的I/O

譯者:

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

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

1 意圖
在系統中分離了同步I/O和異步I/O的兩個過程，既簡化了并行程序實現的復雜，又不會影響執行的效率。

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

在這個體系中，操作系統內核響應設備的中斷，執行異步的I/O。而用戶級的應用程序進行同步的I/O。這正是“半同步半異步”這個名字的由來，這個結構滿足下面的兩個需要：

編程實現簡單。異步I/O模型中，中斷隨時觸發輸入和輸出操作，編程復雜。使用異步I/O模型，當中斷處理例程擁有線程控制權時,會產生非常麻煩的時序和竟爭問題。而且，使用中斷機制的程序要求額外的數據結構，這個數據結構用于在異步事件發生的時候保存進程上下文狀態。并且，程序執行的時候，外部的事件會在不固定的時間發生，程序不容易調試。

與其相比，使用同步I/O模型的時候，I/O操作在確定的點發生，編程實現要容易的多。此外，同步I/O操作的程序會阻塞等待I/O操作的完成。進程運行上下文的活動記錄自動在運行棧中保存，不必使用獨立的數據結構。因此，為了讓編程簡單，有強烈的理由使用同步I/O模型。

程序執行高效。在中斷驅動的設備上，異步I/O模型運用帶來了高效率。異步I/O讓通信和計算同時進行。并且，因為程序運行狀態的數據量相對較小，上下文切換的消耗被最小化[2]。因此，為了提高運行的性能，也有強烈理由使用異步I/O模型。

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

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

4 應用?
半同步半異步模式在下面的場景中使用。

× 一個系統中的進程有下面的特征：
系統必須響應和處理外部異步發生的事件，
如果為每一個外部資源的事件分派一個獨立的線程同步處理I/O，效率很低。
如果上層的任務以同步方式處理I/O，實現起來簡單。

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

5 結構和組成單元
圖二顯示了半同步半異步模式的組成結構。這些組成單元如下描述

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

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

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

×外部事件源（網絡接口）
外部設備產生事件，產生的事件先被異步任務層接收和處理。

6 協作
圖三展現了一個動態的過程：當外部事件到達后，半同步半異步模式的各個組成單元協作和處理。把協作的過程分成下面三個階段：

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

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

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

7 結果
半同步半異步模式有下面的優點

×上層的任務被簡化，這是因為不需要再面對底層的異步I/O。復雜的并發控制，中斷處理和計時操作都委托給異步任務層。異步層負責處理底層的細節，如，異步系統編程的中斷處理。異步任務層管理與硬件相關的組件間（如DMA，內存管理，設備寄存器）的交互。

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

×層間的通信被限制在單獨的一點，因為所有的交互使用隊列層協調。隊列層對兩層之間的消息進行緩存。如果直接通信，同步和異步任務層直接訪問對方的內存，就必須使用復雜的鎖和時序控制。

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

半同步半異步模式有下面的缺點

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

×上層任務缺少異步I/O的實現。依賴與系統接口的設計，可能導致上層無法直覺使用低層的異步I/O設備。因此，如果外部的設備支持異步的重疊的I/O方式，系統的I/O結構會防礙應用程序高效的使用。

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

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

× 使用反應堆模式[6]實現多路事件的處理，反應堆模式使用一個單線程的處理循環，把多路的事件派發給多個處理者。這個模式組合了單線程處理循環的簡單性和面向對象編程提供的可擴展性。反應堆模式在一個線程（或進程）中進行順序的消息處理，常用來消除多線程同步和加鎖處理的復雜性。
一個反應堆可以使用在同步或者異步的事件源上。但是它支持的事件處理者的行為要求是異步的。也就是說，為了不影響其它事件源的響應效率，事件處理者是不能阻塞的。

×實現一個多級的中斷處理機構。這種機構下，當更高級別的任務（如硬中斷）要求處理的時候，當前的進程可以被中斷。為了防止共享的狀態訪問時被破壞，異步層使用的數據結構必須被保護（例如提升處理器級別或使用信號量）。

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

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

× 并行控制。如果同步任務和異步任務的執行是并行的（如論使用多CPU還是硬件中斷），為了避免爭用，共享的隊列的狀態變化必須是連續的。因此，實現隊列層的時候，經常使用并行控制機制，如信號量，互斥體和條件變量等。當消息在隊列中插入或刪除的時候，并行控制保證隊列的內部數據結構不被破壞。

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

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

9 例子代碼
這節說明兩個使用半同步半異步模式的例子，這是在BSD UNIX中兩個不同部分。這些例子將說明：半同步半異步模式如果讓用戶進程同步操作，讓內核進程異步操作。第一個例子，在網絡子系統中使用這個模式，在以太網上處理通過TCP/IP協議棧輸入的數據。第二個例子，在文件系統上使用這個模式，在磁盤控制器上實現一個中斷驅動的輸出過程。

9.1 BSD網絡子系統的例子
這個例子說明了如何把半主動半自動模式應用與read系統調用，實現同步的操作。異步地接收和處理到達網絡接口的數據，同步完成read的調用。圖一 說明了BSD UNIX中，這個模式的參與者和結構。關于BSD UNIX網絡子系統的完整解釋，請參考[9].

9.1.1同步調用
考慮一個用戶進程，創建了一個被動模式的TCP流套接口，從連接的套接口描述子中接收TCP數據。對用戶進程來說，read系統調用就是一個同步的操作，進程調用然后數據返回。當read被調用時，它進入操作系統內核，進入網絡套接口的實現代碼。最終，控制線程會進入soreceive函數，這個函數完成半同步部分的處理。soreceive負責把套接口隊列的數據傳遞給用戶。它必須能夠處理多種類型的套接口（如數據報套接口和流套接口）。下面是簡化后的樣子，重點強調了同步和異步任務層之間的邊界。
/* 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 */
}

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

soreceive處理read的請求有多種方式，這取決于套接口的屬性和當前隊列中的數據。

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

×半同步半異步。如果請求的數據還沒有到達內核，內核將調用sbwait函數，讓用戶進程阻塞至數據到達。

一旦sbwait讓進程進入隨眠狀態，操作系統的調度者會立即把上下文切換到其它進程運行。但原來的用戶進程看起來，read系統調用是同步執行的。當包含數據的包到達內核時，將被異步處理，見9.1.2的描述。當足夠多的數據到達隊列后，內核將喚醒原來的進程進行處理。

9.1.2 異步數據接收和協議處理
當異步數據包到達網絡接口的時候，半異步部分啟動。所有輸入的包在中斷處理例程中處理。中斷處理，沒有進程上下文也沒有控制線程，這期間是不能睡眠（被阻塞）的。因此，一個中斷處理例程必須借用調用者所在的控制線程（例如，它的運行棧和寄存器）執行。BSD UNIX 內核使用這個策略，借用發起系統調用的用戶線程。

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

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

考慮一個例子，一個主機安裝了AMD LANCE的以太網卡，這個設備的驅動名字叫“le”。當數據到達的時候，中斷處理中lerint函數被調用。它的工作是確認和清除中斷，從包中提取數據，把數據拷貝到名字為mbuf的內存緩存區。如下：
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被傳遞給以太函數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);
}

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

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

下面的代碼對ipintr的處理流程進行了說明，從tcp_input,到sowakeup，組成了同步和異步層的邊界，第一個函數ipintr，處理輸入的數據包。
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函數會根據判斷結果調用tcp_input函數。這個函數處理一個輸入的TCP數據包。
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);
?? /* ... */
}

函數sowakeup將喚醒在read調用中睡眠的用戶進程，這個進程之前一直在等待數據包的到達。在下面一節的討論中將會看到，這個函數組成了同步和異步層的邊界。

9.1.3 同步階段的完成
當數據添加到隊列后，如果有一個用戶進程正在睡眠中等待這個數據，sowakeup函數將被調用。
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);
?? }
}

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

如果套接口隊列上沒有等待數據的進程，什么也不會發生。在我們的例子中，如9.1.1的說明，原來的進程阻塞在soreceive調用上。內核將要喚醒這個進程，它循環檢測是否有足夠多的數據到達供read使用。如果足夠的數據到達，soreceive把數據拷貝到用戶的緩沖區，系統調用read將會返回。

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

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

9.2.1 同步調用
如果一個進程打開一個字符設備文件（例如：/dev/rdk0a），進行一個寫動作，當設備驅動真正完成寫動作后才會結束。這是半同步的處理部分，多數原始磁盤設備有一個write動作的執行入口點，入口點作為一個全局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);
}

這個函數同步調用了physio，physio在用戶進程的請求下完成物理I/O動作，物理I/O直接從裸設備寫入到用戶緩存區，繞過系統的高速緩存。如下實現
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例程使用一個用戶緩沖區，一個設備和設備的strategy函數指針作為參數。這個例程的任務是：發起一個讀或寫操作，然后立即返回。因為執行用戶緩沖去的指針是用戶提供的，第一步必須認。一旦確認，就把緩沖區封裝到一個buf的結構體中。buf結構體的標志被設置說明其是一個寫還是一個讀操作。同時有標志說明了這是一個raw I/O的操作。當buf的結構體設置好，就傳遞到strategy，這個例程調度I/O操作并返回。下一步，physio睡眠直到I/O操作完成。

9.2.2 異步處理
帶緩存的和raw I/O的請求，都是同步的進入設備的驅動，通過strategy函數。
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被設計成通用的函數，大部分設備的I/O都使用這個接口。上面的例子假定驅動一次只處理一個請求。一個設備可能在一個時間處理多個請求，在這種情況下，需要使用多個列表保存哪一個緩存區是激活的，哪一個正在等待I/O。???????????
??????????
9.2.3 同步完成階段。
當磁盤控制器完成操作后，會產生中斷。這將觸發一個中斷處理例程，這個例程聯系了同步任務層和異步任務層。如下面的代碼
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 */
}

這個中斷處理函數，完成中斷服務并清除硬件中斷。查看驅動的狀態表檢測一個I/O是不是完成。一個I/O的請求使用異步buf結構描述，一旦boidone函數被調用，將通知高一級的內核軟件，write請求已經完成。這會導致進程的tsleep調用返回。

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

×組合異步通知和同步I/O。當數據在排隊層緩存后，通知同步層。UNIX的SIGIO就是實現的這種信號驅動的I/O。在這種情況下，一個信號發給上層的用戶進程，然后用戶進程使用read讀出數據。

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

× 在上層任務中使用異步I/O。一些系統擴展了原來的模型，準許把傳遞數據的通知發給上層任務。UNIX SYSTEM V 的第4版本使用這種方法擴展了信號接口。一個緩沖區指針作為信號處理函數的參數傳遞。Windows NT 使用重疊I/O的方式實現了相似的結構。這種結構中，一個異步事件中包含一個重疊的IO結構，結構中包含完成事件的標識和對應的數據。

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

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].（這個模式，我也已經翻譯了）
×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.

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。