242
多核時代：並行程序設計探討（7）——並行編程模式概覽
並行編程模式概覽
前麵的5、6篇博文，都是和並行編程相關的基礎知識，如果你一路看來，基本上也能夠開始進行並行編程設計了，也可以和別人吹吹牛、聊聊天了。
但“欲窮千裏目，更上一層樓”，前麵的畢竟都是基礎知識，拿來直接設計，雖然能夠完成任務，但就像在茫茫大海中航行，沒有燈塔，難免會走很多彎路、甚至絕路！
所以我們要在這些基礎知識之上，學習一套係統的分析問題、設計方案、應用實現的理論來指導我們作出正確的、優秀的分析、設計，以及實現。並行編程模式就是這樣一座指導我們進行並行編程設計和實現的燈塔。
當然，這個並行編程模式也是一個完整的體係，不是簡單的幾個模式堆雜在一起，所以我們要開始就把握住這個並行編程模式的體係的框架，高屋建瓴的從整體上對這套體係有一個清晰的了解，然後再開始深入的掌握每個部分。
首先，我們從整體上看一下並行編程模式的體係結構，如下圖：
從圖中可以看出，總共分為4大部分：Finding concurrency、Algorithm structure、Support Structure、Implementation Mechanisms。從英文本意來看比較難以理解，我仔細看了每章的介紹，按照如下方式翻譯：並行性分析、算法結構、程序結構、實現結構。這幾個部分實際上是按照設計的先後順序進行分類的：首先要分析問題、然後再選擇什麼算法，再看程序如何設計，最後看具體實現。下麵我們就逐一簡單介紹這幾部分。
1.1 並行性分析
顧名思義，這部分模式是用來分析並行性的，按照英文的字麵意思就是“找到並行性”。
如下圖，並行性分析又分為三大類：分解、依賴分析、設計評估，共6個模式。
1.2 算法結構
經過並行性分析後，並行相關的任務、數據、依賴都已經基本分析完畢了（之所以說是基本，是因為分析和設計是一個迭代的過程，不是標準的流水線作業），這時就要看看如何將這些任務、數據組織起來來解決實際的問題。也就是說並行性分析是一個“分”的過程，而算法結構是一個“合”的過程。
如下圖：算法結構模式部分分為三類：按任務組織、按數據分解組織、按數據流組織，共6個模式。
但細心的朋友可能就會問：在並行性分析之前就是一個已經“合”好的問題了，為什麼這裏還要再次合起來呢？
關鍵就在於：算法結構的“合”是針對已經分解好的任務、數據和依賴，而並行性分析前的“合”隻是一個問題的初始混沌狀態（有的書中叫做problem mud）。算法結構中的“合”動作是看並行性分析後的結果合起來是否能夠解決並行性分析前“合”的問題，其實道理很簡單：分解得再好，合起來不能解決分之前的問題，那也是錯誤的。
1.3 程序結構
按照英文原意翻譯，這部分叫做“支撐結構”，很難理解，我仔細看了這類模式包含的幾個子模式，發現其實都是關於進程/線程結構、數據結構的，而這些都是具體程序設計的時候需要考慮的，因此我覺得翻譯成“程序結構”更加容易理解。
從下圖可以看出，這類模式分為兩類：Program Structure，這是關於如何組織進程或者線程的；Data structure，這是關於如何組織數據的。
上一章的算法結構中也有“按照數據組織”，這一章也有“數據結構”，兩者是什麼區別或者關係呢？
區別就在於兩個“數據”的地位不一樣：算法結構中是按照數據來對任務進行“合”操作，不考慮對數據本身的管理（例如數據操作、數據互斥、數據同步），而程序結構中是考慮數據本身的管理，即如何保證數據滿足多個任務的並行運行。
1.4 實現結構
實現結構作為並行編程模式有點“掛羊頭賣狗肉”的意思，因為實際上這裏麵的內容都是和具體的語言或者平台相關的，作者在這部分主要講了Java、OpenMP、MPI三種語言的實現方法，並不是什麼模式（模式應該是語言無關的吧）。
認真的朋友看到“UE Management”、“Synchronization”、“Communications”可能有似曾相識的感覺，因為我在前麵5、6篇博文裏麵重點就是講解了Windows和Linux的多進程/多線程實現機製、進程間同步、進程間通信，這不正好對應這裏所謂的“UE Management”、“Synchronization”、“Communications”麼？：）
最後更新：2017-04-02 04:00:23