以下為截止2009年3月21日前發布在本人博客中的多核相關的文章匯總，這些文章大部分摘自于我寫的《多核計算與程序設計》一書?，F將這些文章分類匯總，方便大家閱讀。

后續如果博客中繼續發布了多核相關的文章，那么本文章將會被更新。如果對多核編程技術非常感興趣的話，可以考慮將這篇文章加入您的瀏覽器收藏夾中，也歡迎您將這篇文章推薦給您的朋友。

一、基礎篇

1、多核編程的幾個難題及其應對策略

主要講解多核編程時的串行化方面的難題及其應對策略。閱讀全文

2、多核編程中的鎖競爭難題

鎖競爭會導致加速系數隨CPU核數增多而下降的現象。核數增加到128時，加速系數只有0.78，還不如在單核CPU上運行的速度。 S(p) = (t +1)/ (p + t/p) = p*(t+1) / (p*p+t) （鎖競爭下的加速系數公式） 。閱讀全文

3、多核編程中的負載平衡難題

負載平衡的難度與CPU的核數成正比，CPU核數越多，負載劃分的難度就越大。 閱讀全文 

二、OpenMP專題

1、OpenMP并行程序設計（一）

介紹OpenMP程序在并行計算時的效率，在雙核CPU上效率增加了整整一倍。 閱讀全文

2、OpenMP并行程序設計（二）

1、fork/join并行執行模式的概念 2、OpenMP指令和庫函數介紹 3、parallel 指令的用法 4、for指令的使用方法 5 sections和section指令的用法。閱讀全文

3、OpenMP中的數據處理子句

本文主要介紹了OpenMP中的private、firstprivate、lastprivate、threadprivate、reduction、copyin、copyprivate等數據處理子句的用法。 閱讀全文

4、OpenMP中的任務調度

本文主要介紹了OpenMP中任務調度子句schedule的使用方法。閱讀全文

5、OpenMP創建線程中的鎖及原子操作性能比較

主要比較了原子操作，Windows CriticalSection， OpenMP庫帶的鎖在單任務運行情況下和多任務運行情況下的性能情況，在多核CPU上，多任務的鎖競爭花費的時間是單任務時的鎖運行花費時間的18倍。鎖競爭帶來的效率下降完全出乎意料之外，由此也可見多核編程和單核多任務編程是有很大區別的。 閱讀全文

6、OpenMP程序設計的兩個小技巧

講述了如何動態設置線程數量以適應硬件和軟件的擴展性，如何將嵌套循環并行化的技巧。 閱讀全文

三、性能篇

1、雙核CPU上的快速排序效率

在雙核CPU上運行后，打印出花費的時間為 234 ms , 單任務版的快速排序函數約需406ms左右，并行運行效率為：406/（2×234） = 86.7% 左右。運行速度快了172ms。 閱讀全文

2、多核系統中三種典型鎖競爭的加速比分析

本文主要討論了固定式鎖競爭、隨機鎖競爭、分布式鎖競爭三種典型鎖競爭情況下的加速比,并分析了任務粒度因子和鎖粒度因子對加速比的影響。結論: 分布式鎖競爭加速比隨CPU核數成正比，可以達到和單核多任務時相當的性能，是多核編程的發展方向。 閱讀全文

3、無鎖編程與分布式編程那個更適合多核CPU？

本文重點比較了無鎖編程和分布式鎖競爭的性能，無鎖（原子操作）實際上是一種細粒度鎖。然后又從實現的功能，程序員掌握難易程度，現有軟件的移植等方面進行了比較，得出結論：無鎖編程遠不如分布式編程。分布式編程更適合多核CPU系統。 閱讀全文

四、多核編程模式專題

1、多核編程中的線程分組競爭模式

討論了使用任務分組鎖競爭方式來消除鎖競爭導致的CPU饑餓現象，隊列池就是任務分組競爭的一個非常好的實踐任務分組競爭模式相對于無鎖編程具有更好的優勢。 閱讀全文

2、多核編程中的線程隨機競爭模式的概率分析

本文主要分析了多個任務在隨機分布式鎖競爭的情況下，有不少于CPU核數個數的任務在運行的概率。然后將隨機競爭和無鎖編程的性能進行了理論上的比較。閱讀全文

3、多核編程中的條件同步模式

本文講解了一種減少鎖使用的方法，將每次都加鎖改為滿足一定條件時才加鎖，非常適合具有狀態機性質的場合使用。 閱讀全文

五、多核數據結構與算法專題

1、多核分布式隊列的實現：偷與自私的運用

本文講述了多核系統中分布式隊列的實現方法，所謂分布式隊列指的是每個線程除了可以訪問線程池外還自動擁有一個本地隊列。實現分布式隊列的基本方法就是“偷”與“自私”。 閱讀全文

