ch8-04-2 done

ch8/ch8-04-1.md

@@ -1,10 +1,10 @@
 ### 8.4.1. 不帶緩存的Channels
 
-一個基於無緩存Channels的發送操作將導致發送者goroutine阻塞，直到另一個goroutine在相同的Channels上執行接收操作，當發送的值通過Channels成功傳輸之後，兩個goroutine可以繼續執行後面的語句。反之，如果接收操作先發送，那麽接收者goroutine也將阻塞，直到有另一個goroutine在相同的Channels上執行發送操作。
+一個基於無緩存Channels的發送操作將導致發送者goroutine阻塞，直到另一個goroutine在相同的Channels上執行接收操作，當發送的值通過Channels成功傳輸之後，兩個goroutine可以繼續執行後面的語句。反之，如果接收操作先發生，那麽接收者goroutine也將阻塞，直到有另一個goroutine在相同的Channels上執行發送操作。
 
 基於無緩存Channels的發送和接收操作將導致兩個goroutine做一次同步操作。因爲這個原因，無緩存Channels有時候也被稱爲同步Channels。當通過一個無緩存Channels發送數據時，接收者收到數據發生在喚醒發送者goroutine之前（譯註：*happens before*，這是Go語言併發內存模型的一個關鍵術語！）。
 
-在討論併發編程時，當我們説x事件在y事件之前發生（*happens before*），我們併不是説x事件在時間上比y時間更早；我們要表達的意思是要保證在此之前事件都已經完成了，例如在此之前的更新某些變量的操作已經完成，你可以放心依賴這些保證了。
+在討論併發編程時，當我們説x事件在y事件之前發生（*happens before*），我們併不是説x事件在時間上比y時間更早；我們要表達的意思是要保證在此之前的事件都已經完成了，例如在此之前的更新某些變量的操作已經完成，你可以放心依賴這些已完成的事件了。
 
 當我們説x事件旣不是在y事件之前發生也不是在y事件之後發生，我們就説x事件和y事件是併發的。這併不是意味着x事件和y事件就一定是同時發生的，我們隻是不能確定這兩個事件發生的先後順序。在下一章中我們將看到，當兩個goroutine併發訪問了相同的變量時，我們有必要保證某些事件的執行順序，以避免出現某些併發問題。
 
@@ -35,5 +35,5 @@ func main() {
 
 基於channels發送消息有兩個重要方面。首先每個消息都有一個值，但是有時候通訊的事實和發生的時刻也同樣重要。當我們更希望強調通訊發生的時刻時，我們將它稱爲**消息事件**。有些消息事件併不攜帶額外的信息，它僅僅是用作兩個goroutine之間的同步，這時候我們可以用`struct{}`空結構體作爲channels元素的類型，雖然也可以使用bool或int類型實現同樣的功能，`done <- 1`語句也比`done <- struct{}{}`更短。
 
-**練習 8.3：** 在netcat3例子中，conn雖然是一個interface類型的值，但是其底層眞實類型是`*net.TCPConn`，代表一個TCP鏈接。一個TCP鏈接有讀和寫兩個部分，可以使用CloseRead和CloseWrite方法分别關閉它們。脩改netcat3的主goroutine代碼，隻關閉網絡鏈接中寫的部分，這樣的話後台goroutine可以在標準輸入被關閉後繼續打印從reverb1服務器傳迴的數據。（要在reverb2服務器也完成同樣的功能是比較睏難的；參考**練習 8.4：**）
+**練習 8.3：** 在netcat3例子中，conn雖然是一個interface類型的值，但是其底層眞實類型是`*net.TCPConn`，代表一個TCP鏈接。一個TCP鏈接有讀和寫兩個部分，可以使用CloseRead和CloseWrite方法分别關閉它們。脩改netcat3的主goroutine代碼，隻關閉網絡鏈接中寫的部分，這樣的話後台goroutine可以在標準輸入被關閉後繼續打印從reverb1服務器傳迴的數據。（要在reverb2服務器也完成同樣的功能是比較睏難的；參考**練習 8.4**。）