.Net並行編程系列之一：並行基礎

如今普通PC平臺上面多核處理器的普及，讓咱們領教了可以利用多核進行並行計算的軟件的處理能力，同時繼承更多地核心正是當前處理器發展的趨勢。

可是做爲一個.NET開發人員，是否有時候會發現你的程序佔用了其中一個核心的大部分運行時間，甚至達到了100%，除了繼續優化處理問題的算法。

那麼還有方法可以利用CPU的其它核心爲你的應用程序所用麼？答案是顯然能夠的。

你所要作的，就是把應用程序的任務分割成塊，使各塊在同一時間運行。

.Net 4.0引入了一種新的編程模型，結合VS2010使得開發並行應用程序變得更加容易。.Net4.0提供了任務並行庫（TPL）與並行語言查詢集合（PLINQ）。VS2010提供了調試並行程序的工具和分析工具。

 把現行的程序任務改編成能夠並行運行的任務須要如下幾個步驟：

1.分解：瞭解任務，選擇合適的粒度把任務拆分紅離散的單元方法（函數）

2.協調：選擇協調這些並行任務的方法（數據流或者控制流）

3.可擴展共享：任務間共享數據的設計（例如經過阻塞併發線程實現數據同步，鎖，比較並交換，信號燈等），記住，無論是什麼同步設計都必然產生順序的形式，都會對性能效率產生負面影響。

併發與並行的區別：

併發的目的是防止線程飢餓，強調的是每一個線程都能有本身的時間片來運行，減小相應的時延。

並行解決的問題是關於吞吐量的，是一種優化手段，目的是爲了充分利用多核處理器。

既然並行能夠利用多核處理器的威力，那麼當內核數目增長時，咱們的應用程序加速是否能夠隨着利用的內核數目增長而成線性增加呢？

答案是否認的，除非須要處理的任務沒有順序執行部分。

例如： 假設一個任務分爲兩部分：不能被並行化的部分a，能夠並行化的部分b。

當任務在單核處理器上面順序執行時，分別須要的時間爲 Ta，Tb，記Ta+Tb=S

若是把任務放到n核心處理器上面運行，則理論的運行時間應該是〉=Ta+（Tb/n）

則獲得加速比 r〈=[S/（Ta+Tb/n）]=[S/（Ta+（S-Ta）/n）]=1/[Ta/S+（1-Ta/S）/n]

當n無限增大時 r的極限爲r〈=S/Ta

因此加速比的極限爲S/Ta。

此定律爲阿姆達爾定律，它爲咱們的並行計算指明瞭能夠改進的方向，儘可能減小順序部分佔全部時間的比例。而且若是任務的順序部分比例很大的時候，即便把可並行部分轉換爲並行執行，也是意義不大的。 

完畢。

做者：Andy Zeng

歡迎任何形式的轉載，但請務必註明出處。

http://www.cnblogs.com/andyzeng/p/3704333.html