歡迎光臨
每天分享高質量文章

最大限度地降低多執行緒 C# 代碼的複雜性

分支或多執行緒編程是編程時最難最對的事情之一。這是由於它們的並行性質所致,即要求採用與使用單執行緒的線性編程完全不同的思維樣式。對於這個問題,恰當類比就是拋接雜耍表演者,必須在空中拋接多個球,而不要讓它們相互干擾。這是一項重大挑戰。然而,通過正確的工具和思維樣式,這項挑戰是能應對的。

本文將深入介紹我為了簡化多執行緒編程和避免爭用條件、死鎖等其他問題而編寫的一些工具。可以說,工具鏈以語法糖和神奇委托為依據。不過,取用偉大的爵士音樂家 Miles Davis 的話:“在音樂中,沒有聲音比有聲音更重要。” 聲音間斷就產生了奇跡。

從另一個角度來說,不一定是關乎可以編碼什麼,而是關乎可以選擇不編碼什麼,因為你希望通過間斷代碼行產生一點奇跡。取用 Bill Gates 的一句話:“根據代碼行數來衡量工作質量就像通過重量來衡量飛機質量一樣。” 因此,我希望能幫助開發人員減少編碼量,而不是教導開發人員如何編寫更多代碼。

同步挑戰

在多執行緒編程方面遇到的第一個問題是,同步對共享資源的訪問權限。當兩個或多個執行緒共享對某個物件的訪問權限且可能同時嘗試修改此物件時,就會出現這個問題。當 C# 首次發佈時,lock 陳述句實現了一種基本方法,可確保只有一個執行緒能訪問指定資源(如資料檔案),且效果很好。C# 中的 lock 關鍵字很容易理解,它獨自顛覆了我們對這個問題的思考方式。

不過,簡單的 lock 存在一個主要缺陷:它不區分只讀訪問權限和寫入訪問權限。例如,可能要從共享物件中讀取 10 個不同的執行緒,並且通過 System.Threading 命名空間中的 ReaderWriterLockSlim 類授權這些執行緒同時訪問實體,而不導致問題發生。與 lock 陳述句不同,此類可便於指定代碼是將內容寫入物件,還是只從物件讀取內容。這樣一來,多個讀取器可以同時進入,但在其他所有讀寫執行緒均已完成自己的工作前,拒絕任何寫入代碼訪問。

現在的問題是:如果使用 ReaderWriterLock 類,語法就會變得很麻煩,大量的重覆代碼既降低了可讀性,又隨時間變化增加了維護複雜性,並且代碼中通常會分散有多個 try 和 finally 塊。即使是簡單的拼寫錯誤,也可能會帶來日後有時極難發現的災難性影響。

通過將 ReaderWriterLockSlim 封裝到簡單的類中,這個問題瞬間解決,不僅重覆代碼不再會出現,而且還降低了小拼寫錯誤毀一天勞動成果的風險。圖 1 中的類完全基於 lambda 技巧。可以說,這就是對一些委托應用的語法糖(假設存在幾個接口)。最重要的是,它在很大程度上有助於實現避免重覆代碼原則 (DRY)。

圖 1:封裝 ReaderWriterLockSlim

 1 public class Synchronizer where TImpl : TIWrite, TIRead {
 2     ReaderWriterLockSlim _lock = new ReaderWriterLockSlim ();
 3     TImpl _shared;
 4 
 5     public Synchronizer (TImpl shared) {
 6         _shared = shared;
 7     }
 8 
 9     public void Read (Action functor) {
10         _lock.EnterReadLock ();
11         try {
12             functor (_shared);
13         } finally {
14             _lock.ExitReadLock ();
15         }
16     }
17 
18     public void Write (Action functor) {
19         _lock.EnterWriteLock ();
20         try {
21             functor (_shared);
22         } finally {
23             _lock.ExitWriteLock ();
24         }
25     }
26 }

圖 1 中只有 27 行代碼,但卻精妙簡潔地確保物件跨多個執行緒進行同步。此類假定型別中有讀取接口和寫入接口。如果由於某種原因而無法更改需要將訪問權限同步到的基礎類實現,也可以重覆模板類本身三次,通過這種方式使用它。基本用法如圖 2 所示。

