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