青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Creative Commons License
本Blog采用 知識(shí)共享署名-非商業(yè)性使用-禁止演繹 3.0 Unported許可協(xié)議 進(jìn)行許可。 —— Fox <游戲人生>

游戲人生

游戲人生 != ( 人生 == 游戲 )
站點(diǎn)遷移至:http://www.yulefox.com。請(qǐng)訂閱本博的朋友將RSS修改為http://feeds.feedburner.com/yulefox
posts - 62, comments - 508, trackbacks - 0, articles - 7

Author: Fox

//-----------------------------------------------------------------------------------------------------
夜深了,隨便寫(xiě)寫(xiě)……
//-----------------------------------------------------------------------------------------------------

大凡學(xué)過(guò)編程語(yǔ)言和網(wǎng)絡(luò)的TX應(yīng)該都寫(xiě)過(guò)自己的聊天程序,那時(shí)候大家都知道了套接字怎么selectconnectbindlisten、accept、sendrecv,也知道了TCPUDP的區(qū)別……稍微用功的TX或許還寫(xiě)過(guò)多人聊天程序,知道了什么是阻塞I/O,真正致力于向QQ、MSN等即時(shí)聊天工具靠齊的大牛對(duì)本文提到的IOCP更是了然于胸。更多的TX或者有興趣繼續(xù)看下去。

一、阻塞I/O(主要指TCP)

1、當(dāng)socket的recv buff為空時(shí),進(jìn)程會(huì)wait直到新數(shù)據(jù)到達(dá);

2、當(dāng)socket的send buff已滿時(shí),進(jìn)程會(huì)wait直到空間足夠;

3、當(dāng)socket的accept沒(méi)有新連接到達(dá),進(jìn)程會(huì)wait直到新連接到達(dá);

4、當(dāng)socket的connect沒(méi)有收到ACK,進(jìn)程會(huì)wait直到收到ACK。

而非阻塞I/O則是致力于提供高效的異步I/O。

二、IOCP(I/O Completion PortI/O完成端口

IOCP是MS提供的Windows內(nèi)核對(duì)象,內(nèi)部使用線程池管理,并根據(jù)CPU的個(gè)數(shù)確定線程個(gè)數(shù)。當(dāng)數(shù)據(jù)到達(dá)后,統(tǒng)一投遞到唯一的IOCP隊(duì)列,對(duì)應(yīng)的若干工作線程用于處理這些數(shù)據(jù),從而實(shí)現(xiàn)非阻塞異步I/O。

簡(jiǎn)單了解了IOCP的功能和原理,下面提供幾點(diǎn)線索,供有興趣的TX整理思緒J

1、OVERLAPPED結(jié)構(gòu):

2、CreateIoCompletioPort:用于創(chuàng)建IOCP,關(guān)聯(lián)連接來(lái)的socket句柄,用于接收數(shù)據(jù);

3、GetQueuedCompletionStatus:供工作線程調(diào)用,取到數(shù)據(jù)的線程會(huì)加入I/O完成隊(duì)列,IOCP的線程池管理這些工作線程。

三、深入學(xué)習(xí)和使用

1、Jeffrey Richter的《Advanced Windows》,第15章,誰(shuí)看誰(shuí)知道J;

2、Jim Beveridge & Robert Wiener的《Multithreading Applications in Win32》,第6章,誰(shuí)看誰(shuí)知道J;

3、Google。

//-----------------------------------------------------------------------------------------------------
感覺(jué)用Office 2007編輯和發(fā)布Blog比Live Writer要方便很多,主要是Live Writer的編輯功能太少了,如果2007能夠?qū)︽溄舆M(jìn)行target設(shè)置,
再支持EntryName就perfact了J
從新公司回來(lái),還沒(méi)有完全適應(yīng)這邊寬松的環(huán)境,這幾天好似夢(mèng)游一般,先是IE出問(wèn)題,Ghost了一道,后面是Outlook收郵件出問(wèn)題。
還是夜深人靜的時(shí)候,一個(gè)人燃著煙、聽(tīng)著歌、喝著茶、敲著鍵盤(pán)有感覺(jué)……
//-----------------------------------------------------------------------------------------------------

posted @ 2008-03-06 01:18 Fox 閱讀(4452) | 評(píng)論 (7)編輯 收藏

Author: Fox

//-----------------------------------------------------------------------------------------------------
因?yàn)橐獨(dú)w位回原公司了,手上便沒(méi)有什么工作了,難得清閑下來(lái),就整理一些很雜的東西,準(zhǔn)備下周回去了J。
//-----------------------------------------------------------------------------------------------------

零、關(guān)于此文

下面的東西很雜,但并非沒(méi)有關(guān)聯(lián)。

一、關(guān)于《瘋狂的程序員》

有些搞程序的人有個(gè)癖性:自負(fù)偏激,主觀絕對(duì)。

早就看過(guò)一點(diǎn)兒,因?yàn)闀r(shí)間,沒(méi)有怎么關(guān)注,下午就找來(lái)CSDN的blog上面連載的《瘋狂的程序員》來(lái)看。

正如很多人所評(píng)論的,在絕影身上,大家都找到了自己當(dāng)初學(xué)程序的影子。哪個(gè)稍有點(diǎn)技術(shù)的程序沒(méi)有點(diǎn)自負(fù)的心理呢?絕影的性格很偏激,人很要面子,想法很陰暗,對(duì)世界的認(rèn)識(shí)很主觀、很絕對(duì)。

可惜的是,這個(gè)東西,只能當(dāng)作小說(shuō)看,其他不做評(píng)論……

二、關(guān)于Windows的環(huán)境變量

有些搞程序的人有個(gè)癖性:能用鍵盤(pán)的堅(jiān)決不用鼠標(biāo)。

查看幫助,按F1,重命名,按F2,搜索,按F3,輸入地址,按F4,刷新,按F5……

桌面上很干凈,沒(méi)有"我的電腦"的圖標(biāo),都用WinKey+E。沒(méi)有IE的圖標(biāo),都用WinKey+R,輸入iexplore,回車(chē)……

快速啟動(dòng)里面沒(méi)有"顯示桌面"的圖標(biāo),都用WinKey+D,或者WinKey+M,沒(méi)有Outlook的圖標(biāo),都用WinKey+R,輸入outlook,回車(chē),Word就輸入winword,記事本就輸入notepad……

