併發編程中的重重量級模型和輕量級模型

併發編程中的重重量級模型和輕量級模型

使用輕量級併發開發

        不論是Amdahl定律仍是Gustafson的定律都沒有考慮引入併發須要付出的額外開銷。同時也沒有考慮那些能夠將順序代碼轉變成能夠利用並行優點的算法的設計模式。重要的是減小程序中必須執行的順序代碼，改善對並行執行單元的利用。

        之前的.NET 版本，若是你想在一個進程內並行執行C#應用程序，你必須建立和管理多線程（軟件線程）。因此，你必須編寫複雜的多線程代碼。分解算法到多個線程上，協調不一樣的代碼單元，在它們之間共享信息，而且收集執行結果確確實實是一件複雜的編程工做。隨着邏輯核心的增多，狀況變得甚至更糟了，由於你須要更多的線程來獲取更好的可伸縮性。

        多線程模型的設計並非爲了幫助開發人員應對多核革命的。事實上，建立一個新的線程須要不少不少的處理器資源，而且把每個算法分解到並行的線程上會引入不少的開銷。大多有用的結構和類的設計並不能被不一樣的線程同時訪問，因此必須添加不少的代碼處理這種狀況。這些額外的代碼是開發人員難以專一主要目的：利用並行執行改善程序性能。

        由於這種多線程模型處理多核併發太複雜了，因此這就是衆所周知的重量級併發模型。這引入了額外的負擔。因爲在框架級別缺少對多線程互訪的支持，爲了解決這個問題須要添加太多的代碼，這使代碼異常的難理解。

        前面提到的與先前.NET提供的多線程模型有關的問題和現代微處理器不斷增長的邏輯核心的數目，促使建立新的模型編寫併發代碼。新的模型就是衆所周知的輕量級併發模型，由於它減小了在不一樣的邏輯核心上建立和執行代碼的代價。可是這並不意味着它消除了引入併發致使的全部代價，可是這個模型是爲如今多核微處理器的開發設計的。重量型併發模型是在多處理器時代產生的，當時一個電腦能夠有不少個只有一個物理核心的微處理器。輕量級併發模型考慮了某些物理核心支持不少邏輯核心的架構。

        輕量級併發模型並不只僅是調度不一樣物理核心的負載。它同時增長了對框架級別多線程互訪問的的支持，同時使代碼更加簡單易於理解。

        幾乎全部的現代編程語言都將要轉向支持輕量型的併發模型。幸運的.Net 4就是其中的一員。因此，全部能夠生成.NET應用程序的託管語言均可以利用這種新的模型。

建立良好的基於任務模型的設計

        有的時候，你必須優化一個已存的解決方案以便充分利用並行的特性。在這種狀況下，有必須理解已經存在的串行設計，理解採用的並行算法是否會下降伸縮性，不然你必須進行重構以在不引入問題或者產生不一樣結果狀況下獲取性能的提高。你能夠將問題的一部分或者整個問題建立基於任務模型的設計，而後你就能夠引入並行了。當你設計新的解決方案的時候，也能夠應用相同的技術。

        依據如下步驟你能夠建立有效的基於任務模型的設計：

1.      將每一個問題分解成不少的小問題，而且忘記有關串行執行的東西。

2.      向下面同樣考慮與每一個子問題有關的東西：

能夠併發處理的數據，就將數據進行分解實現併發。

須要不少任務和一些複雜並行處理的數據，就分解這些數據和任務來實現併發。

能夠並行執行的任務，就分解這些任務來實現併發。

3.      組織你的設計展示併發意圖。

4.      肯定串聯不一樣子問題須要的任務。儘可能的避免產生依賴。

5.      時刻謹記以併發和潛在的並行思想進行設計。

6.      分析並行問題的執行計劃須要考慮如今的多核微處理器和未來的架構。爲獲取更好的伸縮性進行設計。

7.      儘量的最小化危險的部分。

8.      不管什麼時候，儘量的使用基於任務模型實現併發編程。

9.      協調步調，不斷迭代重複這些步驟。

前面提到的步驟並不意味着全部的子問題均可以成爲運行在不一樣的線程上的並行任務。

當編寫代碼的時候，根據性能和伸縮性的目標，設計須要考慮並行的可能性，並選擇最好設計。並行的思想、將工做分解成不一樣的任務來完成是很重要的。以這種方式，你就能夠根據須要將你的代碼並行化。若是你有一個經典的串行執行的設計，經過使用基於任務模型的編程技術使其並行化須要付出很大努力。