 昨天找來(lái)了原始的pdf文檔，LF.pdf. 硬著(zhù)頭皮讀了幾章，有些地方理解不能，關(guān)鍵是英文太菜了，句子一長(cháng)就不知道說(shuō)什么了。 還是勉強翻譯了一下，還沒(méi)完，15頁(yè)呢，只看了一半，似懂非懂。貼上來(lái)共享下。 翻譯的很爛，有些詞不知道怎么表達，別罵我，多謝。 PS: TMD擺渡總提示我有不合適的詞，瞪著(zhù)眼找了半天居然是"插 入"兩個(gè)字...杯具??！ Leader/Followers 一個(gè)高效的多線(xiàn)程IO多路分離和分發(fā)設計模式 翻譯： 英文超爛的sodarfish 概要 LF設計模式提供了一種并發(fā)模型，它允許多線(xiàn)程高效地進(jìn)行事件的多路分離和分派事件處理過(guò)程，以處理多個(gè)線(xiàn)程共享的IO句柄。 示例 考慮設計一個(gè)多層次的、大容量的、實(shí)時(shí)在線(xiàn)交易處理系統，如下圖，前置通信服務(wù)器將來(lái)自客戶(hù)端的交易請求轉發(fā)到后端數據庫服務(wù)器進(jìn)行處理，客戶(hù)端可以是如旅行社、索賠處理中心或者銷(xiāo)售終端等。該多層模型已經(jīng)通過(guò)負載均衡和冗余的方式來(lái)提升整個(gè)系統的吞吐量和可靠性。 前置通信服務(wù)器是個(gè)名副其實(shí)的”混血兒”，它主要負責兩項任務(wù)。首先，它處理來(lái)自成千上萬(wàn)遠程客戶(hù)端通過(guò)WAN同時(shí)發(fā)來(lái)的請求；其次，它檢測請求的有效性，并將有效請求通過(guò)TCP/IP鏈接發(fā)送到后端數據庫服務(wù)器。相對來(lái)說(shuō)，數據庫服務(wù)器是一個(gè)只處理特定交易的”純粹的”服務(wù)器. 在交易完成之后，數據庫服務(wù)器將結果返回給通信服務(wù)器，進(jìn)而返回給遠程客戶(hù)端。 改進(jìn)OLTP性能的通常策略是使用多線(xiàn)程同時(shí)處理多個(gè)請求。 理論上每個(gè)線(xiàn)程可以獨立地運行，通過(guò)復用OLTP計算相關(guān)的網(wǎng)絡(luò )和磁盤(pán)IO處理，如校驗、索引檢索、表合并，存儲過(guò)程等，以增加整個(gè)系統的吞吐量。 但實(shí)際上,設計一個(gè)令前端和后端進(jìn)行高效IO操作和OLTP處理的多線(xiàn)程模型并不容易。 一種方式是使用基于半同步/半反應(半同步半異步模型的變體)模式的線(xiàn)程池. 在大規模OLTP系統中，IO鏈接數往往比線(xiàn)程數大很多，在這種情況下，像select, poll, waitForMultipleObjects 等事件多路調節器被用于等待一個(gè)socket集合上發(fā)生的事件. 一些特定的多路分離器，例如著(zhù)名的select, poll, 如果被多個(gè)線(xiàn)程在同一個(gè)socket集上調用，將會(huì )發(fā)生問(wèn)題。 為了突破這個(gè)限制，可以給多路分離器設計一個(gè)專(zhuān)有的線(xiàn)程(IO線(xiàn)程)，如下圖所示。當集合中有句柄發(fā)生活動(dòng)時(shí)，事件多路分離器返回控制器給IO線(xiàn)程，并指定哪些句柄即將發(fā)生事件。 IO線(xiàn)程從特定的socket句柄中讀取交易請求，將其存儲到一個(gè)動(dòng)態(tài)分配的命令對象，并插入到一個(gè)消息隊列中，該隊列以監視對象模式實(shí)現。 該隊列由工作線(xiàn)程池提供服務(wù)，當一個(gè)工作線(xiàn)程可用時(shí)，它從隊列中移出一個(gè)命令對象，處理指定的交易，然后給通信服務(wù)器一個(gè)響應。 類(lèi)似的模式也可以應用到前置通信服務(wù)器，單獨的IO線(xiàn)程和工作線(xiàn)程池用于校驗和轉發(fā)請求到后端服務(wù)器。在這個(gè)設計中，前置通信服務(wù)器依然扮演后端服務(wù)器的客戶(hù)端角色，因此，前置機要等待后端返回交易結果。前置機收到結果后，結果必須分配給適當的工作線(xiàn)程。此外，在多層系統中，前端可能在處理前端請求的同時(shí)對后端返回的結果做出響應。因此前置機必須總能夠在處理請求和發(fā)送響應，這意味著(zhù)前置機的工作線(xiàn)程在同一時(shí)間不能全部在阻塞狀態(tài)。 盡管上面的模型被用于許多的并發(fā)應用程序，但是在大容量系統中，例如我們的OLTP例子，它會(huì )帶來(lái)過(guò)度的負荷。例如，即使是很輕的工作量，半同步/半反應線(xiàn)程池的設計也會(huì )導致動(dòng)態(tài)內存分配、多操作同步以及上下文切換，以在工作線(xiàn)程和IO線(xiàn)程之間傳遞命令對象，這會(huì )使最佳響應時(shí)間不必要地變長(cháng)。 此外，如果OLTP服務(wù)器運行在多處理器環(huán)境下，處理器的緩存一致性要求在多個(gè)線(xiàn)程之間傳遞命令對象，這會(huì )導致高負荷情況發(fā)生。 如果OLTP服務(wù)運行在一個(gè)支持異步IO的操作系統上，那么半同步半反應模式的線(xiàn)程池可以被替換為基于Preactor模式的純粹的異步線(xiàn)程池，由于去掉了IO線(xiàn)程，在一定程度上減少了負荷。 許多操作系統不支持異步io,而且即使實(shí)現了，也不見(jiàn)得高效。（貌似現在好多了哈），目前，多線(xiàn)程對于OLTP服務(wù)來(lái)說(shuō)是非常必要的。 背景(上下文) 在應用中，發(fā)生在IO句柄集合上的事件必須被分離并高效的分配到多個(gè)線(xiàn)程。 問(wèn)題 多線(xiàn)程是用于實(shí)現并行處理多IO事件的通用技術(shù). 實(shí)現一個(gè)高性能的多線(xiàn)程應用并不簡(jiǎn)單，無(wú)論如何，要有效的應對這個(gè)問(wèn)題，下面的幾條必須要滿(mǎn)足： 高效的分離IO句柄和線(xiàn)程: 高性能多線(xiàn)程服務(wù)器會(huì )同時(shí)處理多種類(lèi)型的事件，例如連接、讀、寫(xiě)事件。這些事件通常發(fā)生在分配給每個(gè)客戶(hù)端連接的TCP/IP套接字上。關(guān)鍵問(wèn)題是，確定線(xiàn)程和IO句柄直接的高效的關(guān)聯(lián)方式。 對于服務(wù)器程序來(lái)說(shuō)，為每個(gè)IO句柄關(guān)聯(lián)一個(gè)線(xiàn)程是不現實(shí)的，因為此設計可能不會(huì )隨著(zhù)IO句柄的增長(cháng)而有效伸縮。有必要設置一個(gè)較小的、固定數量的線(xiàn)程來(lái)復用大量的IO句柄。相反的，一個(gè)客戶(hù)端程序可能有大量的線(xiàn)程連接到同一個(gè)服務(wù)端，此時(shí)每個(gè)線(xiàn)程一個(gè)連接的方式會(huì )消耗過(guò)多系統資源。因此，將客戶(hù)端的大量線(xiàn)程對少量的連接進(jìn)行復用是必要的，例如，維護一個(gè)單獨的從客戶(hù)端到服務(wù)端的連接。 舉個(gè)例子，如果一個(gè)OLTP服務(wù)器使用每個(gè)線(xiàn)程一個(gè)連接的并發(fā)模型，將無(wú)法處理大量的并發(fā)請求。此時(shí)使用多路復用模型，使用線(xiàn)程池來(lái)令線(xiàn)程數與系統可用資源保持一致，例如CPU數量，而不是令線(xiàn)程數與連接數一致。 同樣地，為了保存系統資源，前端中的每個(gè)線(xiàn)程復用同一個(gè)連接，如圖所示。這樣，當前端收到由后端返回的結果時(shí)，必須分離出結果并交給適當的線(xiàn)程去處理。 減少同步相關(guān)的消耗 要將性能最優(yōu)化，同步相關(guān)消耗的幾個(gè)關(guān)鍵來(lái)源：上下文切換、同步、緩存一致性管理等必須最小化。 實(shí)際上，要求動(dòng)態(tài)的分配內存給每個(gè)請求，并在多個(gè)線(xiàn)程之間傳遞將帶來(lái)大量的消耗（在傳統多處理器操作系統上）。 舉例，我沒(méi)的OLTP例子使用了基于半同步/半反應的并發(fā)模型。它利用一個(gè)消息隊列來(lái)將負責從客戶(hù)端取請求事件的網(wǎng)絡(luò )IO線(xiàn)程解耦， 在工作線(xiàn)程池中，工作線(xiàn)程處理這些事件并返回給客戶(hù)端。 不幸的是，這個(gè)設計要求內存被動(dòng)態(tài)的分配，從IO線(xiàn)程的堆內存或者公共內存區，這樣請求事件才能被加入到消息隊列。另外，它要求若干個(gè)同步和上下文切換來(lái)完成在消息隊列上的加入和移除動(dòng)作。 防止競爭： 多線(xiàn)程在同一個(gè)IO集合上進(jìn)行事件分離，必須協(xié)同以防止競爭條件產(chǎn)生。競爭會(huì )出現在多個(gè)線(xiàn)程同時(shí)訪(fǎng)問(wèn)同種類(lèi)型的IO句柄時(shí)。這可以通過(guò)同步解決，例如互斥體，信號了或者條件變量。 例如，線(xiàn)程池可以用select 來(lái)分離一個(gè)socket集合，當IO事件在同一個(gè)句柄集合上準備就緒時(shí)，操作系統會(huì )錯誤地通知到多個(gè)調用select的線(xiàn)程。此時(shí)，線(xiàn)程池需要進(jìn)行同步，以防止多個(gè)線(xiàn)程同時(shí)讀同一個(gè)socket句柄，這會(huì )導致數據丟失。同樣地，多個(gè)線(xiàn)程同時(shí)寫(xiě)socket句柄，會(huì )導致數據混亂。 解決方案 領(lǐng)倒者/跟隨者模式包括如下幾個(gè)部分: 句柄和句柄集合: 句柄是對IO資源的標識，例如一個(gè)socket連接或打開(kāi)的文件, 通常由操作系統實(shí)現和管理。句柄集合由多個(gè)IO句柄組成，用于監聽(tīng)該集合中包含的句柄上發(fā)生的事件。當集合中某個(gè)句柄上可能發(fā)起一個(gè)非阻塞操作時(shí)，句柄集合將被返回給它的調用者。 例如，OLTP服務(wù)器關(guān)心兩種事件類(lèi)型—連接事件 和 讀事件 –分別代表了接入連接 和 交易請求。 前端和后端程序對每個(gè)客戶(hù)端維護單獨的一條連接。每個(gè)連接在服務(wù)器上表現為一個(gè)單獨的socket句柄。 我們的OLTP服務(wù)器使用select 多路分離器來(lái)確定哪些句柄有即將到來(lái)的事件，對句柄進(jìn)行IO操作而不阻塞它的調用線(xiàn)程。然而由于IO事件會(huì )通知到多個(gè)線(xiàn)程，因此不能讓多線(xiàn)程在同一個(gè)集合上同時(shí)調用select。 事件響應者（event handler）： 事件響應者指定了一個(gè)接口，其由一個(gè)或多個(gè)鉤子函數組成，這些函數描述了對事件句柄上發(fā)生的事件的各個(gè)操作集合。 實(shí)際事件響應者： 是事件響應者的具體實(shí)現。每個(gè)實(shí)際事件響應都與應用中的一個(gè)句柄綁定。 另外，事件響應者實(shí)現了用于處理從句柄上收到的事件的各個(gè)鉤子函數。 例如，OLTP前端程序的事件響應者收到并校驗了客戶(hù)端的請求，并將請求轉發(fā)到后端服務(wù)器。同樣的，后端的事件響應者接受前端發(fā)來(lái)的請求，讀寫(xiě)數據庫記錄來(lái)完成交易，然后將結果返回給前端。 領(lǐng)倒者/跟隨者 線(xiàn)程集合 線(xiàn)程在該模式中扮演多個(gè)角色。 領(lǐng)倒者線(xiàn)程等待句柄集上發(fā)生事件，到時(shí)它處理事件并執行某些類(lèi)型的服務(wù)。 當線(xiàn)程處理完事件后，它將進(jìn)入線(xiàn)程集合進(jìn)行等待。 0個(gè)或者多個(gè)跟隨者線(xiàn)程將排隊等待成為領(lǐng)倒者，或從領(lǐng)倒者線(xiàn)程中接收分配來(lái)的事件。 當前領(lǐng)倒者從句柄中取得一個(gè)事件時(shí)，它將推舉一個(gè)跟隨者線(xiàn)程作為新的領(lǐng)倒者，然后自己處理這個(gè)事件。跟隨者集合可以被隱式地維護，例如，使用信號量或者條件變量；也可以顯式維護，如使用集合類(lèi)。 用哪種方式取決于領(lǐng)倒者是否必須顯式指定某個(gè)特定的線(xiàn)程來(lái)處理事件的跟監。 例如，每個(gè)OLTP后端服務(wù)器都有一個(gè)線(xiàn)程池，每個(gè)線(xiàn)程等待處理交易請求。任何時(shí)候線(xiàn)程們都能在處理請求和發(fā)送數據給前端通信服務(wù)器。最多一個(gè)線(xiàn)程做領(lǐng)倒者，負責監聽(tīng)新的連接和讀事件。 其余的線(xiàn)程都是跟隨者，他們在池中等待被推舉為新的領(lǐng)倒者，或者接收領(lǐng)倒者發(fā)來(lái)的事件。 動(dòng)態(tài) LF模式中各組成部分存在兩種協(xié)作，其依賴(lài)于句柄集合中的IO句柄與線(xiàn)程之間的兩種關(guān)聯(lián)：綁定和非綁定。 非綁定的句柄/線(xiàn)程關(guān)聯(lián)：這種情況下，線(xiàn)程和IO句柄之間沒(méi)有固定的關(guān)聯(lián)，因此，每個(gè)線(xiàn)程都可以處理發(fā)生在任何句柄上的任何事件。這種方式在多個(gè)線(xiàn)程輪流共享句柄集合時(shí)常用。 例如，OLTP后端服務(wù)器的例子在線(xiàn)程池和由select管理的句柄集之間實(shí)現了一個(gè)非綁定關(guān)聯(lián)。 實(shí)際的事件響應者可以在任何一個(gè)線(xiàn)程中執行處理。因此，沒(méi)有必要來(lái)維護線(xiàn)程和句柄之間的關(guān)系。這種情形簡(jiǎn)化了后端程序的開(kāi)發(fā)。 綁定的句柄/線(xiàn)程關(guān)聯(lián)：每個(gè)線(xiàn)程都綁定到它自己的IO句柄上，各自處理特定的事件。當一個(gè)客戶(hù)端線(xiàn)程在socket句柄上等待服務(wù)器對雙向請求的響應時(shí)常用此方式。 這種情況下，客戶(hù)端應用線(xiàn)程希望用一個(gè)特定的線(xiàn)程來(lái)處理該IO句柄上的事件，通常是發(fā)出請求的那個(gè)線(xiàn)程。 例如，前端通信程序中的線(xiàn)程轉發(fā)客戶(hù)請求到后端進(jìn)行處理。為了減少系統資源的消耗，前端的工作線(xiàn)程會(huì )使用多路復用連接于后端通信。當請求發(fā)送后，工作線(xiàn)程等待結果的返回，這種情況下，維護一個(gè)綁定關(guān)系簡(jiǎn)化了前端程序，并減少了交易處理中不必要的上下文管理負荷。（注：即工作線(xiàn)程前端與和后端的連接綁定，長(cháng)連接適用，注意多個(gè)線(xiàn)程不要寫(xiě)同一個(gè)句柄） 上面描述了兩種關(guān)聯(lián)，下面是LF模式中發(fā)生的各種協(xié)作。 1. 領(lǐng)倒者多路分離: 領(lǐng)倒者線(xiàn)程等待句柄集上發(fā)生事件。 2. 跟隨者推舉：根據關(guān)聯(lián)的不同，存在兩種情況： 對于非綁定線(xiàn)程/句柄關(guān)聯(lián)，當領(lǐng)倒者線(xiàn)程分離出事件后，他選擇一個(gè)跟隨者線(xiàn)程做新的領(lǐng)倒（根據后面講到的推舉協(xié)議）。 對于綁定線(xiàn)程/句柄關(guān)聯(lián)，當領(lǐng)倒者分離出事件后，他檢查與該事件關(guān)聯(lián)的句柄，以決定哪個(gè)線(xiàn)程負責處理它。如果領(lǐng)倒者發(fā)現自己負責該事件，就推舉一個(gè)跟隨者作為新領(lǐng)倒（使用和非綁定情況下一樣的協(xié)議）。相反的，如果事件是由其他線(xiàn)程負責，那么領(lǐng)倒者必須將事件移交給預定的跟隨者線(xiàn)程。這個(gè)跟隨者線(xiàn)程隨即將自己從線(xiàn)程集合中注銷(xiāo)，并同時(shí)處理這個(gè)事件。于此同時(shí)，當前的領(lǐng)倒者繼續等待另一個(gè)事件發(fā)生。 3. 事件處理: 對于非綁定關(guān)聯(lián)， 前一個(gè)領(lǐng)倒者線(xiàn)程在推舉完下一個(gè)領(lǐng)倒者后開(kāi)始處理其分離出的事件； 對于綁定關(guān)聯(lián)，或者由前任領(lǐng)倒者處理事件，或者由一個(gè)跟隨者線(xiàn)程處理領(lǐng)倒移交給他的事件。 4. 重加入到 LF 線(xiàn)程集合：為了多路分離句柄集合上的各個(gè)句柄，L/F線(xiàn)程集中必定首先有一個(gè)線(xiàn)程加入(重新加入)。這個(gè)動(dòng)作通常發(fā)生在一個(gè)事件被處理完畢，線(xiàn)程準備處理另外一個(gè)事件時(shí)。如果當前沒(méi)有領(lǐng)倒者，一個(gè)線(xiàn)程可以立刻變?yōu)轭I(lǐng)倒。否則，該線(xiàn)程必須作為跟隨者等待領(lǐng)倒將其提拔。 下圖描述了各個(gè)部分之間的協(xié)作關(guān)系。 在任何時(shí)刻，LF模式中的各成員都處于以下三種狀態(tài)： 領(lǐng)倒者: 當前作為領(lǐng)倒者的線(xiàn)程，其等待事件發(fā)生，當收到事件時(shí)，轉為處理中狀態(tài)。 處理中: 此狀態(tài)的線(xiàn)程可以與領(lǐng)倒者、跟隨者或其他線(xiàn)程同時(shí)執行，通常它會(huì )轉為跟隨者狀態(tài)，如果當他處理完事件時(shí)沒(méi)有領(lǐng)倒者，也可能立刻變?yōu)轭I(lǐng)倒者狀態(tài)。 跟隨者: 此狀態(tài)的線(xiàn)程在線(xiàn)程池中處于等待狀態(tài)，當被當前領(lǐng)倒推舉時(shí)可以轉為領(lǐng)倒者， 或者如果收到領(lǐng)倒者移交來(lái)的事件，他會(huì )立刻轉為處理中狀態(tài)。 下圖描述了狀態(tài)的轉化: 實(shí)現 下面幾個(gè)步驟將實(shí)現L/F模式. 1. 選擇一個(gè)IO句柄和句柄集機制。 句柄集是 IO句柄的集合，用于等待句柄上發(fā)生的事件。 開(kāi)發(fā)者通常選擇由操作系統提供的IO句柄機制，而不是自己白手實(shí)現。下面幾個(gè)子步驟可用于選擇IO句柄和句柄集的機制。 1.1 確定IO句柄的類(lèi)型： 有兩種常用的類(lèi)型： 并發(fā)句柄 這種類(lèi)型的句柄允許多線(xiàn)程并發(fā)的訪(fǎng)問(wèn)它，而不會(huì )由于資源競爭導致崩潰，數據丟失或數據混亂。 例如，Socket API 對面向記錄的(record-oriented)協(xié)議（如UDP）, 允許多線(xiàn)程對同一個(gè)句柄同時(shí)讀寫(xiě)。 迭代(interative重復)句柄: 這種類(lèi)型句柄要求多線(xiàn)程循序地訪(fǎng)問(wèn)它，因為并發(fā)訪(fǎng)問(wèn)會(huì )導致競爭條件。 例如Socket API 對面向字節流的協(xié)議（如TCP），不保證read和write操作是原子的。所以如果IO操作沒(méi)有適當的進(jìn)行串行化，將會(huì )破壞或者丟失數據。 1.2 確定IO句柄集合的類(lèi)型: 也有兩種: 并發(fā)句柄集合：該集合可以被并發(fā)的訪(fǎng)問(wèn)，例如，被線(xiàn)程池所調用。 當它可能在一個(gè)句柄上發(fā)起一個(gè)操作，且這個(gè)操作是非阻塞的，則將并發(fā)句柄集合返回給它的調用者。 例如，Win32的 waitForMultipleObjects 函數支持并發(fā)句柄集合，允許多個(gè)線(xiàn)程同時(shí)在一個(gè)句柄集合上等待事件。 迭代(interative重復)句柄集合: 這種類(lèi)型集合當可能在一個(gè)或者多個(gè)句柄上發(fā)起非阻塞操作時(shí)，會(huì )返回一個(gè)迭代集合。盡管他能在一次調用中返回多個(gè)句柄，但不能被多個(gè)線(xiàn)程同時(shí)調用。Select 和poll 只支持迭代集合，所以select /poll 都不允許多線(xiàn)程同時(shí)訪(fǎng)問(wèn)一個(gè)句柄集合。 1.3 確定對IO句柄和句柄集合的選擇產(chǎn)生的影響 通常來(lái)說(shuō)，LF模式被用于防止多線(xiàn)程錯誤地破壞或者丟失數據， 例如并發(fā)的讀取一個(gè)TCP連接，或者同時(shí)在同一個(gè)句柄集上執行select(). 然而，有些應用不必關(guān)心這些情況。實(shí)際上，如果IO句柄和句柄集合機制都是并發(fā)的，下面的幾個(gè)步驟都可以省略。 舉例來(lái)說(shuō)，特定的網(wǎng)絡(luò )編程API, 如UPD Sockets,支持并發(fā)IO操作，因此消息總可以無(wú)風(fēng)險的被線(xiàn)程讀取，不必擔心并行讀取或交錯的數據損壞。 同樣地，特定的句柄集和機制，例如win32的waitForMultipleObjects 函數每次調用返回唯一的句柄，并允許多線(xiàn)程并行訪(fǎng)問(wèn)它。在這些情景下， 可以簡(jiǎn)單的使用操作系統的調度器來(lái)安全地復用線(xiàn)程、句柄集和和句柄。 這種實(shí)現可以省略掉 步驟2.(activity 2). 如果在步驟3中確定線(xiàn)程是非綁定的，那么其余步驟也都不必實(shí)現了。 1.4 利用高級模式將底層句柄集機制封裝（可選） ，實(shí)現LF模式的一種思路是使用操作系統原生的事件多路分離機制，例如select 和waitForMultipleObjects. 相反的，開(kāi)發(fā)者可以使用高級設計模式，如Reactor, Proactor, 和Warapperfacade。這些模式簡(jiǎn)化了LF模式的實(shí)現，并減少了為克服直接使用操作系統底層機制帶來(lái)的額外復雜性鎖做的付出。此外，應用高級設計模式更易于將并發(fā)模型和系統的IO分離機制解耦，從而減少代碼的重復和維護工作。 舉個(gè)例子，在我們的OLTP服務(wù)器例子中， IO事件必須要被分離給實(shí)際的事件處理者，這要根據是哪個(gè)IO句柄接收的這個(gè)事件來(lái)分派。 Reactor模式支持這種行為，從而簡(jiǎn)化LF模式的實(shí)現。 在LF模式中，一個(gè)響應者(reactor) 在分離過(guò)程中只分派一個(gè)實(shí)際事件處理者，而不管有多少句柄將有事件發(fā)生。下面的c++代碼描述了Reactor模式的實(shí)現: Typedef unsigned int Event_Types; Enum{ ACCEPT_EVENT = 01,//accept 事件是read事件的一個(gè)別名 READ_EVENT = 01, WRITE_EVENT= 02, TIMEOUT_EVENT= 04, SIGNAL_EVENT= 010, CLOSE_EVENT=020 }; Class Reactor{ Public : //對特定的事件類(lèi)型注冊一個(gè)事件響應者 Int register_handler (Event_handler *eh, Event_Type et); Int remove_handler(Event_handler *eh, Event_Type et); //進(jìn)入取事件循環(huán)的入口函數 Int handle_events(Time_value *timeout = 0); }; 開(kāi)發(fā)者提供Event_Handler接口的具體實(shí)現: Class Event_handler{ Pulbic : /** Reactor 處理特定類(lèi)型的事件時(shí)調用的回調處理方法 */ Virtual int handle_event(HANDLE, Event_Type et) = 0; //獲取IO句柄的鉤子函數 Virtual HANDLE get_handle(void) const = 0; }; （C++代碼看著(zhù)真tmd頭暈~_~````那個(gè)啥，是叫虛函數么? Holly shit） 2 實(shí)現一個(gè)臨時(shí)激活/失效句柄的協(xié)議 當事件到達時(shí)，領(lǐng)倒者線(xiàn)程使該句柄暫時(shí)失效，使其不在句柄集和的考慮之列，然后推舉一個(gè)新的領(lǐng)倒者，并繼續處理這個(gè)事件。 暫時(shí)的使句柄在集合中失效可以防止競爭出現，否則當新的領(lǐng)倒產(chǎn)生，且事件被經(jīng)處理時(shí)，競爭條件就可能出現：如果新的領(lǐng)倒在此期間等待事件（則剛剛的事件也會(huì )通知到新的領(lǐng)倒者），它很可能錯誤地再次分派這個(gè)事件。等到事件被處理完畢，句柄被重新激活，以允許領(lǐng)倒者等待上面發(fā)生的事件。 在我們的OLTP例子中，這個(gè)協(xié)議由reactor的實(shí)現提供，如下: Class Reactor{ Int suspend_handler(Event_handler *, Event_Type et); int resume_handler(Event_handler *, Event_type et); } 實(shí)現線(xiàn)程集合 為了推舉跟隨者作為領(lǐng)倒者，以及確定哪個(gè)線(xiàn)程是當前領(lǐng)倒者，LF的實(shí)現必須管理一個(gè)線(xiàn)程集合。兩種策略可用：非綁定和綁定方式，如下描述: //剩下的還未看完... |
聯(lián)系客服
