Fixes #198
This commit is contained in:
chai2010
2016-01-18 11:22:04 +08:00
parent 884ada9cd0
commit 9666211cd7
71 changed files with 107 additions and 105 deletions

View File

@@ -54,7 +54,7 @@ func Balance() int {
上面的bank程序例證了一種通用的併發模式。一繫列的導出函數封裝了一個或多個變量那麽訪問這些變量唯一的方式就是通過這些函數來做(或者方法,對於一個對象的變量來説)。每一個函數在一開始就獲取互斥鎖併在最後釋放鎖從而保證共享變量不會被併發訪問。這種函數、互斥鎖和變量的編排叫作監控monitor(這種老式單詞的monitor是受"monitor goroutine"的術語啟發而來的。兩種用法都是一個代理人保證變量被順序訪問)。
由於在存款和査詢餘額函數中的臨界區代碼這麽短--隻有一行,沒有分支調用--在代碼最後去調用Unlock就顯得更爲直截了當。在更複雜的臨界區的應用中尤其是必要盡早處理錯誤併返迴的情況下,就很難去(靠人)判斷對Lock和Unlock的調用是在所有路徑中都能夠嚴格配對的了。Go語言里的defer簡直就是這種情況下的救星我們用defer來調用Unlock臨界區會隱式地延伸到函數作用域的最後這樣我們就從“總要記得在函數返迴之後或者發生錯誤返迴時要記得調用一次Unlock”這種狀態中獲得了解放。Go會自動幫我們完成這些事情。
由於在存款和査詢餘額函數中的臨界區代碼這麽短--隻有一行,沒有分支調用--在代碼最後去調用Unlock就顯得更爲直截了當。在更複雜的臨界區的應用中尤其是必要盡早處理錯誤併返迴的情況下,就很難去(靠人)判斷對Lock和Unlock的調用是在所有路徑中都能夠嚴格配對的了。Go語言里的defer簡直就是這種情況下的救星我們用defer來調用Unlock臨界區會隱式地延伸到函數作用域的最後這樣我們就從“總要記得在函數返迴之後或者發生錯誤返迴時要記得調用一次Unlock”這種狀態中獲得了解放。Go會自動幫我們完成這些事情。
```go
func Balance() int {
@@ -102,7 +102,7 @@ func Withdraw(amount int) bool {
上面這個例子中Deposit會調用mu.Lock()第二次去獲取互斥鎖但因爲mutex已經鎖上了而無法被重入(譯註go里沒有重入鎖關於重入鎖的概念請參考java)--也就是説沒法對一個已經鎖上的mutex來再次上鎖--這會導致程序死鎖沒法繼續執行下去Withdraw會永遠阻塞下去。
關於Go的互斥量不能重入這一點我們有很充分的理由。互斥量的目的是爲了確保共享變量在程序執行時的關鍵點上能夠保證不變性。不變性的其中之一是“沒有goroutine訪問共享變量”。但實際上對於mutex保護的變量來説不變性還包括其它方面。當一個goroutine獲得了一個互斥鎖時它會斷定這種不變性能夠被保持。其獲取併保持鎖期間可能會去更新共享變量這樣不變性隻是短暫地被破壞。然而當其釋放鎖之後它必保證不變性已經恢複原樣。盡管一個可以重入的mutex也可以保證沒有其它的goroutine在訪問共享變量但這種方式沒法保證這些變量額外的不變性。(譯註:這段翻譯有點暈)
關於Go的互斥量不能重入這一點我們有很充分的理由。互斥量的目的是爲了確保共享變量在程序執行時的關鍵點上能夠保證不變性。不變性的其中之一是“沒有goroutine訪問共享變量”。但實際上對於mutex保護的變量來説不變性還包括其它方面。當一個goroutine獲得了一個互斥鎖時它會斷定這種不變性能夠被保持。其獲取併保持鎖期間可能會去更新共享變量這樣不變性隻是短暫地被破壞。然而當其釋放鎖之後它必保證不變性已經恢複原樣。盡管一個可以重入的mutex也可以保證沒有其它的goroutine在訪問共享變量但這種方式沒法保證這些變量額外的不變性。(譯註:這段翻譯有點暈)
一個通用的解決方案是將一個函數分離爲多個函數比如我們把Deposit分離成兩個一個不導出的函數deposit這個函數假設鎖總是會被保持併去做實際的操作另一個是導出的函數Deposit這個函數會調用deposit但在調用前會先去獲取鎖。同理我們可以將Withdraw也表示成這種形式