圖 2:使用 Synchronizer 類

 1 interface IReadFromShared {
 2     string GetValue ();
 3 }
 4 
 5 interface IWriteToShared {
 6     void SetValue (string value);
 7 }
 8 
 9 class MySharedClass : IReadFromShared, IWriteToShared {
10     string _foo;
11 
12     public string GetValue () {
13         return _foo;
14     }
15 
16     public void SetValue (string value) {
17         _foo = value;
18     }
19 }
20 
21 void Foo (Synchronizer sync) {
22     sync.Write (x => {
23         x.SetValue ("new value");
24     });
25     sync.Read (x => {
26         Console.WriteLine (x.GetValue ());
27     })
28 }

在圖 2 的代碼中,無論有多少執行緒在執行 Foo 方法,只要執行另一個 Read 或 Write 方法,就不會呼叫 Write 方法。不過,可以同時呼叫多個 Read 方法,而不必在代碼中分散多個 try/catch/finally 陳述句,也不必不斷重覆相同的代碼。我在此鄭重宣告,通過簡單字串來使用它是沒有意義的,因為 System.String 不可變。我使用簡單的字串物件來簡化示例。

基本思路是,必須將所有可以修改實體狀態的方法都添加到 IWriteToShared 接口中。同時,應將所有隻從實體讀取內容的方法都添加到 IReadFromShared 接口中。通過將諸如此類的問題分散到兩個不同的接口,並對基礎型別實現這兩個接口,可使用 Synchronizer 類來同步對實體的訪問權限。這樣一來,將訪問權限同步到代碼的做法變得更簡單,並且基本上可以通過更具宣告性的方式這樣做。

在多執行緒編程方面,語法糖可能會決定成敗。除錯多執行緒代碼通常極為困難,並且創建同步物件的單元測試可能會是徒勞無功之舉。

如果需要,可以創建只包含一個泛型引數的多載型別,不僅繼承自原始 Synchronizer 類,還將它的一個泛型引數作為型別引數三次傳遞到它的基類。這樣一來,就不需要讀取接口或寫入接口了,因為可以直接使用型別的具體實現。不過,這種方法要求手動處理需要使用 Write 或 Read 方法的部分。此外,雖然它的安全性稍差一點,但確實可便於將無法更改的類包裝到 Synchronizer 實體中。

用於分支的 lambda 集合

