各位好孩子千萬不要學哦～

感謝告知。

半路：
噢！這個實在太酷了～～
只要在程式中有使用到 sort, find, for_each 等 STL algorithm，
就能夠不改一行程式碼的享受到多核運算的好處。真是夠神！
如果有時間的話，應該要來試用看看。

非常感謝您的分享～ ：D

所以如果有許多執行緒有共用鎖的行為, 理論上最好能放在同一個核上執行.
多核中的記憶體同步是個有趣的研究問題, 不管在硬體設計或是編譯器, 作業系統支援.

半路：
感謝提供有用的知識連結～ ：D

原來鎖的存在會造成核心數目提升效能的瓶頸，
難怪要逐漸往 Lock-Free Algorithm 的方向前進了。
我想，未來的硬體架構，應該也會提供更好的多緒程式支援性。
目前的狀況下，還是盡可能減少鎖定的使用吧。

這是微軟在 GDC 2008 的其中一篇演講資料，下載檔案中有包含投影片檔以及錄音檔。這個 PPT 的內容真的非常不錯，值得一讀！除了投影片的內容外，也別忘記閱讀底下備忘稿的部分，有更詳細的解釋與說明文字。或者也可以一面閱讀，一面聽內附的錄音檔。

其中提到了三種多緒的執行模型 (Execution Models)：

• Bulk Synchronous Processing (BSP)
• Communication Sequential Processes (CSP)
• Task Pool

目前最熱門也是最複雜的技術，應該就屬 Task Pool 的執行模型了。
等我學習完之後，再寫範例程式來試試～：D

除了以上介紹的方案，我覺得一個常用的多緒方式是 producer-consumer pattern。

而有時候，使用 multi-thread 不是因為 single thread 效能不足，而是因為要等 I/O，例如 background loading 就算是單核也需要 multi-thread。最近玩Xbox360，發覺不少遊戲還是在過關卡時等很長的載入時間，一般歐美遊戲在這方面比日本遊戲好。

另外，前文中的

Lock kLock;

我覺得應該改為

Lock kLock(m_kMutex);
// Lock::Lock(Mutex& mutex) : mMutex(mutex) { mutex->Lock(); }
// Lock::~Lock() { mMutex->Unlock() }

如果只是從 local variable (lock) 裡建立 mutex 就沒有意義了? 還是有其他背後的精妙之處?

半路：
Producer-Consumer Pattern 是指將 threads 當作 Consumer，由 Producer 產生任務分派給各個 threads 進行工作嗎？不知道和 threading pool 的概念有沒有相似性呢。

現在遊戲的資料量越來越龐大，Background Loading 的重要性也越來越高。如果在傳統單核心 CPU 的情況下使用多緒，會對遊戲主程式迴圈造成效能影響，但是如果在多核系統中，就應該能夠比較適當地使用 Background Loading 才對；但是不止日本遊戲在這方面做得不夠好，台灣也幾乎沒看過使用這項技術的遊戲。

沒錯，Lock kLock(m_kMutex) 才是正確的用法。 Orz
文章內容已更正，感謝堪誤。