Nebula3的代碼運(yùn)行在兩種根本不同的方案中. 第一種方案我稱之為”Fat Thread”. 一個(gè)Fat Thread在一個(gè)線程中運(yùn)行一個(gè)完整的子系統(tǒng)(如渲染, 音頻, AI, 物理, 資源管理), 并且基本上鎖定在一個(gè)特定的核心上.

第二種類型的線程我叫它”Job”. 一個(gè)job是一些數(shù)據(jù)和用于處理這些數(shù)據(jù)的包裝成C++對(duì)象的代碼. 工作調(diào)度程序掌管了Job對(duì)象, 并且把工作分配給低負(fù)載的核心來保持它們一直處于忙碌狀態(tài).

顯然, 挑戰(zhàn)就是設(shè)計(jì)一個(gè)經(jīng)過全面考慮的系統(tǒng), 以保持所有的核心一直均勻地忙碌著. 這不但意味著連續(xù)的活動(dòng)需要在游戲每幀的空閑時(shí)期內(nèi)輪流交替, 而且要求job對(duì)象不得不事先(如每幀前)創(chuàng)建好, 這樣才能在各種Fat Thread空閑時(shí)填充當(dāng)前幀的空白.

這是我希望進(jìn)行更多試驗(yàn)和調(diào)整的地方.

第二個(gè)挑戰(zhàn)就是讓程序員的工作盡量的簡單. 一個(gè)游戲應(yīng)用程序員(邏輯程序員)在任何時(shí)候都不應(yīng)該關(guān)心他運(yùn)行在一個(gè)多線程的環(huán)境中, 不應(yīng)該擔(dān)心會(huì)產(chǎn)生死鎖或改寫了其它線程的數(shù)據(jù), 也不應(yīng)該瞎搞一些臨界區(qū), 事件和信號(hào)量. 同樣, 整個(gè)引擎的架構(gòu)也不應(yīng)該是”脆弱的”. 大部分傳統(tǒng)的多線程代碼在一定程度上都會(huì)發(fā)生紊亂, 或者忘記了臨界區(qū)而打亂數(shù)據(jù).

當(dāng)線程間需要進(jìn)行數(shù)據(jù)共享和通信時(shí), 多線程就變得很棘手. 像兩個(gè)臨界區(qū)這樣的解決方案也會(huì)導(dǎo)致脆弱代碼問題.

從大的角度來說, Nebula3通過一個(gè)”并行Nebula”的概念解決了這個(gè)兩個(gè)問題. 其思想就是運(yùn)行了一個(gè)完整子系統(tǒng)的”Fat Thread”都有自己的最小Nebula運(yùn)行庫, 這個(gè)最小運(yùn)行庫剛好包含了這個(gè)子系統(tǒng)需要的部分. 因此, 如果這個(gè)運(yùn)行在它自己線程中的子系統(tǒng)需要進(jìn)行文件訪問, 它會(huì)有一個(gè)跟其它Fat Thread完全分離的文件服務(wù)器(file server). 這個(gè)解決方案的優(yōu)點(diǎn)是, 大部分Nebula中的代碼都不需要知道它運(yùn)行在一個(gè)多線程的環(huán)境中, 因?yàn)樵趂at thread之間沒有數(shù)據(jù)進(jìn)行共享. 運(yùn)行著的每個(gè)最小Nebula內(nèi)核是跟其它Nebula內(nèi)核完全隔離的. 缺點(diǎn)就是, 重復(fù)的數(shù)據(jù)會(huì)浪費(fèi)一些內(nèi)存, 但是我們只是占用幾KB, 而不是MB.

這些數(shù)據(jù)冗余消除了細(xì)密的鎖定, 并且解決把程序員從思考每一行代碼的多線程安全性中解放了出來.

當(dāng)然, 從某種意義上說Fat Thread間的通信是肯定會(huì)發(fā)生的, 要不然這整個(gè)思想就沒有意義了. 方法就是建立一個(gè)且只有一個(gè)的標(biāo)準(zhǔn)通信系統(tǒng), 并且保證這個(gè)通信系統(tǒng)是可靠而快速的. 這就是消息系統(tǒng)的由來. 要跟一個(gè)Fat Thread通信的話只有發(fā)送一個(gè)消息給它. 消息是一個(gè)簡單的C++對(duì)象, 它包含了一些帶有g(shù)et/set方法的數(shù)據(jù). 通過這個(gè)標(biāo)準(zhǔn)的通信手段, 實(shí)際上只有消息子系統(tǒng)才需要是線程安全的(同樣, 訪問跟消息相關(guān)的資源時(shí), 如內(nèi)存緩沖區(qū), 必須受到約束, 因們它們代表了共享數(shù)據(jù)). (xoyojank: 我說咋那么多Message…)

這樣雖然解決了Fat Thread方案中大多數(shù)的多線程問題, 但沒有解決Job對(duì)象的任何事情. Nebula3很有可能需要約束一個(gè)Job對(duì)象能做什么和不能做什么. 最直接的行為就是限制job做內(nèi)存緩沖區(qū)的計(jì)算. 那樣的話, job中就不能存在復(fù)雜的運(yùn)行庫(不能文件I/O, 不能訪問渲染等等). 如果這樣還不夠的話, 必須定義一個(gè)”job運(yùn)行時(shí)環(huán)境”, 就像Fat Thread中的那樣. 因?yàn)橐粋€(gè)job不會(huì)發(fā)起它自己的線程, 而且還會(huì)被調(diào)度到一個(gè)已經(jīng)存在的線程池中. 就這個(gè)方面來說, 這不存在什么問題.

到現(xiàn)在為止(xoyojank: 2007/01/21, 最新版本已經(jīng)實(shí)現(xiàn)了多數(shù)子系統(tǒng)的多線程化), 只有IO子系統(tǒng)作為概念證明在Fat Thread中得到實(shí)現(xiàn), 并且它運(yùn)行得很今人滿意. 在做傳統(tǒng)的同步IO工作時(shí), 一個(gè)Nebula3程序可以直接調(diào)用本地線程的IO子系統(tǒng). 所以像列出文件夾的內(nèi)容或刪除一個(gè)文件, 只會(huì)調(diào)用一個(gè)簡單的C++方法. 對(duì)于異步IO工作, 定義了一些常見的IO操作消息(如ReadStream, WriteStream, CopyFile, DeleteFile, 等等). 進(jìn)行異步IO只需要幾行代碼: 創(chuàng)建一個(gè)消息對(duì)象, 填充數(shù)據(jù), 并發(fā)送這個(gè)消息到一個(gè)IOInterface單件. 如果必要的話, 這可能會(huì)需要等待和輪詢異步操作.

這樣的好處就是, 整個(gè)IO子系統(tǒng)沒有一行多線程意義上的代碼, 因?yàn)楦鱾€(gè)在不同的Fat Thread中的IO子系統(tǒng)是完全隔離的(當(dāng)然, 同步肯定會(huì)發(fā)生在一些IO操作上, 但那都留給操作系統(tǒng)了).