並行的代價

並行的代價

天下沒有免費的午餐，對於並行來說也是一樣。

可能我們看到並行的代價第一反應就是複雜度以及額外的工作量。總體上來講，並行的複雜度一般來說都會高於序列。開發一款軟體，一個開發團隊的開發能力總是會高於團隊中一個單獨程式設計師的（假設他們水平都差不多）。然而一個由10人組成的團隊開發能力能達到單獨程式設計師的10倍麼？顯然不可能。因為相對於一個獨立開發的程式設計師來說，團隊開發時我們需要合理拆分開發任務，需要管理團隊中程式設計師的工作內容和進度，需要協調不同程式設計師開發的模組之間的對接...於是專案管理、軟體工程、系統架構成了一個一個獨立的課題，每個課題對於現代軟體開發來說都是重點，也是難點。

類比到計算機程式的並行，雖然並行能給我們帶來很多好處，但引入並行就意味著程式的複雜度上升，並且帶來很多其他的難點：程式/執行緒之間的通訊、資源競爭、程式/執行緒的管理維護、異常處理等等（和軟體團隊的管理很像吧，這也是我一直把平行計算問題當做程式設計問題中的管理問題來看的緣由）。然而相比於這些問題來說，更大的難點在於：如何設計一個併發程式？

在前文已經有所提及，從某個層面來看，只有併發程式才是可並行的。所以對於原本我們用序列方法解決的問題來說，想並行化來提高效率，首先要做的工作是將大問題分解成一個個能夠獨立解決的小問題。既然分解得到的小問題是互相獨立的，那麼它們就能轉變成一個併發問題，從而並行執行。但對於大多數問題來說，這樣的分解過程相當困難。

當然也不用被嚇到，在軟體這個充滿分享精神的行業裡，總有很多“模式”可以套用。《七週七併發模型》一書就歸納總結了一些常用的併發模型，從技術實現和設計角度上都具有很大的參考價值。

在本節的最後，不得不提醒一句：軟體行業沒有銀彈，並行不是萬能良藥。技術的選擇在於根據實際環境所進行的衡量和取捨，這也正是工程學的魅力所在。如果瞭解過計算機的底層介面演變，並口到串列埠的演變作為例子在這裡提出來非常合適：依照正常的思維，並行傳輸資料總是會比序列傳輸來得更快，但為什麼並口會被串列埠替換掉？為什麼SAS(Serial Attached SCSI，穿行連線SAS介面)和SATA(穿行ATA)硬碟會大規模替換早期的PATA（並行ATA）硬碟？這些都是值得思考的問題。