場景：
一個多執行緒的C++程式，24h x 5.5d執行。有幾個工作執行緒ThreadW{0,1,2,3}，處理客戶發過來的交易請求，另外有一個背景執行緒ThreadB，不定期更新程式內部的參考資料。這些執行緒都跟一個hash表打交道，工作執行緒只讀，背景執行緒讀寫，必然要用到一些同步機制，防止資料損壞。
這裡的示例程式碼用std::map代替hash表，意思是一樣的：
typedef map<string, vector<pair<string, int> > > Map;
map 的 key 是使用者名稱，value 是一個vector，裡邊存的是不同stock的最小交易間隔，vector已經排好序，可以用二分查詢。
我們的系統要求工作執行緒的延遲儘可能小，可以容忍背景執行緒的延遲略大。一天之內，背景執行緒對資料更新的次數屈指可數，最多一小時一次，更新的資料來自於網路，所以對更新的及時性不敏感。Map的資料量也不大，大約一千多條資料。
最簡單的同步辦法，用讀寫鎖，工作執行緒加讀鎖，背景執行緒加寫鎖。但是讀寫鎖的開銷比普通mutex要大，如果工作執行緒能用最普通的非重入Mutex實現同步，就不必用讀寫鎖，效能較高。我們藉助shared_ptr實現了這一點：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 |
class Mutex; class MutexLockGuard; class CustomerData { public: CustomerData() : data_(new Map) { } ~CustomerData(); int query(const string& customer, const string& stock) const { MapPtr data = getData(); // data 一旦拿到，就不再需要鎖了。取資料的時候只有getData()內部有鎖，多執行緒併發讀的效能很好。 // 假設使用者肯定存在 const EntryList& entries = (*data)[customer]; return findEntry(entries, stock); } void update(const string& customer, const EntryList& entries ); private: typedef vector<string, int> EntryList; typedef map<string, EntryList> Map; typedef tr1::shared_ptr<Map> MapPtr; static int findEntry(const EntryList& entries, const string& key) const { /* 用 lower_bound 在 entries 裡找 key */ } MapPtr getData() const { MutexLockGuard lock(dataMutex_); return data_; } MapPtr data_; mutable Mutex dataMutex_; }; |
關鍵看CustomerData::update()怎麼寫。既然要更新資料，那肯定得加鎖，如果這時候其他執行緒正在讀，那麼不能在原來的資料上修改，得建立一個副本，在副本上修改，修改完了再替換。如果沒有使用者在讀，那麼就能直接修改，節約一次拷貝。
|
1 2 3 4 5 6 7 8 9 10 11 |
void CustomerData::update(const string& customer, const EntryList& entries ) { MutexLockGuard lock(dataMutex_); if (!data_.unique()) { MapPtr newData(new Map(*data_)); data_.swap(newData); } assert(data_.unique()); (*data_)[customer] = entries; } |
注意其中用了shared_ptr::unique()來判斷是不是有人在讀，如果有人在讀，那麼我們不能直接修改，因為query()並沒有全程加鎖，只在getData()內部有鎖。shared_ptr::swap()把data_替換為新副本，而且我們還在鎖裡，不會有別的執行緒來讀，可以放心地更新。
據我們測試，大多數情況下更新都是在原來資料上進行的，拷貝的比例還不到1%，很高效。更準確的說，這不是copy-on-write，而是copy-on-other-reading。
我們將來可能會採用無鎖資料結構，不過目前這個實現已經非常好，滿足我們的要求。