• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            CppExplore

            一切像霧像雨又像風(fēng)

              C++博客 :: 首頁(yè) :: 新隨筆 :: 聯(lián)系 :: 聚合  :: 管理 ::
              29 隨筆 :: 0 文章 :: 280 評(píng)論 :: 0 Trackbacks

            作者:CppExplore 網(wǎng)址:http://www.shnenglu.com/CppExplore/
            《技術(shù)系列綜述(一)》介紹了網(wǎng)絡(luò)層部分。網(wǎng)絡(luò)層基本都是多路復(fù)用函數(shù)作為運(yùn)行的主線程,使用管道或者sockpair與之通訊,這是網(wǎng)絡(luò)層線程的固有特點(diǎn),和業(yè)務(wù)線程的呈現(xiàn)方式完全不同。經(jīng)過網(wǎng)絡(luò)層以后,數(shù)據(jù)開始流向業(yè)務(wù)線程,現(xiàn)在就順著數(shù)據(jù)流向往上看。
            一 業(yè)務(wù)線程
            《技術(shù)系列之 線程(一)》有對(duì)線程的一個(gè)入門描述,里面的消息隊(duì)列只是示例,真實(shí)可用的可以看《技術(shù)系列之 線程(二)》
            (1)業(yè)務(wù)線程的劃分
            在業(yè)務(wù)層面,數(shù)據(jù)結(jié)構(gòu)仍然是服務(wù)器程序的核心。整理出業(yè)務(wù)需要的數(shù)據(jù)結(jié)構(gòu),據(jù)此劃分線程,保證每個(gè)數(shù)據(jù)結(jié)構(gòu)都在它所屬的線程中被修改。如果其它線程想修改該結(jié)構(gòu),則需要向本線程發(fā)送消息,由本線程修改。當(dāng)然這只是理想情況,有時(shí)候處于性能的需要或者和網(wǎng)絡(luò)層的交互,需要跨線程訪問其它線程的數(shù)據(jù),此時(shí)則需要加鎖,這也是線程間交互陷入混亂的一個(gè)開端,這種情況要限制在一個(gè)很小可控的范圍內(nèi)。
            (2)帶消息隊(duì)列的線程實(shí)現(xiàn)
            OA/CRM/WorkFlow的系統(tǒng)的關(guān)鍵在于業(yè)務(wù)的整理、面向?qū)ο蟮脑O(shè)計(jì)。而網(wǎng)絡(luò)服務(wù)器不同,服務(wù)器的業(yè)務(wù)相對(duì)清晰,相關(guān)性強(qiáng),它設(shè)計(jì)的關(guān)鍵在于數(shù)據(jù)模型的整理、線程的劃分。可以說線程是服務(wù)器的骨架。這里引入幾乎每個(gè)服務(wù)器都會(huì)有的一個(gè)基礎(chǔ)模塊:帶消息隊(duì)列的線程類。《技術(shù)系列之 線程(二)》實(shí)現(xiàn)了一個(gè)簡(jiǎn)單的線程消息隊(duì)列。在該消息隊(duì)列基礎(chǔ)之上進(jìn)一步封裝,實(shí)現(xiàn)帶消息隊(duì)列的線程類。該類的靜態(tài)類圖如下:

            ThreadQueue參見《技術(shù)系列之 線程(二)》
            start方法中參數(shù)默認(rèn)為1,大于1則是線程池的實(shí)現(xiàn),里面以線程的方式啟動(dòng)run函數(shù),線程號(hào)存入vector,供停止時(shí)用。putq方法在其它線程中調(diào)用,向該線程發(fā)送消息,run方法中循環(huán)調(diào)用getq獲取消息,調(diào)用deal_msg處理。實(shí)際的業(yè)務(wù)線程只需要繼承該類即可成為帶消息隊(duì)列的線程。
            (3)監(jiān)控線程
            基于上面這個(gè)基礎(chǔ)模塊,可以進(jìn)一步開發(fā)監(jiān)控線程,監(jiān)控線程定時(shí)向各個(gè)線程發(fā)送心跳消息,各普通線程收到心跳信息后向監(jiān)控線程回復(fù),如果某個(gè)線程在一定時(shí)間內(nèi)沒有回復(fù)心跳,則可以采取進(jìn)一步的修復(fù)處理。該方案可以作為系統(tǒng)安全的一個(gè)備選方案。
            以上思想同樣適用于嵌入式平臺(tái),很多嵌入式平臺(tái)使用多進(jìn)程協(xié)同處理消息,進(jìn)程之間使用共享內(nèi)存或者系統(tǒng)消息隊(duì)列通訊,思想大同小異,并且同樣可以設(shè)計(jì)監(jiān)控進(jìn)程。
            二 消息映射
            (1)消息定義以及處理示例
            有了線程消息隊(duì)列,也有就有消息傳遞,接下來就是業(yè)務(wù)線程獲取到消息處理消息。一個(gè)業(yè)務(wù)線程可能要處理多種消息,為區(qū)分不同的消息,引入消息類型。如下:

            enum MsgType
            {
                MSG_TYPE_1=
            65,//64一下預(yù)留,用于統(tǒng)一的管理控制
                MSG_TYPE_2,
                ..
                MSG_TYPE_MAX
            }
            ;
            struct Msg
            {
                MsgType type;
                MsgData data;
            }
            ;

            業(yè)務(wù)線程在deal_msg方法中處理消息,很容易想到的處理流程如下:
            switch(msg->type)
            {
                
            case MSG_TYPE_1:
                     do_msg_type_1_();
                     
            break;
                
            case MSG_TYPE_2:
                     do_msg_type_2_();
                     
            break;
                ..
                
            default:
                         do_default_msg_();
                         
            break;
            }


            (2)從代碼熵引入查表法
            這里引入“代碼熵”的概念,用于描述代碼的混亂程度。每千行代碼中,出現(xiàn)一個(gè)“else”,代碼熵加1,出現(xiàn)一個(gè)“case”,代碼熵也加1。如果1k行代碼的熵大于7,我們就認(rèn)為這個(gè)代碼已經(jīng)開始變的混亂了。
            因此當(dāng)消息類型不多的時(shí)候,使用case是個(gè)不錯(cuò)的選擇,當(dāng)處理的消息大于7個(gè)并且有擴(kuò)充趨勢(shì)的時(shí)候,我們就要想另外的辦法來代替這種switch...case...的寫法。
            消除else和case最直接的想法是查表法,使用數(shù)組下標(biāo)標(biāo)記消息類型,數(shù)組保存消息處理方法指針。這里不使用map,查詢需要o(lgn)不如數(shù)組來的直接,另外設(shè)計(jì)期間就已明確知道消息的類型以及對(duì)應(yīng)的處理函數(shù),不需要?jiǎng)討B(tài)增減,也不需要使用vector,直接簡(jiǎn)單的方法就是定義一個(gè)static的數(shù)組表。
            (3)消息映射
            直接的數(shù)組展現(xiàn)方式不攜帶語(yǔ)義,展現(xiàn)方式不直觀,維護(hù)和擴(kuò)充都讓人頭大。這里可用借助宏包裹數(shù)組,提供可讀的展現(xiàn)方式,如下:

            BEGIN_MESSAGE_MAP(SessionManager,SessionMsg)
                ON_MESSAGE(MSG_TYPE_1, SessionManager::do_msg_type_1_)
                ON_MESSAGE(MSG_TYPE_2, SessionManager::do_msg_type_2_)
                
            END_MESSAGE_MAP()

            如果你熟悉MFC,一定很熟悉這種消息映射的定義方式。這種消息映射的定義方式,從可維護(hù)、可讀方面比直接的數(shù)組更進(jìn)了一步。宏BEGIN_MESSAGE_MAP、ON_MESSAGE的實(shí)現(xiàn)方式不再詳寫,如果讀者實(shí)在想象不出來,可以參見《技術(shù)系列之 狀態(tài)機(jī)(一)》中的狀態(tài)機(jī)映射宏的定義方式。使用的時(shí)候在deal_msg中直接根據(jù)消息類型找到數(shù)組中的消息處理函數(shù)進(jìn)行處理,如果你認(rèn)為這樣暴露了消息映射背后的數(shù)組結(jié)構(gòu),可以把這個(gè)尋找消息處理函數(shù)的工作也封裝到基類IMsgThread中。
            (4)成員函數(shù)委托
            上面的消息映射宏展開后實(shí)際是一個(gè)靜態(tài)數(shù)組,而方法do_msg_type_1_/do_msg_type_2_也必須是類的靜態(tài)成員函數(shù)(普通類成員函數(shù)指針不能轉(zhuǎn)化為普通函數(shù)指針)。通過類的靜態(tài)成員函數(shù)訪問類的非靜態(tài)屬性或者方法如下:在消息中攜帶該類指針handler,處理方法中取到handler指針轉(zhuǎn)換類型,通過指針操作。
            當(dāng)代碼中充斥大量通過靜態(tài)成員函數(shù)訪問對(duì)象私有屬性的時(shí)候,這無疑是一種丑陋的寫法(事實(shí)并沒有這么嚴(yán)重)。
            這里就該boost::function,boost::bind出場(chǎng)了。如果你喜歡,也可以直接寫模版實(shí)現(xiàn)。也可以參見csdn文章成員函數(shù)指針與高性能的C++委托》
            (5)題外話
            1、統(tǒng)一的展現(xiàn)方式。
            不僅變量的命名需要統(tǒng)一規(guī)范,方法的調(diào)用邏輯同樣需要統(tǒng)一,這可以幫助你明確程序中數(shù)據(jù)的流向以及保證程序持續(xù)的擴(kuò)充、維護(hù)。相對(duì)于簡(jiǎn)單的命名規(guī)范,方法調(diào)用邏輯的統(tǒng)一更為重要。
            以線程類舉例說2點(diǎn)(1)其它線程類不能直接調(diào)用其它線程的putq方法向?qū)?yīng)線程發(fā)送消息。正確的做法是調(diào)用對(duì)應(yīng)線程類的方法,由該方法負(fù)責(zé)向本線程發(fā)送消息。
            (2)發(fā)送消息的方法/處理消息的方法職責(zé)要明確、命名要統(tǒng)一。
            發(fā)送消息的方法負(fù)責(zé)把方法參數(shù)轉(zhuǎn)化為消息內(nèi)容,調(diào)用putq發(fā)送消息,該方法不得操作本類的任何私有屬性。
            處理消息的方法負(fù)責(zé)對(duì)消息做出處理、響應(yīng)。
            命名方面,比如發(fā)送消息的方法可以以O(shè)N_開頭,處理消息的方法可以以DO_開頭。
            這些規(guī)范不應(yīng)該只是規(guī)范,而應(yīng)該是發(fā)自內(nèi)心的需要。當(dāng)然沒有什么規(guī)范是必須的,你仍然可以使用你喜歡的或者認(rèn)為可行的方式,如果你的方法在程序1w行、10w行、50w行的時(shí)候,仍能清晰表現(xiàn)程序的數(shù)據(jù)流向,仍有很好的可維護(hù)性、可擴(kuò)充性。
            2、開發(fā)領(lǐng)域的烙印。
            不多說了。一句話:重要的是思想,不是平臺(tái)和語(yǔ)言。

            posted on 2008-11-07 15:33 cppexplore 閱讀(4907) 評(píng)論(9)  編輯 收藏 引用

            評(píng)論

            # re: 【原創(chuàng)】技術(shù)系列綜述(二) 2008-11-10 09:10 true
            好文,挺起來  回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】技術(shù)系列綜述(二) 2008-11-10 09:21 true
            提出一個(gè)疑問:業(yè)務(wù)線程肯定是多線程的實(shí)現(xiàn),threadA,threadB,threadC,如果同一個(gè)client連續(xù)發(fā)送了2個(gè)待處理的包,是否保證對(duì)該client的處理由同一個(gè)線程實(shí)現(xiàn)?否則是否會(huì)出現(xiàn)threadA,threadB同時(shí)向client的socket寫數(shù)據(jù),導(dǎo)致亂序
              回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】技術(shù)系列綜述(二) [未登錄] 2008-11-10 09:36 cppexplore
            @true
            業(yè)務(wù)線程也不見得是多線程實(shí)現(xiàn),尤其是是處理有上下文關(guān)聯(lián)關(guān)系(比如,rtsp協(xié)議,發(fā)了setup,才能發(fā)play,發(fā)送teardown之后才結(jié)束,不同階段狀態(tài)是不同的,http是無狀態(tài)的協(xié)議就另說了)邏輯的業(yè)務(wù)線程 ,一般都是單線程。把握住系統(tǒng)瓶頸的所在,在關(guān)鍵業(yè)務(wù)瓶頸處加多線程。另外,如果真想實(shí)現(xiàn)你說的情況,可以綁定connection和上層業(yè)務(wù)線程,我覺得這不會(huì)有性能的提升,當(dāng)然也要看你的業(yè)務(wù)應(yīng)用場(chǎng)景。  回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】技術(shù)系列綜述(二) 2008-11-25 13:47 卡通服裝
            好文章,支持樓主多寫些  回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】技術(shù)系列綜述(二) 2009-04-14 17:01 包裝機(jī)
            恩,好  回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】服務(wù)器技術(shù)系列綜述(二) 2009-07-27 13:05 套袋收縮機(jī)
            不錯(cuò),給你頂一個(gè),  回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】服務(wù)器技術(shù)系列綜述(二) 2009-09-28 18:09 neou
            不錯(cuò),跟我的思路比較類似。 我的代碼。

            BEGIN_REQUEST_MAP(chunk_master_handler)
            REQUEST_HANDLER(PChunkSnap, onChunkSnap)
            REQUEST_HANDLER(PRegSlave, onRegSlave)
            REQUEST_HANDLER(PMasterSnap, onMasterSnap)
            END_REQUEST_MAP()


            另外,服務(wù)器最重要的是要實(shí)現(xiàn)一個(gè)好用的buffer, 高效,內(nèi)存分配快。   回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】服務(wù)器技術(shù)系列綜述(二) 2010-05-30 21:54 UustCodeIT
            對(duì)于某些消息,業(yè)務(wù)線程處理完了還要向client返回結(jié)果,怎么把結(jié)果返回到網(wǎng)絡(luò)層在發(fā)送給client?是不是在把消息從網(wǎng)絡(luò)層向業(yè)務(wù)線程轉(zhuǎn)移的時(shí)候還要提供消息所有者等信息。  回復(fù)  更多評(píng)論
              

            # re: 【原創(chuàng)】服務(wù)器技術(shù)系列綜述(二) [未登錄] 2010-06-04 12:06 cppexplore
            @UustCodeIT
            session對(duì)象和 網(wǎng)絡(luò)層的connection對(duì)象有一定對(duì)應(yīng)關(guān)系的  回復(fù)  更多評(píng)論
              


            只有注冊(cè)用戶登錄后才能發(fā)表評(píng)論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            欧美一区二区久久精品| 久久久无码精品亚洲日韩蜜臀浪潮 | 久久久久无码中| 亚洲欧美日韩精品久久| 国产精品9999久久久久| 久久精品中文无码资源站| 久久久久久午夜成人影院| 久久天天躁狠狠躁夜夜96流白浆| 久久久无码精品亚洲日韩京东传媒 | 亚洲国产另类久久久精品黑人| 99久久夜色精品国产网站| 狠狠色丁香久久婷婷综合图片| 精品国产乱码久久久久软件| 久久久亚洲裙底偷窥综合| 伊人久久大香线焦AV综合影院| 欧美日韩久久中文字幕| 性欧美丰满熟妇XXXX性久久久| 久久99精品久久久久久久久久 | 狠狠久久亚洲欧美专区| 26uuu久久五月天| 亚洲人成网站999久久久综合| 久久亚洲日韩看片无码| 99精品久久精品一区二区| 国产日韩久久久精品影院首页 | 99久久国产综合精品网成人影院 | 7777精品久久久大香线蕉| 国产亚洲精久久久久久无码| 久久久久久一区国产精品| 亚洲AV无码1区2区久久| 99久久婷婷国产一区二区| 久久婷婷人人澡人人爽人人爱| 久久无码人妻一区二区三区| 国产99久久久国产精品~~牛| 伊人久久大香线蕉成人| aaa级精品久久久国产片| 久久久精品国产Sm最大网站| 久久水蜜桃亚洲av无码精品麻豆 | 办公室久久精品| 新狼窝色AV性久久久久久| 久久夜色精品国产| 久久亚洲国产午夜精品理论片|