• <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>
            隨筆 - 119  文章 - 290  trackbacks - 0

            博客搬家了哦,請(qǐng)移步
            叫我abc

            常用鏈接

            留言簿(12)

            隨筆分類

            我的博客

            搜索

            •  

            積分與排名

            • 積分 - 304346
            • 排名 - 84

            最新評(píng)論

            閱讀排行榜

            我一直堅(jiān)信,如果不是處理大規(guī)模客戶端連接,是不需要使用epoll和IOCP的。我傾向于簡(jiǎn)單的東西,所以我一直用著select。
            一直以來,我的網(wǎng)絡(luò)程序結(jié)構(gòu)就是在每一幀的開始select,有什么消息就處理一下,然后跑程序的主邏輯。我覺得這個(gè)結(jié)構(gòu)挺好,單線程,簡(jiǎn)單、明了、優(yōu)雅。
            不過最近有頭兒告訴我,這個(gè)事情雖然可以,但是感覺上不太對(duì)頭,網(wǎng)絡(luò)組件的工作應(yīng)該是獨(dú)立的,不可以占用主邏輯的時(shí)間。
            好吧,我改成多線程就是了。一個(gè)主線程,負(fù)責(zé)處理客戶端消息和運(yùn)算主邏輯;一個(gè)網(wǎng)絡(luò)線程,負(fù)責(zé)從網(wǎng)絡(luò)上讀取數(shù)據(jù)和將數(shù)據(jù)發(fā)送到網(wǎng)絡(luò)上,基本上就是select,recv,send三調(diào)用。

            這里出現(xiàn)了第一個(gè)問題:主線程和網(wǎng)絡(luò)線程之間如何進(jìn)行數(shù)據(jù)交換?主線程中待發(fā)送的數(shù)據(jù)需要交給網(wǎng)絡(luò)線程做實(shí)際的發(fā)送,網(wǎng)絡(luò)線程接收到的數(shù)據(jù)需要交給主線程處理。
            基于盡可能短的lock-time這一原則,我給主線程和網(wǎng)絡(luò)線程各分配了一個(gè)完全一樣的容器,這個(gè)容器由各線程獨(dú)自享有,容納發(fā)送和接收的數(shù)據(jù)。
            然后在特定的時(shí)候,lock主其中一個(gè)容器,進(jìn)行數(shù)據(jù)拷貝即可——將欲發(fā)送的數(shù)據(jù)從主線程容器拷貝到網(wǎng)絡(luò)線程的容器,將收到的數(shù)據(jù)從網(wǎng)絡(luò)線程的容器拷貝到主線程的容器。
            這一lock只有拷貝工作,時(shí)間上應(yīng)該是十分短暫的。

            第二個(gè)問題:由誰(shuí)負(fù)責(zé)這個(gè)拷貝,主線程還是網(wǎng)絡(luò)線程?負(fù)責(zé)拷貝的線程,必然去lock另一個(gè)線程的容器。
            我選擇了主線程負(fù)責(zé)拷貝操作。在每幀的開始,鎖住網(wǎng)絡(luò)線程的容器,將它收到的數(shù)據(jù)拷出來,將要發(fā)送的數(shù)據(jù)拷進(jìn)去,解鎖,然后處理收到的消息。網(wǎng)絡(luò)線程則需要在操作自己的容器的時(shí)候加鎖。
            好處是,主線程的 send_packet 操作不需要加鎖,并且收到的數(shù)據(jù)是拷出來就消耗掉。
            順便也想想網(wǎng)絡(luò)線程負(fù)責(zé)拷貝的情形,在select之前,鎖住主線程的容器,將欲發(fā)送的數(shù)據(jù)拷進(jìn),解鎖;然后是select,recv,send;然后再次鎖住主線程的容器,將收到的數(shù)據(jù)拷出。相應(yīng)的,主線程需要在操作自己容器的時(shí)候加鎖。
            看起來我并不想主線程在一幀內(nèi)有太多次的加鎖解鎖操作,因此就選擇了第一個(gè)方案。

            至此,程序跑起來了。不過出現(xiàn)了一個(gè)單線程所沒有的新問題——CPU占用率太高了。
            原因應(yīng)該是,select能掛起程序,所以單線程的時(shí)候,程序多多少少總會(huì)有掛起的機(jī)會(huì);但是多線程以后,主線程就跟while ( true )差不多,浪費(fèi)了太多的資源。
            因此,讓主線程在每幀也睡一會(huì)就好了。游戲的主邏輯是限幀的,一般每秒25幀,稱邏輯幀。但是處理網(wǎng)絡(luò)消息不是限幀的,而是希望能盡可能快的處理他們,因此處理網(wǎng)絡(luò)消息是在實(shí)際幀中進(jìn)行的。
            通常游戲主邏輯的一次tick并不能完全消耗掉一個(gè)邏輯幀的時(shí)間,因此讓主線程在邏輯幀剩下的時(shí)間里睡上一覺就好。

            第三個(gè)問題是:如何讓主線程在剩下的邏輯幀時(shí)間里掛起,并在有網(wǎng)絡(luò)消息的時(shí)候立即激活?
            信號(hào)/EVENT——主線程在進(jìn)行容器的數(shù)據(jù)拷貝之前,如果自己沒有欲發(fā)送的數(shù)據(jù),則等待信號(hào),等待的時(shí)間是上一個(gè)邏輯幀所剩余的時(shí)間。相應(yīng)的網(wǎng)絡(luò)線程中,如果收到新的數(shù)據(jù),則激活這個(gè)信號(hào),那么主線程會(huì)被立即喚醒。
            等待超時(shí)或者被喚醒后,就會(huì)執(zhí)行數(shù)據(jù)拷貝和消息處理。這樣,既實(shí)現(xiàn)了sleep,又兼顧了即時(shí)反應(yīng)能力。

            編譯運(yùn)行,程序看起來挺穩(wěn)定,CPU占用率為0.。。。。。。新項(xiàng)目,邏輯上幾乎啥都沒有呢。
            posted on 2009-01-03 16:54 LOGOS 閱讀(7951) 評(píng)論(8)  編輯 收藏 引用

            FeedBack:
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu)[未登錄] 2009-01-03 17:21 關(guān)中刀客
            我的做法就是:
            底層select線程不停的接受數(shù)據(jù),插入到緩沖中,上層的單邏輯線程一楨取一次數(shù)據(jù),然后全部的處理。  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu)[未登錄] 2009-01-03 17:30 關(guān)中刀客
            對(duì)了,在說以下,LZ可以把發(fā)送數(shù)據(jù),在每一楨里面都寫入到邏輯主線程里的一個(gè)內(nèi)存塊,在每一楨結(jié)束的時(shí)候使用邏輯主線程來發(fā)送,不需要再交給底層的select線程了。底層就只需要管理接受九可以了。  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu) 2009-01-03 20:57 LOGOS
            @關(guān)中刀客
            回復(fù)1就是我想表達(dá)的
            回復(fù)2,由主線程在每幀結(jié)束的時(shí)候執(zhí)行真正的發(fā)送——socket對(duì)象是被包裝過的,sendbuf并不是可重入的。基本上就是,我所使用的socketlib無(wú)法便利的做到這點(diǎn)  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu)[未登錄] 2009-01-03 21:40 true
            我也在做多線程select,不同的是,接受數(shù)據(jù)也是多線程的select,因?yàn)閱蝹€(gè)select的連接數(shù)受限,所以,是一個(gè)單獨(dú)的select線程,accept連接,然后交個(gè)多個(gè)select線程處理接收數(shù)據(jù),至于發(fā)送是和接收分開處理的,也是一個(gè)select+一個(gè)隊(duì)列的發(fā)送模式。多個(gè)接收線程將收到的數(shù)據(jù)放到同一個(gè)隊(duì)列,這里當(dāng)然少不了lock,隊(duì)列的數(shù)據(jù)如果交給 上層邏輯,則比較靈活,可以一次復(fù)制整個(gè)隊(duì)列,也可以是一次一個(gè)消息處理。  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu)[未登錄] 2009-01-03 21:45 true
            另外,粗略看過glibc,及內(nèi)核的epoll的源代碼,epoll內(nèi)部實(shí)現(xiàn)比較復(fù)雜,而且加鎖次數(shù),及加鎖層次較多,與select的簡(jiǎn)單特性相比,感覺優(yōu)勢(shì)不大  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu) 2009-01-04 09:44 zuhd
            epoll的優(yōu)勢(shì)是輪詢的效率高,會(huì)忽略閑置的fd,select不會(huì)。不管什么網(wǎng)絡(luò)模型,感覺網(wǎng)絡(luò)事件和邏輯處理都是兩個(gè)線程的,而且只需兩個(gè)線程。我比較同意1樓的想法,感覺很成熟。  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu) 2009-01-04 14:04 LOGOS
            @true
            我覺得如果多個(gè)線程做select,連接的數(shù)量規(guī)模較大的話,還是使用epoll或者IOCP好一點(diǎn)
            如zuhd所說,內(nèi)核處理的代碼總是相當(dāng)穩(wěn)定和有效率的  回復(fù)  更多評(píng)論
              
            # re: 多線程下的select網(wǎng)絡(luò)程序結(jié)構(gòu) 2009-01-05 09:18 honghui
            我一般是用pthread_cond_t 配合線程鎖 來解決的,當(dāng)沒有數(shù)據(jù)等待處理時(shí),主線程釋放鎖并且在pthread_cond_t上睡眠,直到子線程拿到數(shù)據(jù)并且將數(shù)據(jù)加入到數(shù)據(jù)結(jié)構(gòu)中后,釋放鎖并喚醒主線程  回復(fù)  更多評(píng)論
              

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


            热久久最新网站获取| 国产69精品久久久久9999APGF| 色婷婷噜噜久久国产精品12p | 国产产无码乱码精品久久鸭 | 久久久久久午夜精品| 超级97碰碰碰碰久久久久最新| 无码精品久久久久久人妻中字 | 亚洲国产精品嫩草影院久久| 久久中文字幕人妻熟av女| 久久A级毛片免费观看| 看全色黄大色大片免费久久久| 囯产极品美女高潮无套久久久| 久久亚洲国产精品一区二区| 久久精品国产黑森林| 久久精品国产亚洲AV高清热| 久久久WWW成人免费毛片| 精品国产乱码久久久久久人妻| 99久久无码一区人妻| 久久99精品久久久大学生| 国产精品欧美亚洲韩国日本久久 | 99久久久久| 亚洲AV无码久久精品狠狠爱浪潮 | 久久人人爽人人人人爽AV| 亚洲国产精品久久久久| 久久天天躁狠狠躁夜夜96流白浆 | 久久精品一区二区三区中文字幕| 午夜精品久久久久久99热| 久久精品免费网站网| 青青草国产精品久久久久| 久久99热只有频精品8| 丁香色欲久久久久久综合网| 伊人久久国产免费观看视频| 久久国产一片免费观看| 久久久精品无码专区不卡| 91精品国产91久久久久久青草| avtt天堂网久久精品| 77777亚洲午夜久久多喷| 国产精品久久亚洲不卡动漫| 国产高潮国产高潮久久久| 久久精品国产影库免费看| 久久精品国产福利国产秒|