打開(kāi)大多程序,不用鼠標(biāo)到處點(diǎn)擊,都是"運(yùn)行"里面輸入命令行替代了。除了Windows默認(rèn)的這些,自己常用的其他軟件怎么辦呢?Windows有個(gè)環(huán)境變量。下面我給大家show一下,怎么不用鼠標(biāo),完成自定義環(huán)境變量,實(shí)現(xiàn)命令打開(kāi)任一軟件J

1、WinKey+E,打開(kāi)"我的電腦";

2、Alt+Enter,打開(kāi)其"屬性";

3、方向鍵,選擇"高級(jí)";

4、Alt+N,打開(kāi)"環(huán)境變量";

5、Tab鍵,選擇"系統(tǒng)變量";

6、方向鍵,選擇"Path";

7、Alt+I,打開(kāi)"編輯";

8、End鍵,移動(dòng)到最后;

9、輸入";targetpath";*

10、Tab鍵,選擇"確定",回車(chē),Tab鍵,選擇"確定",回車(chē);

11、WinKey+R,打開(kāi)"運(yùn)行";

12、輸入"softname",回車(chē);*

13、Over。

//-----------------------------------------------------------------------------------------------------
其中,targetpath為soft所在文件夾絕對(duì)路徑,softname為軟件對(duì)應(yīng)的exe文件名(.exe可省略)……
//-----------------------------------------------------------------------------------------------------

posted @ 2008-02-29 18:11 Fox 閱讀(1772) | 評(píng)論 (3)編輯 收藏

Author: Fox

//-----------------------------------------------------------------------------------------------------
關(guān)于反外掛,這兩天在和幾位同事和網(wǎng)友討論的結(jié)果依然是,更多的要從策劃角度解決……
//-----------------------------------------------------------------------------------------------------

最近在考慮安全問(wèn)題的時(shí)候,在《游戲編程精粹3》中看到Pete Isensee的《安全套接字》(即通常所說(shuō)的Secure Socket Layer, SSL技術(shù)),又Google了一些IPSec的相關(guān)資料。盡管IPSec是部署在IP層的協(xié)議,但它還是可以為我們提供一些思路。

一、IPSec的認(rèn)證安全(AH+ESP)

1、不可否認(rèn)性:采用公鑰加密的數(shù)字簽名具有抗抵賴性。

2、防止報(bào)文重放:使用序列號(hào)和滑動(dòng)窗口以保證數(shù)據(jù)包的唯一性,即使數(shù)據(jù)包被截獲重發(fā),也會(huì)因序列號(hào)的相同或者錯(cuò)誤而被拋棄。

3、完整性:IPSec使用單獨(dú)的鑒別頭部(Authentication Header, AH)信息進(jìn)行校驗(yàn),防止報(bào)文篡改,校驗(yàn)的算法主要是MD5、SHA-1等單向哈希算法。

4、可靠性:通過(guò)加密封裝安全有效載荷(Encapsulating Security Payload, ESP),IPSec對(duì)傳輸數(shù)據(jù)進(jìn)行保護(hù),加密算法除了MD5、SHA-1,還有加密塊鏈接(Cipher Block Chaining, CBC)模式加密算法等。

二、IPSec的數(shù)據(jù)加密

在數(shù)據(jù)加密上,IPSec使用的主要是DES(Data Encryption Standard)和3DES(Triple Data Encryption Standard)算法。

三、IPSec的密鑰管理

為了保證數(shù)據(jù)傳輸安全,IPSec使用由IKE(Internet Key Exchange)提供的動(dòng)態(tài)密鑰更新機(jī)制,Diffie-Hellman算法提供密鑰生成策略,通信兩端需要維持一個(gè)安全關(guān)聯(lián)(Security Association),為兩端通信指定認(rèn)證及加密所用算法和密鑰,并提供序列號(hào)和滑動(dòng)窗口等。

需要注意的是,IPSec并沒(méi)有提供數(shù)據(jù)產(chǎn)生到發(fā)送之前的保護(hù)機(jī)制。舉例來(lái)說(shuō),就是IPSec可以在最大程度上保證你輸入的帳號(hào)密碼在傳輸過(guò)程中的安全,但并不能防止釣魚(yú)軟件和其他木馬在你輸入這些信息時(shí)被截獲L,那應(yīng)該是你要注意的。

對(duì)IPSec有興趣的TX可以到http://www.ietf.org上下載相關(guān)的RFC文檔研究研究J

//-----------------------------------------------------------------------------------------------------
本以為手上工作完成,可以偷時(shí)間看看安全方面的東西,不曾想Joe又分下了新任務(wù)L……
//-----------------------------------------------------------------------------------------------------

posted @ 2008-02-28 20:54 Fox 閱讀(2114) | 評(píng)論 (3)編輯 收藏

Author: Fox

//-----------------------------------------------------------------------------------------------------
此篇僅是對(duì)反脫機(jī)外掛的一點(diǎn)思考,其他安全問(wèn)題如登錄驗(yàn)證、消息驗(yàn)證等更多的是涉及邏輯功能。
//-----------------------------------------------------------------------------------------------------

春節(jié)剛回來(lái)的時(shí)候,回公司去和Soft聊到了自己的畢業(yè)論文的問(wèn)題,因?yàn)閷I(yè)的關(guān)系,我必須給出一些安全方面的考慮,正是因?yàn)檫@一點(diǎn),我當(dāng)時(shí)開(kāi)題時(shí)就立足對(duì)安全的無(wú)縫游戲世界進(jìn)行思考。只是在游戲本身的安全性上,一直也沒(méi)有一個(gè)好的出發(fā)點(diǎn),這兩周還是在考慮這個(gè)問(wèn)題。

這一點(diǎn),有我入行時(shí)間不長(zhǎng),對(duì)于游戲本身、玩家與開(kāi)發(fā)者(含游戲及外掛、木馬開(kāi)發(fā)者)之間的關(guān)系并沒(méi)有一個(gè)很好的把握,更多的是由于我對(duì)游戲中的可用的安全技術(shù)不了解,尤其是對(duì)應(yīng)用層安全協(xié)議不了解,對(duì)破解技術(shù)也不了解,導(dǎo)致無(wú)所適從。