2、多核查找-順序查找也瘋狂

用 數組進行查找，由于其插入和刪除需要按順序進行，需要移動較多的數據，對于大數據量的查找是無法使用的。然而，在多核時代，一切都改變了，大數據量的查找 結構也可以用數組來實現。并且用數組實現的大數據量查找結構有著比其他查找結構更明顯的優勢：效率高、內存占用少、并且容易避免偽共享問題。 閱讀全文

3、多核中的并行前綴和計算

前綴和計算在并行計算中很有用，因為在處理負載平衡問題時，經常需要將若干段數據重新平分，而計算前綴和通常是一種有效的將數據平分的方法。 閱讀全文

六、多核編程思想專題

1、多核新觀念－象使用內存一樣使用CPU？

象使用內存一樣使用CPU？ 閱讀全文

2、“老子”是偉大的多核計算科學家

本文主要論述道家的“小國寡民”，“無為”“大道自然”等思想與多核計算中使用的思想的異曲同工之處，給出了道家思想在多核計算中的實踐實例分析。大道自然，“貪心”，“自私”，“偷竊”這些大自然賦給人類的自然力量，在多核計算中得到了廣泛的使用。 閱讀全文

3、多核編程的四層境界

從先天方法策略、目標需求評價、本質根源保障、算法實現執行四個層面闡述多核計算的含義    閱讀全文

4、高房價與多核分布式計算

本文主要從多核計算的角度來論述高房價問題及其對社會的影響，并給出了高房價問題的最終解決措施。 閱讀全文

5、道家·老子的算法思想分析

將 道家老子的思想與軟件中的思想進行對比分析，得出結論，道家追求穩定可靠性。所以歷代在撥亂反正時期，用的都是道家思想。歷史上最典型的三個朝代漢、唐、 明為例，漢朝時張良等人都是好黃老之術（也就是道家思想），唐朝的宰相魏征也是道家人物，明朝的劉伯溫也是屬于道家人物。 閱讀全文

6、屈原·漁父的算法追求

屈原與漁父兩種不同的思想，相當于軟件中的兩種不同算法思想。“世人皆濁，眾人皆醉”可以理解為軟件運行的場景。  閱讀全文

更多的多核相關的資源，可以訪問：

1）Intel軟件社區多核論壇：http://forum.csdn.net/Intel/IntelMulti-core/

2）Intel的博客：http://softwareblogs-zho.intel.com/

關于多核相關的書籍介紹可以參考下面這篇文章：

“多核編程高處并不“寒””，文章地址： http://news.csdn.net/n/20081107/120632.html

這篇文章里有我對現在市面上有關多核編程和并行計算書籍的一個點評。可以給大家購買書籍作為一個參考。

多核相關的開源項目介紹:

1、Intel 開源項目TBB庫，鏈接：http://www.threadingbuildingblocks.org/

這是一個專門針對多核的開源項目，包含一些常見的多核數據結構與算法，如分段鎖的哈希表、分布式內存管理、動態任務調度器等，其中最重要的一個是動態任務調度器，可以使用動態任務調度器將串行算法自動變成并行算法，免去程序員學習并行算法之苦。

TBB開源項目的使用方法詳見O’Reilly出版的James Reinders的《Intel Threading Building Blocks》一書，如果要了解它的實現原理和方法，可以參考我寫的《多核計算與程序設計》一書。

2、Capi開源項目，鏈接：http://gforge.osdn.net.cn/projects/capi 

這個項目是我開發的一個針對多核的數據結構與算法庫，提供了許多實用的適應多核系統的數據結構與算法，主要的功能有以下一些：

1）各種并行算法，如并行歸并排序、并行基數排序等并行排序算法；并行順序搜索及終止檢測算法、并行Dijikstra最短路徑算法等并行搜索算法；并行前綴和、并行矩陣乘法等并行數值算法；等等。

2）分布式查找算法，如分段鎖的哈希表、動態分布式哈希數組、動態哈希AVL樹等。

3）搶奪式內存管理算法，即使在分配和釋放共享內存時，也幾乎不需要使用鎖。

4）基于偷取和自私的分布式隊列，用分布式隊列實現的兩種動態任務調度器、以及用動態嵌套任務調度器實現的Parallel_For()功能，用Parallel_For()實現的并行快速排序算法、并行歸并算法等。

5）任務圖調度器，可以用來實現對有依賴關系的執行塊的并行計算。

這個開源項目和TBB相比起來各有特色，TBB庫的優勢在于它是商業化的開源項目，代碼經過優化和相對完善的測試。CAPI的代碼專門為學習而設計，代碼沒有經過優化，代碼簡單易懂，易于學習，并且實現了比TBB庫更多的數據結構與算法容器，有一些創新的數據結構與算法在里面。其缺點是，現在發布的版本為0.2版本，如果進行商業使用需要自行增加測試用例進行更完善的測試和優化。