邁出第一步來使用神奇的 lambda(或在 C# 中稱為“委托”)後,不難想象,可以利用它們完成更多操作。例如,反覆出現的常見多執行緒主題是,讓多個執行緒與其他服務器聯繫,以提取資料並將資料傳回給呼叫方。

最簡單的例子就是,應用程式從 20 個網頁讀取資料,併在完成後將 HTML 傳回給一個根據所有網頁的內容創建某種聚合結果的執行緒。除非為每個檢索方法都創建一個執行緒,否則此代碼的運行速度比預期慢得多:99% 的所有執行時間可能會花在等待 HTTP 請求傳回上。

在一個執行緒上運行此代碼的效率很低,並且執行緒創建語法非常容易出錯。隨著你支持多個執行緒及其助理物件,挑戰變得更嚴峻,開發人員不得不在編寫代碼時使用重覆代碼。意識到可以創建委托集合和用於包裝這些委托的類後,便能使用一個方法呼叫來創建所有執行緒。這樣一來,創建執行緒就輕鬆多了。

圖 3 中的一段代碼創建兩個並行運行的此類 lambda。請註意,此代碼實際上來自我的第一版 Lizzie 腳本語言的單元測試 (bit.ly/2FfH5y8)。

圖 3:創建 lambda

 1 public void ExecuteParallel_1 () {
 2     var sync = new Synchronizer<string, string, string> ("initial_");
 3 
 4     var actions = new Actions ();
 5     actions.Add (() => sync.Assign ((res) => res + "foo"));
 6     actions.Add (() => sync.Assign ((res) => res + "bar"));
 7 
 8     actions.ExecuteParallel ();
 9 
10     string result = null;
11     sync.Read (delegate (string val) { result = val; });
12     Assert.AreEqual (true, "initial_foobar" == result || result == "initial_barfoo");
13 }

仔細看看這段代碼便會發現,計算結果並未假定我的兩個 lambda 的執行存先後順序。執行順序並未明確指定,並且這些 lambda 是在不同的執行緒上執行。這是因為,使用圖 3 中的 Actions 類,可以向它添加委托,這樣稍後就能決定是要並行執行委托,還是按順序執行委托。

為此,必須使用首選機制創建並執行許多 lambda。在圖 3 中可以看到前面提到的 Synchronizer 類,用於同步對共享字串資源的訪問權限。不過,它對 Synchronizer 使用了新方法 Assign,我並未在圖 1中的串列內為 Synchronizer 類添加此方法。Assign 方法使用前面 Write 和 Read 方法中使用的相同“lambda 技巧”。

若要研究 Actions 類的實現,請務必下載 Lizzie 版本 0.1,因為我在後面推出的版本中完全重寫了代碼,使之成為獨立編程語言。

C# 中的函式式編程

大多數開發人員往往認為,C# 幾乎與面向物件的編程 (OOP) 同義或至少密切相關,事實顯然如此。不過,通過重新思考如何使用 C#,並深入瞭解它的各方面功能,解決一些問題就變得更加簡單了。目前形式的 OOP 不太易於重用,原因很多是因為它是強型別。

例如,如果重用一個類,就不得不重用初始類取用的每個類(在兩種情況下,類都是通過組合和繼承進行使用)。此外,類重用還會強制重用這些第三方類取用的所有類等。如果這些類是在不同的程式集中實現,必須添加各種各樣的程式集,才能獲得對一個型別上單個方法的訪問權限。

我曾經看過一個可以說明這個問題的類比:“雖然想要的是香蕉,但最終得到的是手拿香蕉的大猩猩,以及大猩猩所居住的熱帶雨林。” 將這種情況與使用更動態的語言(如 JavaScript)進行重用做比較,後者並不關心型別,只要它實現函式本身使用的函式即可。通過略微寬鬆型別方法生成的代碼更靈活、更易於重用。委托可以實現這一點。

可使用 C# 來改善跨多個專案重用代碼的過程。只需要理解函式或委托也可以是物件,並且可以通過弱型別方式控制這些物件的集合。

早在 2018 年 11 月發行的《MSDN 雜誌》中,我發表過一篇標題為“使用符號委托創建你自己的腳本語言”的文章 (msdn.com/magazine/mt830373)。本文中提到的有關委托的思路是在這篇文章的基礎之上形成。本文還介紹了 Lizzie,這是我的自製腳本語言,它的存在歸功於這種以委托為中心的思維樣式。如果我使用 OOP 規則創建了 Lizzie,我會認為,它在大小上可能至少大一個數量級。

當然,如今 OOP 和強型別處於主導地位,想要找到一個主要必需技能不要求它的職位描述,幾乎是不可能的。我在此鄭重宣告,我創建 OOP 代碼的時間已超過 25 年,所以,我與任何人一樣都會因為對強型別有偏見而感到內疚。然而,如今我在編碼方法上更加務實,對類層次結構的最終外觀失去興趣。

並不是我不欣賞外觀精美的類層次結構,而是收益遞減。添加到層次結構中的類越多,它就變得越臃腫,直到因不堪重壓而崩潰。有時,卓越的設計只用很少的方法、更少的類和大多數鬆散耦合的函式,這樣就可以輕鬆擴展代碼,也就不需要“引入大猩猩和熱帶雨林”了。

回到本文反覆出現的主題(從 Miles Davis 的音樂方法中獲得靈感):少即是多(“沒有聲音比有聲音更重要”)。 代碼也不例外。間斷代碼行往往會產生奇跡,最佳解決方案的衡量依據更多是不編碼什麼,而不是編碼什麼。連傻瓜也可以將喇叭吹響,但只有為數不多的人才能用喇叭吹奏出音樂。像 Miles 這樣能創造出奇跡的人就更少了。


 原文作者:Thomas Hansen

原文地址:Minimize Complexity in Multithreaded C# Code

赞(0)

分享創造快樂