《游戲編程精粹1》中Andrew Kirmse在《在線游戲的網(wǎng)絡(luò)協(xié)議》一文中對(duì)常見(jiàn)的篡改報(bào)文、報(bào)文重放和逆向工程有講述。預(yù)防報(bào)文篡改的有效防御是哈希校驗(yàn),現(xiàn)在大多游戲是使用MD5算法,而且網(wǎng)上開(kāi)源的MD5代碼也很多。對(duì)于報(bào)文重放,Andrew提到了使用線性疊加隨機(jī)數(shù)的狀態(tài)機(jī),具體原理和實(shí)現(xiàn)方式因?yàn)闆](méi)有提到太詳細(xì),還要針對(duì)實(shí)際應(yīng)用繼續(xù)學(xué)習(xí)L。然而,由于客戶端既是報(bào)文的接收者也是發(fā)送者,因此,客戶端包括了完整的加解密算法。一旦客戶端被逆向,上述措施就變成了破解者背后的煙霧彈,完全失去意義。

提到反外掛,Joe的看法也是說(shuō)這個(gè)東西和具體某一個(gè)技術(shù)關(guān)系不大,還是要從機(jī)制上去看。加不加密對(duì)于普通玩家沒(méi)有意義,對(duì)于專業(yè)從事逆向的人更是也沒(méi)有意義,所有單純考慮加密是沒(méi)有效果的。對(duì)于免費(fèi)游戲,外掛往往是打錢(qián)公司的工具,你封他的號(hào),他再建就是了,代價(jià)幾乎為0,而一般付費(fèi)游戲(像魔獸世界)一個(gè)帳號(hào)對(duì)應(yīng)一個(gè)CDKey,一個(gè)CDKey就要幾十塊錢(qián),這個(gè)封起來(lái)就有點(diǎn)咬牙了。

說(shuō)到這里,不妨換個(gè)思路:為免費(fèi)游戲加入CDKey。我一款游戲從內(nèi)測(cè)、封測(cè)到公測(cè),讓玩家充分參與體驗(yàn),在被逆向且外掛橫行之前,按正常邏輯運(yùn)營(yíng)。進(jìn)而假定我這一款游戲在公測(cè)之后,讓玩家感覺(jué)魅力十足。引導(dǎo)玩家并實(shí)施CDKey,一個(gè)CDKey大約會(huì)需要玩家付出些許Money以示誠(chéng)意,在玩家游戲過(guò)程中,會(huì)階段性向玩家贈(zèng)送部分增值道具。老玩家在進(jìn)入新區(qū)時(shí),需要申請(qǐng)繼續(xù)使用原CDKey。這樣一來(lái),外掛就不會(huì)肆無(wú)忌憚了。

BTW,這個(gè)思路沒(méi)有從技術(shù)角度解決問(wèn)題,下面再來(lái)看一種略微關(guān)乎技術(shù)實(shí)現(xiàn)的解決方案:動(dòng)態(tài)驗(yàn)證。在游戲運(yùn)行期間,會(huì)不定期的向玩家發(fā)送驗(yàn)證碼,客戶端在收到消息后,必須在一定時(shí)間內(nèi)響應(yīng),向服務(wù)器確認(rèn)收到的驗(yàn)證碼,否則將被強(qiáng)制下線,再次登錄后將更加頻繁的收到驗(yàn)證碼,直到用其良好的回復(fù)次數(shù)累積消除其不良記錄為止。為了盡量減少因此給玩家造成的不友好體驗(yàn),在任務(wù)場(chǎng)景、重要PK場(chǎng)景或者高等級(jí)玩家活動(dòng)場(chǎng)景,驗(yàn)證碼的發(fā)送和確認(rèn)可適當(dāng)放寬。

當(dāng)然,如果外掛中加入了圖形識(shí)別,這一招也未必奏效。

不知是道高還是魔高,可以肯定的一點(diǎn)是:大家都是在利益的驅(qū)動(dòng)下絞盡腦汁。

//-----------------------------------------------------------------------------------------------------
春節(jié)回來(lái)之后,一直比較忙(確切的說(shuō)是比較懶),沒(méi)有更新,宜更加勤奮。
最近工作涉及到數(shù)據(jù)庫(kù)編程,一點(diǎn)點(diǎn)對(duì)數(shù)據(jù)庫(kù)的讀寫(xiě)居然耗掉我3天時(shí)間,汗!
//-----------------------------------------------------------------------------------------------------

posted @ 2008-02-26 16:04 Fox 閱讀(2635) | 評(píng)論 (10)編輯 收藏

Author: Fox

終于趕在周末之前調(diào)通了,現(xiàn)在來(lái)總結(jié)一下我這個(gè)項(xiàng)目中對(duì)于異步回調(diào)的應(yīng)用背景。

這個(gè)項(xiàng)目的內(nèi)容就是在游戲中使用第三方庫(kù)為所有玩家提供更好的服務(wù),當(dāng)server啟動(dòng)后,加載dll,初始化該模塊,當(dāng)server退出時(shí),結(jié)束模塊功能,卸載dll。

當(dāng)玩家提出請(qǐng)求后,server在main thread中通過(guò)lib轉(zhuǎn)發(fā)玩家請(qǐng)求,lib處理完畢,在其獨(dú)立thread中回調(diào)server為其實(shí)現(xiàn)的callback function。此時(shí),server需要將返回的result轉(zhuǎn)到main thread中對(duì)result及其相關(guān)的玩家數(shù)據(jù)進(jìn)行處理。

第三方庫(kù)的需求是很明確的,在合適的地方發(fā)送請(qǐng)求,在合適的地方處理響應(yīng)。

Joe對(duì)我的要求也是很明確的,響應(yīng)處理時(shí)采用server當(dāng)前架構(gòu)(這個(gè)架構(gòu)在上一篇文中有提到),使我的編碼不涉及任何游戲功能邏輯處理,并使整個(gè)處理流程細(xì)節(jié)對(duì)后續(xù)應(yīng)用開(kāi)發(fā)透明。

