在實(shí)際游戲中，邏輯線程需要對(duì)渲染對(duì)象做許多操作，比如添加與刪除，改變渲染對(duì)象的屬性等等，而由于在先前的設(shè)計(jì)中，邏輯線程與渲染線程相互獨(dú)立，如果只是改變某一共享數(shù)據(jù)，沒有問題，但如果操作影響到了場景結(jié)構(gòu)，例如實(shí)體的添加與刪除，則必須進(jìn)行線程同步，這又違背了FlagshipEngine的設(shè)計(jì)初衷——避免繁重的邏輯計(jì)算影響渲染速度。
解決辦法其實(shí)在上一篇中已經(jīng)提到了，仍然是利用天然的同步機(jī)制——Windows消息，添加實(shí)體時(shí)，邏輯線程只是new了一個(gè)Entity對(duì)象，設(shè)置這個(gè)對(duì)象的初始共享數(shù)據(jù)，比如位置信息，同時(shí)向渲染線程發(fā)送一條WM_ADDENTITY的自定義消息，將Entity指針作為wParam傳遞。渲染線程接受到消息后調(diào)用Entity的UpdateScene方法，更新Entity在場景樹中的位置，并加載資源。
刪除也是一樣，邏輯線程向渲染線程發(fā)送WM_DELETEENTITY消息，并不再使用該Entity指針，渲染對(duì)象則處理改消息，將此Entity從場景中刪除并卸載資源。
這里有一個(gè)非常危險(xiǎn)的情況，前面一篇提到，資源加載也是通過消息傳遞實(shí)現(xiàn)的，同樣是傳遞的資源指針，如果邏輯線程添加了一個(gè)Entity，還沒加載就刪掉了它，則資源加載線程會(huì)拿到一個(gè)過期指針，一切就結(jié)束了。。。
解決這一問題，最穩(wěn)妥的方法是消息的wParam并不傳遞指針，而是傳遞該Entity或資源的唯一ID，這樣的話即使ID過期，也可輕松忽略掉這條消息，壞處是每次消息處理都的從全局的map里檢查是否存在此ID對(duì)應(yīng)的Entity或資源，這可是筆不小的開銷。
第二種方案，我們?nèi)匀粋鬟f指針，只是在接受到WM_DELETEENTITY消息時(shí)，檢查該Entity是否已經(jīng)加載完成，如果沒有完成，則重新將此消息加入消息隊(duì)列，下個(gè)渲染幀再次判斷。
FlagshipEngine的多線程設(shè)計(jì)大致就是如此了。