續上篇，Day7 - 讀 Concurrency is not Parallelism - Rob Pike (二)，繼續昨天的 gopher 燒書：

想出了一種 gopher 燒書的方式之後。當我們暸解到可以將一個問題拆解成幾個相依的 process，我們當然能想出另一種解決燒書問題的方式：一個 gopher 把書放到推車上，一個 gopher 將推車推到焚化爐並且把空的推車推回，一個 gohper 負責燒書。

這樣的設計會變快，但可能不會快多少，如果中間那隻 gopher 的路途很長時，其他兩隻 gopher 可能沒事做 (左邊的 gopher 已經把書疊完，右邊的 gopher 已經把書燒完)，那就多來一支 gopher 將空的車運回來。這其實就是另一種 concurrent 設計，而且我們將 gopher 燒書這件事，拆解的更細了。可以想像若這四隻 gopher 燒書如果設計的良好，可能會比本來一支 gopher 燒書還要快四倍。

藉由這次的觀察，得到一個結論，藉由加了一個 gopher 之後，燒書這件事情效率就上升了。當然加了一個 gopher 做事情效率上升，這事情很直覺，但是把加 gopher 這件事情想成多加了一個設計，效率就上升了，這件事是蠻神奇的。這種拆解問題的方式 (也就是 concurrent design) 不單單只是 parallel 這麼簡單而已。

這四隻 gopher，一隻把書放進推車，一隻燒書，一隻將書卸載，一隻將推車返回。你可以把這想成四個不相依的 process，並且各自運作良好，將它們組合後就能解決燒書的問題。

當然剛剛的解法也不是唯一的，重點是，當我們將問題拆解 (concurrent decompostion) 之後，就可以在不同的維度上平行化。

這時候 Rob Pike 說了一句：也許這也可以不是一個 parallel 的狀態啊，這些 gopher 不一定要同時忙碌。
在同一個時間，可能只有一個 gopher 在忙碌，其他七個閒置，但真正的重點是：儘管只有一隻 gopher 工作，這個設計仍然是正確的且運作良好。這代表我們不需要擔心 parallelism ，當我們做出了一個良好的 concurernt 設計，parallel 其實就是一個挑選幾隻 gopher 在忙碌 free variable 的參數而已。

接下來，再來看看一個新的設計吧，一隻 gopher 將書堆運到中間，另一隻則從中間的書堆運到焚化爐。

來一點平行化吧，直接複製一組兩隻 gopher 燒書的方式：

還記得，我們剛剛將燒書拆成四個 gopher 去做嗎 (堆書，推車，返回空車，燒書)，我們將同樣的概念在用在這裡：

當然，我們也能直接複製一組，變成 16 隻 gopher 來運作：

從這幾個設計的演化可以學到，

1. 拆解問題的方法很多種 (也就是 concurrent 的設計有很多種)。
2. 剛剛的設計過程，就是 concurrent desing 的過程了。
3. 當我們把問題拆解之後，parallel 就自然會出現拉，而且運作是良好且正確的
   

最後我們把這些事情做個替換，書堆換成網頁內容，gohper 換成 cpu，推車換成渲染、marshaling 或是網路，焚化爐換成瀏覽器或是代理伺服器等等，這其實就是一個可擴展的 web 服務的 concurrent 設計

明日繼續讀