二者結(jié)合起來(lái),就為這個(gè)項(xiàng)目融入整個(gè)server的架構(gòu)提供了完美的需求,也為我的編碼提供了最小限度的選擇空間:(,好處是后續(xù)功能開(kāi)發(fā)可以完全無(wú)視我的編碼,只需實(shí)現(xiàn)對(duì)回調(diào)響應(yīng)后的功能,只有server底層知悉如何調(diào)用。

給出序列圖:

?

uml_asny_callback

為了保持對(duì)上層開(kāi)發(fā)透明,OnCallback需要封裝。

//-------------------------------------------------------------------------------
// 一年來(lái),我主要參與了兩款游戲,確切的說(shuō)是半年,前面半年并沒(méi)有真正涉及運(yùn)營(yíng)產(chǎn)品的開(kāi)發(fā),只是做工具。
// 現(xiàn)在這個(gè)模塊是我做的最快,也是壓力最大的一個(gè)?,F(xiàn)在想來(lái),原因在于此模塊涉及到游戲主邏輯底層和
// 第三方動(dòng)態(tài)鏈接庫(kù)的通信及處理。
// 在短短幾天的時(shí)間內(nèi)讓你的設(shè)計(jì)滿足第三方庫(kù)的應(yīng)用需求并符合游戲自身底層邏輯的設(shè)計(jì)風(fēng)格,的確有些痛苦,
// 好在有Joe的指點(diǎn),讓我在完成工作的同時(shí)又學(xué)到了一些方法:)。
//-------------------------------------------------------------------------------

posted @ 2008-01-25 11:27 Fox 閱讀(1595) | 評(píng)論 (4)編輯 收藏

Author: Fox

前段時(shí)間寫(xiě)過(guò)一篇關(guān)于線程安全的文字,有TX覺(jué)得不深入。因?yàn)楸緛?lái)就沒(méi)想寫(xiě)的太具體,只是隨便說(shuō)說(shuō),今天就想說(shuō)點(diǎn)具體的技術(shù)。

//-------------------------------------------------------------------------------
// 動(dòng)態(tài)鏈接庫(kù) (Dynamic Link Library)

1) 動(dòng)態(tài)鏈接;

2) 跨語(yǔ)言;

3) Win32平臺(tái)可用;

?1?// ?靜態(tài)鏈接庫(kù).h文件中對(duì)函數(shù)的聲明:
?2?//?dllExam.h

?3?extern?"C"?void?/*__stdcall*/?Func(?int ?nParam?);
?4?

?5?// ?動(dòng)態(tài)鏈接庫(kù).h文件中對(duì)函數(shù)的聲明:
?6?//?dllExam.h

?7?extern?"C"?void?__declspec(?dllexport?)?/*__stdcall*/?Func(?int ?nParam?);
?8?

?9?//?動(dòng)態(tài)鏈接庫(kù)的靜態(tài)調(diào)用:
10?#pragma?comment(lib,"dllExam.lib" )?
11?extern?"C"?__declspec(dllimport)?/*__stdcall*/?Func(?int
?nParam?);
12?

13?dllFun(0 );
14?

15?// ?動(dòng)態(tài)鏈接庫(kù)的動(dòng)態(tài)調(diào)用:
16?//?useDllExam.cpp

17?typedef?void(/*__stdcall*/?*CallFun?)(?int?);????//?宏定義,方便使用
18?
19?HINSTANCE?hDll;????????????????????????//?DLL句柄
20?CallFun?dllFun;????????????????????????//?庫(kù)函數(shù)指針
21?hDll?=?LoadLibrary(?"dllExam.dll" ?);
22?if
(?hDll?)
23?
{
24?????dllFun?=?(CallFun)GetProcAddress(hDll,?"Func"
);
25?????if
?(?dllFun?)
26?
????{
27?????????dllFun(0
);
28?
????}
29?
????FreeLibrary(hDll);
30?}


動(dòng)態(tài)鏈接庫(kù)的一般應(yīng)用都在這兒了,更加具體的就要去問(wèn)google了:)。

//-------------------------------------------------------------------------------
// 異步回調(diào) ( Asynchronism Callback )

今天想說(shuō)的主要內(nèi)容是異步回調(diào)。大致結(jié)構(gòu)是:

//-------------------------------------------------------------------------------
//??????????????? ?????????? IAsyncCaller? IAsyncCallback
//???????????????????????????????????????? \??? /
// CManager --> CSession --> CEvent
//-------------------------------------------------------------------------------
// class :??CManager
// function :?Singleton實(shí)現(xiàn),管理所有CSession對(duì)象

// class :??CSession
// function :?處理會(huì)話,關(guān)聯(lián)事務(wù)

// class :??CEvent
// function :?Session的關(guān)聯(lián)對(duì)象,處理異步回調(diào)
// base class:?IAsyncCaller, IAsyncCallback

在發(fā)起session的時(shí)候,new一個(gè)CSession對(duì)象,為其分配一個(gè)GUID,并加入管理session的CManager對(duì)象的map(支持多線程操作),new一個(gè)CEvent對(duì)象,將該CEvent對(duì)象設(shè)置為回調(diào)響應(yīng)的host,該CEvent對(duì)象可進(jìn)行其他同步處理。

當(dāng)回調(diào)條件滿足,由CManager通過(guò)相應(yīng)CSession對(duì)象觸發(fā),并交由其關(guān)聯(lián)的CEvent對(duì)象處理。

如果CEvent應(yīng)用規(guī)模較小,可由CManager的map直接管理,省掉CSession的中間處理。

這種處理方式的優(yōu)點(diǎn)是,將普通事務(wù)的回調(diào)處理機(jī)制抽象為通過(guò)Session Manager(CManager)進(jìn)行統(tǒng)一管理,普通事務(wù)的處理放到main thread中,線程間通信則交給CManager和CSession,實(shí)現(xiàn)了良好封裝。

//-------------------------------------------------------------------------------
// 具體實(shí)現(xiàn)這里就不給出了,用到的TX根據(jù)上面的描述應(yīng)該大概知道怎么做了。其他TX如果不清楚的話,
// 清楚的話,可以先google其中的一些關(guān)鍵詞。動(dòng)態(tài)鏈接庫(kù)的部分因?yàn)閮?nèi)容很少,因此也只提供基礎(chǔ)使用。
//
// PS: 因?yàn)镚F學(xué)知識(shí)產(chǎn)權(quán)的,剛好了解到有這樣一個(gè)“創(chuàng)作共用”協(xié)議,而且最近很多人在討論
// cppblog的原創(chuàng)精神問(wèn)題,于是大家就看到我blog頂部的這個(gè)東西:)。
// 注釋風(fēng)格也改成自己平時(shí)用的了:)。
//-------------------------------------------------------------------------------