CAPI開源項目的實現原理和使用方法詳見我寫的《多核計算與程序設計》一書。

引言

服務（Service）的本質就是提供 服務消費者期望的某種功能，服務的價值體現在兩個方面：服務本身的質量和寄宿服務的平臺應付消費者的數量，并發（Concurrency）的關注的是第二 個要素。WCF服務寄宿于資源有限的環境中，要實現服務效用的最大化，需要考慮如何利用現有的資源實現最大的吞吐量（Throughput）。提高吞吐量 就某個寄宿的服務實例（Service Instance）來說，一個重要的途徑就是讓它能夠同時處理來自各個客戶端（服務代理）的并發訪問。WCF實現了一套完整的并發控制體系，為你提供了不 同的并發模式。

我經常說軟件架構是一門權衡的藝術，需要綜合考慮各種相互矛盾的因素，找到一種最優的組合方式。提高單個服務實例允許的 并發訪問量能夠提高整體吞吐量，這樣的理論依賴于一種假設，那就是服務端所能使用的資源是無限。我們知道，這種假設無論在什么情況下都不會成立。如果我們 并發量超出了服務端所能承受的臨界點，整個服務端將會崩潰。所以，WCF一方面需要允許讓單個服務實例并發處理接收到的多個請求，同時也需要設置一道閘門 控制并發的數量。WCF的流量限制（Throttling）體系為你創建了這道閘門。

從本篇文章開始，我將發布一系列的文章對WCF并發架構體系進行深入剖析 ，先來看看并發的基本介紹。

一、同一個服務實例上下文同時處理多個服務調用請求

并 發的含義就是多個并行的操作同時作用于一個相同的資源或者對象，或者說同一個資源或者對象同時應付多個并行的請求。對于WCF的并發來說，這里將的“資源 或者對象”指的就是承載服務操作最終執行的服務實例（Service Instance）。而WCF將服務實例封裝在一個稱為實例上下文（InstanceContext）對象中，所以WCF中的并發指的是同一個服務實例上下文同時處理多個服務調用請求。

WCF服務端框架一個主要的任務是將接收到的服務調用請求分發給激活的服務實例，調用相應的服務操作并返回執行結果。也就是說，服務操作的執行最終還是會落實到某個具體的服務實例上。《WCF技術剖析（卷1）》 的第9章對WCF的實例化機制進行了深入的剖析，從中我們知道在WCF服務端框架體系中，激活的服務實例并不是單獨存在的，而是被封裝在一個被稱為實例上 下文（InstanceContext）對象中。WCF提供了三種不同的實例上下模式（Per-Call、Per-Session和Single）實現了 不同的服務實例上下文提供機制。

所以，WCF并發框架體系解決的是如何有效地處理被分發到同一個服務實例上下文的多個服務調用請求，這些并行的調用請求可能來自不同的客戶端（服務代理），也可能相同的客戶端。WCF并發的本質上可以通過圖1體現。

圖1 通過一個InstanceContext對多個并發請求的處理

由于WCF的并發處理屬于服務本身自身的行為，所以我們通過服務行為（Service Behavior）的形式對采取的并發策略進行控制，而不同的并發策略定義在相應的并發模式（Concurrency Mode）下面。

二、通過ServiceBehaviorAttribute特性定義并發模式

WCF為三種典型的并發處理策略定義了三種典型的并發模式，即Single、Reentrant和Multiple。這三種并發模式通過ConcurrencyMode的三個同名的枚舉項表示，ConcurrencyMode定義如下：

   1: public enum ConcurrencyMode

   2: {

   3:     Single,

   4:     Reentrant,

   5:     Multiple

   6: }

通過ConcurrencyMode枚舉項表示的三種不同的并發模式體現了WCF處理并發請求的三種不同能策略：

• Single：一個封裝了服務實例的InstanceContext對象在某個時刻只能用于對某一個單一請求的處理，或者說針對某個InstanceContext對象的多個并發的請求會以一種串行的方式進行處理。具體來講，當WCF服務端框架接收到多個針對相同InstanceContext的請求時，會先確定該InstanceContext是 否可用（是否正在處理之前的服務調用請求），如何可用，則將接收到的第一個請求分發給它，其它請求則被放入根據抵達的先后順序被放入到一個隊列中。如果之 前的請求被正常處理，隊列中的第一個請求被分發給InsanceContext。如果一個請求在隊列中等待的時間過長，超過了設置好的服務調用的超時實 現，客戶端會跑出TimeoutException異常；
• Reentrant：該模式和Single一樣，InstanceContext對象在某個時刻只能用于對某一個單一請求的處理。不過有一點不同的是，如果服務操作在執行過程中涉及對外調用（Call Out），該InstanceContext可以用于其它服務調用請求的處理；
• Multiple：在該模式下，一個InstanceContext可以同時用于處理多個服務請求，所以Multiple并發模式下針對同一個InstanceContext的多個并發請求能夠得到及時的處理。不過，由于是并行的處理方式，服務操作執行過程中狀態的管理以及多線程的安全問題需要服務開發者自行處理。

