Design Patterns for Game Programming -- Reference Count

這是提供入行的新人教育訓練用，我們自己整理的Game Programming中的Design Patterns。我們所想到的第一個項目，就是Reference Count。所以就先將它整理出來了。

既然是寫設計模式，自然必須依照設計模式經典的編排方式來做。

以下進入正題。

 

Design Patterns for Game Programming -- Reference Count

使用時機

遊戲程式中充滿了使用記憶體資源的物件，其中有些物件的特性是，佔用大量的記憶體，又常常重複出現在遊戲中。例如，3D遊戲中的模型、貼圖，2D遊戲中的圖片資源等等。

(場景中重複出現的樹木就包括了重複使用的模型與貼圖) ( Screen-Shot from World of Warcraft )

針對這種物件，我們會將它設計成共享的資源物件，以節省記憶體的使用量。同時，我們也在共享資源物件中，加入參照計數(Reference Count)，以便記錄每個共享資源所被參照的數量。

目的

將共用的資源做有效的管理。改善資源與記憶體的使用。

設計實作

架構上主要有三種物件。

Shared Resource :

也就是共享的資源物件，像是貼圖、模型、圖片等。成員變數m_iReferenceCount記錄的就是參照計數，而IncRefCount與DecRefCount則是用來對Reference Count遞增與遞減之用。每個Resource有一個唯一的Key值(例如，資源檔案名稱或是某種編碼後的整數)。

Resource Table :

存放Shared Resource的地方，通常會使用Hash Map、Binary Tree或是其他能夠快速的從Resource Key值搜尋物件的資料結構。

Resource Manager :

做為與應用程式溝通的介面物件。提供兩個最主要的成員函式 : Query Resource 與 Release Resource。

應用程式透過呼叫Resource Manager的Query Resource函式，來取得共享資源。

首先會在Resource Table中搜尋是否有對應Key值的資源存在，如果存在，就將資源的參照計數遞增之後，傳回給應用程式。如果不存在，就產生一個新的資源( 此時新資源的參照計數為1 )，插入Resource Table中，然後傳回給應用程式。

另外，應用程式也透過Resource Manager的Release Resource函式來釋放資源。

首先Manager會先將Resource的參照計數遞減，並且取得結果。如果參照計數小於或等於0，表示已經不再需要這個共享資源，就先從Resource Table中將資源移除，然後，刪除這個資源。

多緒環境下的設計實作

有兩項必須做到Thread-Safe，一是Resource Table的存取，避免多個執行緒同時修改Table內容以及相關的索引資料，另一個則是Reference Count的遞增與遞減計算，避免多個執行緒同時修改，造成資料錯誤。

使用設計上的限制

1. 在這個機制下，共享資源的生成與銷毀都必須是透過Manager的Query / Release來負責，應用程式要避免直接使用new / delete來生成 / 銷毀共享資源。一個可用的設計方式是，將資源物件的建構子與解構子封裝起來不公開，封鎖應用程式對共享資源的new / delete權限，同時宣告Manager為friend class，把權限讓給Manager。

2. 共享資源的Inc / Dec Reference Count操作必須是成對的，否則容易出現Memory Leak ( 當 Inc Reference Count次數大於 Dec Reference Count時 ) 或是使用到無效的指標 ( 當 Inc Reference Count次數小於 Dec Reference Count時 )。這項限制，可以透過Smart Pointer的設計來改善。