posted @ 2008-01-23 11:04 Fox 閱讀(2444) | 評(píng)論 (4)編輯 收藏

Author: Fox

一、多線程安全的引入:

關(guān)于什么是多線程、為什么使用多線程的問(wèn)題,大家可以看看Jim Beveridge & Robert Wiener的《Win32多線程程序設(shè)計(jì)》(侯捷 譯),或者其他隨便一本提到多線程的書(shū)或文章。這里只是提到Windows環(huán)境下多線程容易引發(fā)的問(wèn)題和解決辦法。

1、線程在時(shí)間片結(jié)束時(shí)退出做不到

由于Windows屬于分時(shí)操作系統(tǒng),系統(tǒng)會(huì)為每個(gè)線程分配響應(yīng)的時(shí)間片使其工作,絕大多數(shù)線程不可能在時(shí)間片結(jié)束的時(shí)候完成其工作,而下一個(gè)時(shí)間片就有可能分配給其他線程。

2、線程獨(dú)立做不到

如果線程間不存在依賴關(guān)系,即線程A的執(zhí)行不依賴于線程B的執(zhí)行,此時(shí)即使線程B被打斷,由于線程獨(dú)立,所以二者也可以相安無(wú)事。

然而,在多線程解決方案中,線程間的通信是頻繁而且必要的。線程通信主要有兩種情況:

1) 多個(gè)線程共享相同資源;

2) 一個(gè)線程的執(zhí)行依賴于其他線程的結(jié)果或執(zhí)行情況。

這時(shí),我們就需要實(shí)現(xiàn)共享資源及線程執(zhí)行的同步。

二、多線程安全的解決方案:

因此,多線程安全的目標(biāo)就是實(shí)現(xiàn)共享資源的互斥訪問(wèn)和線程執(zhí)行的同步通信。

通過(guò)對(duì)操作系統(tǒng)的學(xué)習(xí),我們知道線程同步主要有以下方法:

1) 臨界段(Critical Section)

a) 臨界資源的取舍,宜少不宜多,宜短不宜長(zhǎng),一個(gè)線程只能最多等待一個(gè)臨界段;

b) 無(wú)法偵測(cè)一個(gè)臨界段是否已經(jīng)被放棄;

c) 臨界段屬于用戶對(duì)象。

2) 互斥鎖(Mutex)

同臨界段一樣,互斥鎖也主要用于保證資源的原子訪問(wèn),二者的不同之處在于:

a) 互斥鎖屬于可具名內(nèi)核對(duì)象;

b) 互斥鎖可以跨進(jìn)程使用,臨界段只能用于同一進(jìn)程內(nèi);

c) 互斥鎖可以指定等待時(shí)間,而且可以等待其他內(nèi)核對(duì)象。

3) 事件(Event)

a) 事件重置具有人工重置和自動(dòng)重置兩種方式,簡(jiǎn)單說(shuō)來(lái),二者分別用于多讀和單寫(xiě);

b) 事件主要用于線程間相互通知(喚醒);

C) 事件屬于可具名內(nèi)核對(duì)象。

4) 信號(hào)量(Semaphore)

a) 信號(hào)量屬于可具名內(nèi)核對(duì)象;

b) 信號(hào)量沒(méi)有擁有者,可被任一線程釋放;

關(guān)于Win32中這四種對(duì)象的使用和要點(diǎn),更詳細(xì)的介紹可以參照《Win32多線程程序設(shè)計(jì)》或《Windows核心編程》(Jeffrey Richter)等。

三、多線程安全的實(shí)現(xiàn):

將對(duì)數(shù)據(jù)(對(duì)象、模型、消息、Socket)的I/O處理放在同一個(gè)I/O線程中,保證如隊(duì)列的push/pop操作、鏈表的insert/delete操作、文件的write操作、socket的recv/send操作、全局變量的write操作等的互斥訪問(wèn)。

新建獨(dú)立模塊,尤其是使用第三方庫(kù)的獨(dú)立模塊,大多會(huì)創(chuàng)建獨(dú)立的新線程。此時(shí)就需要對(duì)新線程中的數(shù)據(jù)操作加以注意,可以通過(guò)對(duì)操作數(shù)據(jù)的加鎖訪問(wèn)解決同步問(wèn)題,當(dāng)然,更常見(jiàn)的處理方式是將新線程中的數(shù)據(jù)操作發(fā)送到專門(mén)的I/O線程中處理。

總之,多線程安全是個(gè)常說(shuō)常新的話題,現(xiàn)在有人提出Lock-Free數(shù)據(jù)結(jié)構(gòu)的解決方案(Maged M. Michael),也有所謂的Wait-Free的解決方案(Maurice Herlihy),而國(guó)內(nèi)網(wǎng)游界的大牛云風(fēng)同學(xué)更是提出了單線程多進(jìn)程的觀點(diǎn)和解決方案(因?yàn)椴涣私?,按字面有可能存在斷章取義之嫌)。但不管怎么樣,從中至少可以看出,多線程,說(shuō)來(lái)話長(zhǎng)。

零零散散、東拉西扯、不知所云的講了一些東西,未必正確,更不能當(dāng)作知識(shí)。全當(dāng)是對(duì)上次的承諾有個(gè)交代。

/*****************************************************************************
?想把多線程的問(wèn)題搞明白,不是說(shuō)看看操作系統(tǒng)教材,寫(xiě)點(diǎn)多線程讀寫(xiě)的代碼就夠的。且不論孰是孰非,
?單就網(wǎng)上諸多高手新學(xué)對(duì)加鎖策略鋪天蓋地的爭(zhēng)執(zhí)說(shuō)辭甚至相互批判指責(zé),足可見(jiàn)多線程開(kāi)發(fā)并非只言
?片語(yǔ)即可挑明。
?為防止陷入細(xì)節(jié)爭(zhēng)論,這里先作聲明:小文僅就所學(xué)略抒拙見(jiàn),無(wú)意引起爭(zhēng)端……
*****************************************************************************/