并發模式的采用是服務單邊的選擇，是服務端個人的行為，所以并發模式以服務行為的方式定義，我們只需要在服務類型上應用 ServiceBehaviorAttribute特性，為ConcurrencyMode屬性設置相應的值即 可，ServiceBehaviorAttribute定義如下：

   1: [AttributeUsage(AttributeTargets.Class)]

   2: public sealed class ServiceBehaviorAttribute : Attribute, IServiceBehavior

   3: {

   4:     //其它成員

   5:     public ConcurrencyMode ConcurrencyMode { get; set; }

   6: }

如果顯示指定服務采用的并發模式，默認使用的是ConcurrencyMode.Single，所以下面兩種服務定義方式是等效的。

   1: public class CalculatorService : ICalculator

   2: {

   3:     //省略成員

   4: }

   5:  

   6: [ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]

   7: public class CalculatorService : ICalculator

   8: {

   9:     //省略成員

  10: }

三、回調（Callback）中的并發

WCF并發解決的是同一個InstanceContext對象在處理并發請求是采用怎樣的處理策略。我們知道InstanceContext不僅僅是封裝真正服務實例的容器，當我們通過雙向通信的機制從服務端回調客戶端操作時，真正執行回調操作的回調對象也是封裝在InstanceContext中。

在雙向通信的場景中，如果多個服務端或者同一個客戶端的多個并發的服務調用操作所指定的回調實例上下文（即封裝回調操作的InstanceContext對象），就可能出現針對同一個InstanceContext的并發回調的現象。WCF采用與正常服務調用相同的機制來處理并發回調，實際上WCF采用幾乎一樣的機制來實現正常的服務調用和回調。

與通過將ServiceBehaviorAttribute特性應用到服務類型并指定采用的并發模式相類似，回調采用的并發模式通過應用在回調類型上的CallbackBehaviorAttribute特性來指定。CallbackBehaviorAttribute中同樣定義了ConcurrencyMode屬性：

   1: [AttributeUsage(AttributeTargets.Class)]

   2: public sealed class CallbackBehaviorAttribute : Attribute, IServiceBehavior

   3: {

   4:     //其它成員

   5:     public ConcurrencyMode ConcurrencyMode { get; set; }

   6: }

下面的代用中，我們通過在回調類型CalculatorCallbackService上應用CallbackBehaviorAttribute特性，將回調并發模式設置成ConcurrencyMode.Multiple。

   1: [CallbackBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]

   2: public class CalculatorCallbackService:ICalculatorCallback

   3: {

   4:     //省略成員

   5: }

四、 事務行為與并發

相信你還會記得在上面一章介紹事務編程（《上篇》、《中篇》、《下篇》）的時候，可以在服務類型上面應用ServiceBehaviorAttribute特性將ReleaseServiceInstanceOnTransactionComplete屬性設成True，這樣可以讓WCF在事務結束之后將封裝了服務實例的InstanceContext對象釋放掉。不過這樣的設置之后再并發模式為ConcurrencyMode.Single的前提下方才有效，否則在進行服務寄宿的時候將會拋出異常。

比如說，我們定了如下一個BankingService服務類型，通過ServiceBehaviorAttribute特性指定 ReleaseServiceInstanceOnTransactionComplete為True，并采用 ConcurrencyMode.Multiple并發模式。

   1: [ServiceBehavior(ReleaseServiceInstanceOnTransactionComplete = true,ConcurrencyMode = ConcurrencyMode.Multiple)]

   2: public class BankingService : IBankingService

   3: {

   4:     [OperationBehavior(TransactionScopeRequired = true)]

   5:     public void Transfer(string accountFrom, string accountTo, decimal amount)

   6:     {

   7:        //省略實現

   8:     }

   9: }

當我們試圖寄宿該BankingService服務的時候，如圖2所示的 InvalidOperationException異常會被拋出，并提示對于已經將 ReleaseServiceInstanceOnTransactionComplete設置成True的服務來說，必須將并發模式設成 ConcurrencyMode.Multiple。

圖2 在Multiple+ReleaseServiceInstanceOnTransactionComplete導致的異常 

WCF提供的三種不同的并發模式，使開發者可以根據具體的情況選擇不同的并發處理的策略。對于這三種并發模式，Multiple采用的并行的執行方 式，而Single和Reentrant則是采用串行的執行方式。串行執行即同步執行，在WCF并發框架體系中，這樣的同步機制是如何實現的呢？請關注下篇文章。