前面的5、6篇博文，都是和并行程式設計相關的基礎知識，如果你一路看來，基本上也能夠開始進行并行程式設計設計了，也可以和别人吹吹牛、聊聊天了。
但“欲窮千裡目，更上一層樓”，前面的畢竟都是基礎知識，拿來直接設計，雖然能夠完成任務，但就像在茫茫大海中航行，沒有燈塔，難免會走很多彎路、甚至絕路！
是以我們要在這些基礎知識之上，學習一套系統的分析問題、設計方案、應用實作的理論來指導我們作出正确的、優秀的分析、設計，以及實作。并行程式設計模式就是這樣一座指導我們進行并行程式設計設計和實作的燈塔。
當然，這個并行程式設計模式也是一個完整的體系，不是簡單的幾個模式堆雜在一起，是以我們要開始就把握住這個并行程式設計模式的體系的架構，高屋建瓴的從整體上對這套體系有一個清晰的了解，然後再開始深入的掌握每個部分。
首先，我們從整體上看一下并行程式設計模式的體系結構，如下圖：
從圖中可以看出，總共分為4大部分：finding concurrency、algorithm structure、support structure、implementation mechanisms。從英文本意來看比較難以了解，我仔細看了每章的介紹，按照如下方式翻譯：并行性分析、算法結構、程式結構、實作結構。這幾個部分實際上是按照設計的先後順序進行分類的：首先要分析問題、然後再選擇什麼算法，再看程式如何設計，最後看具體實作。下面我們就逐一簡單介紹這幾部分。
顧名思義，這部分模式是用來分析并行性的，按照英文的字面意思就是“找到并行性”。
如下圖，并行性分析又分為三大類：分解、依賴分析、設計評估，共6個模式。
經過并行性分析後，并行相關的任務、資料、依賴都已經基本分析完畢了（之是以說是基本，是因為分析和設計是一個疊代的過程，不是标準的流水線作業），這時就要看看如何将這些任務、資料組織起來來解決實際的問題。也就是說并行性分析是一個“分”的過程，而算法結構是一個“合”的過程。
如下圖：算法結構模式部分分為三類：按任務組織、按資料分解組織、按資料流組織，共6個模式。
但細心的朋友可能就會問：在并行性分析之前就是一個已經“合”好的問題了，為什麼這裡還要再次合起來呢？
關鍵就在于：算法結構的“合”是針對已經分解好的任務、資料和依賴，而并行性分析前的“合”隻是一個問題的初始混沌狀态（有的書中叫做problem mud）。算法結構中的“合”動作是看并行性分析後的結果合起來是否能夠解決并行性分析前“合”的問題，其實道理很簡單：分解得再好，合起來不能解決分之前的問題，那也是錯誤的。
按照英文原意翻譯，這部分叫做“支撐結構”，很難了解，我仔細看了這類模式包含的幾個子模式，發現其實都是關于程序/線程結構、資料結構的，而這些都是具體程式設計的時候需要考慮的，是以我覺得翻譯成“程式結構”更加容易了解。
從下圖可以看出，這類模式分為兩類：program structure，這是關于如何組織程序或者線程的；data structure，這是關于如何組織資料的。
上一章的算法結構中也有“按照資料組織”，這一章也有“資料結構”，兩者是什麼差別或者關系呢？
差別就在于兩個“資料”的地位不一樣：算法結構中是按照資料來對任務進行“合”操作，不考慮對資料本身的管理（例如資料操作、資料互斥、資料同步），而程式結構中是考慮資料本身的管理，即如何保證資料滿足多個任務的并行運作。
實作結構作為并行程式設計模式有點“挂羊頭賣狗肉”的意思，因為實際上這裡面的内容都是和具體的語言或者平台相關的，作者在這部分主要講了java、openmp、mpi三種語言的實作方法，并不是什麼模式（模式應該是語言無關的吧）。
認真的朋友看到“ue management”、“synchronization”、“communications”可能有似曾相識的感覺，因為我在前面5、6篇博文裡面重點就是講解了windows和linux的多程序/多線程實作機制、程序間同步、程序間通信，這不正好對應這裡所謂的“ue management”、“synchronization”、“communications”麼？：）