posted @ 2008-01-10 04:02 Fox 閱讀(2742) | 評(píng)論 (10)編輯 收藏

Author: Fox

元旦放假3天,本來(lái)想把前面寫(xiě)的一個(gè)存在線程安全隱患的模塊推倒重來(lái)的,可是改著改著就覺(jué)得不對(duì)勁了。

既然是返工,就想盡量把現(xiàn)在的理解完全加進(jìn)去,讓后面的人看了不要罵??墒窍氚褞浊械拇a改得面目全非并且更加安全準(zhǔn)確也并不是一件容易的事,雖然對(duì)于功能和邏輯的認(rèn)識(shí)比以前要清晰的多。

拿到一個(gè)新的模塊,上面一般會(huì)給個(gè)大致的deadline。除非你對(duì)這個(gè)模塊和整個(gè)項(xiàng)目的依賴關(guān)系(接口、邏輯、功能)有很好的把握,否則,你根本不知道到底有多少東西是已經(jīng)實(shí)現(xiàn)的,有多少東西是可以復(fù)用的,有多少東西是需要修改的,有多少東西是要重寫(xiě)的,有多少東西是要新加的,僅僅根據(jù)需求預(yù)估的進(jìn)度是不可能恰到好處的。而脫離了整個(gè)項(xiàng)目實(shí)現(xiàn)的模塊是非??赡艹鰡?wèn)題的,尤其是在使用多線程的項(xiàng)目中。

當(dāng)我的這個(gè)模塊完成并上馬之后,我沾沾自喜的跟上面說(shuō),應(yīng)該是不會(huì)有問(wèn)題了,上面跟我說(shuō)了一句:如果不出問(wèn)題就是奇跡了,我當(dāng)時(shí)頗不以為然。在后面一兩周之內(nèi)真的就是沒(méi)有什么問(wèn)題,我真想告訴他是我創(chuàng)造了奇跡。

“奇跡”在2007年的最后一周破滅了。在我從西嶺雪山回來(lái)的那天,為了增加新功能把代碼修改了一些,結(jié)果第二天更新之后,服務(wù)器就老是有問(wèn)題,找了一下午,才發(fā)現(xiàn)在修改代碼的時(shí)候居然忘記對(duì)一個(gè)pointer做NULL判定!我心想,這種錯(cuò)誤居然都出來(lái)了!死了算了!而且這個(gè)問(wèn)題出在非主線程中。然后就和同事在考慮,這個(gè)東西如果線程同步出現(xiàn)問(wèn)題,你就是每次使用前都做NULL判定也沒(méi)用,所以就決定把這個(gè)模塊重寫(xiě)了。

在這兒我就不想就線程安全問(wèn)題多說(shuō)了,以后想好了再專門(mén)去寫(xiě)點(diǎn)多線程的東西吧,今天只是想說(shuō)點(diǎn)瑣碎的東西。

因?yàn)槭欠偶?,心思未必就全部放在上面了,代碼沒(méi)改多少,倒是玩了很長(zhǎng)時(shí)間的游戲。后來(lái)想想,也不全是時(shí)間問(wèn)題,幾千行的代碼改來(lái)改去,難保不出現(xiàn)更多的問(wèn)題。必須把它當(dāng)作一個(gè)新的模塊去寫(xiě),先要把邏輯結(jié)構(gòu)完全理出來(lái),能多細(xì)化就多細(xì)化,最好能夠精確到變量的使用,而且把文檔做細(xì),這樣就可以在寫(xiě)文檔的過(guò)程中把問(wèn)題盡可能想全想清楚。改代碼先改文檔,這幾乎是所有學(xué)過(guò)軟件工程并寫(xiě)過(guò)項(xiàng)目的同學(xué)都能認(rèn)識(shí)并理解的常識(shí),可是在實(shí)際工作中,上有任務(wù)催趕,下有閑心雜念,很難把文檔和注釋寫(xiě)好。而做不到這一點(diǎn)的話,你就不敢保證你的模塊不出差錯(cuò)。

所以,對(duì)于一個(gè)一般的需求,如果deadline是2個(gè)月的話。讀需求、評(píng)估依賴關(guān)系、量進(jìn)度要花掉1周,畫(huà)邏輯結(jié)構(gòu)、寫(xiě)文檔要花掉3周,相當(dāng)于前面一半的時(shí)間沒(méi)有動(dòng)手寫(xiě)代碼,然后寫(xiě)代碼大概只用1周,甚至更少,其他時(shí)間就留給測(cè)試和修改文檔、代碼了。從軟件工程的角度,這樣的分配是合理的,而且是應(yīng)該的,但到了實(shí)際項(xiàng)目里面,又做不到!看來(lái),不管是manager,還是coder,都不能急,軟件工程不能白學(xué)了。

我發(fā)現(xiàn),我的軟件工程就是白學(xué)了,以后得改改。

/*****************************************************************************
?不想回頭去動(dòng)以前的代碼,每次看以前寫(xiě)過(guò)的東西,都有一種想把它徹底刪除的沖動(dòng)。
?把需求看好、文檔寫(xiě)好、時(shí)間安排好,這才是硬道理……

?畢竟是新年,還是祝大家:新年快樂(lè)!
?重要的是,新的一年,別荒廢了……
*****************************************************************************/

posted @ 2008-01-02 02:43 Fox 閱讀(801) | 評(píng)論 (6)編輯 收藏

Author: Fox

對(duì)于(1+2+...+N) 的求和,最早就是看高斯的故事,而且說(shuō)實(shí)話,我是沒(méi)有這樣的智商的:

????????????????sum(1+2+...+N) = N*(N+1)/2

剛看了一篇研究該級(jí)數(shù)求和的文章,雖為調(diào)侃,但實(shí)在感覺(jué)文中紕漏太多,不禁在此多言。

文中的第一種方法自稱標(biāo)準(zhǔn),而且還能使“全班2/3的同學(xué)都用俺的標(biāo)準(zhǔn)應(yīng)付老師和試卷”,我大為驚詫:

1?int?i,?sum?=?0 ;
2?for(i?=?1;i?<?N;i?++)sum?+=
?i;
3?printf("1-N的級(jí)數(shù)和是:?%i",sum);


顯然,printf的結(jié)果是N-1個(gè)數(shù)的和,此處,我更愿意相信是文中的筆誤而已。

第二種和第三種方法讓人覺(jué)得奇怪:

1?float ?sum;
2?sum?=?(N?^?2)?/?2?+?N?/?2
;
3?printf("1-N的級(jí)數(shù)和是:?%i",(int
)sum);
4?

5?float ?sum;
6?sum?=?N?*?(N?/?2?+?0.5
);
7?printf("1-N的級(jí)數(shù)和是:?%i",(int)sum);


前面的寫(xiě)法純屬惡搞,^在C/C++中是異或位操作,相信接觸過(guò)位運(yùn)算的人都知道這一點(diǎn),而且當(dāng)N為奇數(shù)時(shí),sum的結(jié)果將比真實(shí)值少1。后面的寫(xiě)法更是荒唐,當(dāng)N為奇數(shù)時(shí),sum的結(jié)果將比真實(shí)值相去更遠(yuǎn)(有興趣的可以仔細(xì)看看)。

對(duì)于后面兩種寫(xiě)法,我想說(shuō)的重點(diǎn)不是這些明顯的錯(cuò)誤,因?yàn)檫@樣的錯(cuò)誤只可博眾君一笑。但文中定義sum使用float的做法,讓我百思不得其解。對(duì)于計(jì)算機(jī)的運(yùn)算,浮點(diǎn)運(yùn)算的耗時(shí)和整型運(yùn)算的耗時(shí),那不是一個(gè)數(shù)量級(jí)的。對(duì)于該級(jí)數(shù)運(yùn)算,我們完全可以避免浮點(diǎn)運(yùn)算,而且方法在文章一開(kāi)始,就已經(jīng)給出了:

1?int ?sum;
2?sum?=?N*(N+1)/2
;
3?printf("1-N的級(jí)數(shù)和是:?%i",?sum);


無(wú)論N為奇數(shù)還是偶數(shù),N*(N+1)一定是偶數(shù),因此,上述方法不存在浮點(diǎn)運(yùn)算,而且系統(tǒng)會(huì)自動(dòng)將/2的操作優(yōu)化為右移1位。

不知怎么,忽然就想到了遞歸,想到了Fibonacci數(shù)列。講遞歸的教材都會(huì)拿上面的級(jí)數(shù)求和和Fibonacci數(shù)列做例子。其實(shí),我個(gè)人感覺(jué)這是不恰當(dāng)?shù)?,但想想為了讓學(xué)生掌握遞歸算法,也只能舉類(lèi)似的簡(jiǎn)單的例子。我們也知道,遞歸計(jì)算對(duì)于堆棧調(diào)用是非常頻繁而耗時(shí)的,對(duì)于求Hanoi塔這樣的復(fù)雜問(wèn)題,我不知道不用遞歸有沒(méi)有更好的方法,但如果計(jì)算Fibonacci數(shù)列還是使用遞歸,在初學(xué)遞歸時(shí)是可以原諒的。簡(jiǎn)單點(diǎn)的方法可以是這樣:

?1?int?fib_odd?=?0,?fib_even?=?1 ?;
?2?int?n?=?(N+1)/2
;
?3?for(int?i=0;?i<n;?i++
?)
?4?
{
?5???fib_odd?+=
??fib_even;
?6???fib_even?+=
??fib_odd;
?7?
}
?8?int?nFib?=?0
;
?9?if(?N?%?2
?)
10???nFib?=
?fib_odd;
11?else

12???nFib?= ?fib_even;
13?printf("Fibonacci數(shù)列前N項(xiàng)和是:?%i",nFib);?


上面的兩段代碼中sum和nFib的值不能太大:)。

常言道,言過(guò)必失。但自私一點(diǎn)講,把自己的錯(cuò)誤暴露給別人,可以讓自己更好的進(jìn)步:),因此,我寫(xiě)下來(lái),提醒自己也提醒大家,更歡迎大家多批評(píng)指正。

posted @ 2007-12-21 10:19 Fox 閱讀(3385) | 評(píng)論 (10)編輯 收藏

Author: Fox

俗話說(shuō),道高一尺,魔高一丈。

今天在一個(gè)群里,有人提到某某算法(3DES)可以杜絕外掛。我當(dāng)時(shí)心里苦笑一聲:哥們兒,太逗了。這年頭,中國(guó)人已經(jīng)被忽悠怕了。我信鬼信魔,就是不信佛……

不過(guò)想想,如果能在一定程度上打擊外掛,也不錯(cuò),可是討論了半天,愣是沒(méi)有給出具體的方案,最后還是不了了之。

不過(guò),有時(shí)間把思路整理整理,提一個(gè)稍微好一點(diǎn)的方法也好。

王城里面,一排排的外掛小號(hào)像閱兵一樣,囂張成馬了,完全不把我們放在眼里。

話說(shuō)回來(lái),連個(gè)脫機(jī)外掛都防不住,別人還確實(shí)沒(méi)必要把你放在眼里。

這邊Login Server搞了兩三個(gè)月的驗(yàn)證碼,感覺(jué)不錯(cuò),因?yàn)椴皇褂猛鈷斓耐婕颐看味家垓v半天,我們自己人員輸入驗(yàn)證碼輸?shù)亩紵?,結(jié)果沒(méi)出半個(gè)月外掛又開(kāi)始橫行了,感覺(jué)比以前還囂張。

我是外掛,我得意的笑,我得意的笑……

敢情是防賊沒(méi)防住,把賊扔屋里,自己被鎖在外面了!

/*****************************************************************************
? 晚上本來(lái)想自己寫(xiě)個(gè)內(nèi)掛,可以偷偷懶,可惜對(duì)這東西實(shí)在是從來(lái)沒(méi)有過(guò)研究。
??折騰了一晚上,郁郁而終。
? 技不如人??!想來(lái)都覺(jué)得可笑……
*****************************************************************************/

posted @ 2007-12-20 02:08 Fox 閱讀(2219) | 評(píng)論 (21)編輯 收藏

僅列出標(biāo)題
共7頁(yè): 1 2 3 4 5 6 7 
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国内激情久久| 99re6这里只有精品| 亚洲国产综合视频在线观看| 国模精品一区二区三区| 国产一区二区按摩在线观看| 国产一区二区三区电影在线观看| 国产精品亚洲综合一区在线观看| 国产亚洲日本欧美韩国| 在线国产精品播放| 亚洲伦理一区| 亚洲一区二区三区精品视频| 午夜视频一区在线观看| 久久久国产午夜精品| 免费在线观看精品| 一区二区三区精品国产| 午夜久久一区| 欧美高清视频一区| 国产裸体写真av一区二区| 精品不卡在线| 亚洲自拍偷拍视频| 男女av一区三区二区色多| 亚洲人妖在线| 欧美一区二区日韩一区二区| 免费视频一区| 国产视频丨精品|在线观看| 亚洲经典三级| 久久精品毛片| 一本久久综合| 欧美精品性视频| 在线观看欧美| 欧美一级黄色录像| 亚洲精品一区二区三区蜜桃久| 性欧美1819sex性高清| 欧美久久久久久久| 在线免费观看欧美| 久久超碰97人人做人人爱| 亚洲精品美女在线观看| 裸体丰满少妇做受久久99精品| 国产精品v亚洲精品v日韩精品| 久久久久网站| 国产欧美日韩精品丝袜高跟鞋| 亚洲高清视频一区二区| 欧美一区二区三区四区高清 | 免费观看日韩| 亚洲综合三区| 国产精品久久久久久久久借妻| 亚洲国产精品一区二区久| 久久精品99国产精品日本 | 久久精品30| 国产精品羞羞答答| 亚洲综合视频1区| 日韩视频―中文字幕| 欧美xart系列高清| 尤物yw午夜国产精品视频| 久久久青草青青国产亚洲免观| 亚洲综合国产激情另类一区| 欧美午夜精品| 亚洲欧美一级二级三级| 一区二区三区高清不卡| 欧美手机在线| 欧美亚洲系列| 久久av一区| 亚洲国产精品va在线观看黑人| 免费观看在线综合| 猛男gaygay欧美视频| 亚洲欧洲日本在线| 亚洲国产欧美在线人成| 欧美激情综合五月色丁香| 亚洲精品视频在线| 亚洲乱码国产乱码精品精可以看 | 最新亚洲一区| 亚洲精品日韩一| 欧美日韩午夜在线| 亚洲欧美在线磁力| 香蕉国产精品偷在线观看不卡 | 欧美精品123区| 中文国产成人精品久久一| av成人免费观看| 国产精品视频最多的网站| 久久精品国产久精国产思思| 久久精品国产亚洲精品| 亚洲国产欧美一区| 在线综合亚洲欧美在线视频| 国产视频一区免费看| 欧美福利视频一区| 欧美日韩综合精品| 久久精品久久99精品久久| 久久尤物视频| 亚洲一区三区在线观看| 韩国欧美国产1区| 亚洲第一区在线观看| 欧美成在线观看| 欧美精品一区二区在线观看| 午夜国产不卡在线观看视频| 欧美一区二视频| 一区二区欧美视频| 久久精品国产综合| 亚洲一区视频| 欧美www视频| 久久久99爱| 欧美丝袜第一区| 美日韩免费视频| 国产精品一区二区欧美| 亚洲韩国青草视频| 国内精品视频在线播放| 亚洲人成在线播放| 在线成人小视频| 亚洲一区日韩| 99视频+国产日韩欧美| 久久成人亚洲| 午夜激情一区| 欧美三区在线观看| 亚洲丰满少妇videoshd| 国产一区二区黄| 中日韩视频在线观看| 亚洲激情在线观看视频免费| 久久av一区二区三区漫画| 亚洲专区一区| 欧美日韩一区二区在线观看 | 久久久久久久久久久久久女国产乱| 欧美成人精品不卡视频在线观看| 欧美中在线观看| 国产精品夜夜嗨| 亚洲图片欧洲图片av| 中日韩高清电影网| 欧美日韩理论| 亚洲精品久久久一区二区三区| 精品999成人| 久久国产精品免费一区| 久久精品国产99国产精品澳门| 国产精品久久久久影院色老大 | 另类激情亚洲| 欧美成人综合| 亚洲国产高清高潮精品美女| 久久xxxx| 免费成人av在线| 亚洲高清毛片| 欧美成人中文字幕| 亚洲国产精品欧美一二99| 亚洲国产一区二区三区高清| 久热精品在线视频| 亚洲成人在线免费| 久久久久久高潮国产精品视| 国产精品美女在线| 亚洲小说欧美另类社区| 亚洲一区久久久| 国内揄拍国内精品少妇国语| 欧美激情精品久久久久久蜜臀| 精品成人一区二区| 久久蜜桃香蕉精品一区二区三区| 久久亚洲综合色| 在线激情影院一区| 美女性感视频久久久| 亚洲国产日韩美| 亚洲一区在线直播| 国产日韩精品一区二区三区在线| 久久精品成人一区二区三区| 欧美成人亚洲成人日韩成人| 亚洲免费观看高清完整版在线观看熊| 欧美日韩国产探花| 午夜精品福利电影| 欧美大片在线观看一区二区| 亚洲美女在线一区| 国产精品自在欧美一区| 久久久亚洲高清| 一本色道久久加勒比精品| 久久精品亚洲| 日韩视频一区二区三区| 国产精品普通话对白| 久久久视频精品| 中文高清一区| 欧美成人官网二区| 亚洲免费一区二区| 亚洲国产精品va在线观看黑人| 欧美天堂亚洲电影院在线播放 | 美女免费视频一区| 亚洲视频专区在线| 欧美成人精品一区| 午夜精品美女久久久久av福利| 在线日韩欧美| 国产精品一二三四区| 欧美成人精品在线视频| 午夜精品剧场| 亚洲最新视频在线| 欧美搞黄网站| 久久久国产精品亚洲一区| 夜夜嗨av色一区二区不卡| 狠狠色综合网| 国产精品久久久久久久第一福利| 老司机免费视频一区二区三区| 亚洲一级电影| 日韩一级免费观看| 欧美风情在线观看| 久久亚洲综合网| 欧美一区三区三区高中清蜜桃 | 欧美国产日本| 久久精品国产91精品亚洲| 亚洲图片自拍偷拍| 亚洲精品欧洲精品| 亚洲欧洲中文日韩久久av乱码|