鐵觀音

超酷代碼：來自 COM 經(jīng)驗的八個教訓(xùn)

原著：Jeff Prosise

本文轉(zhuǎn)載自微軟中國社區(qū)：http://www.microsoft.com/china/MSDN/library/windev/COMponentdev/CDwickedtoc.mspx

發(fā)布日期：5/20/2004
更新日期：5/20/2004

原文出處：Wicked Code: Eight Lessons from the COM School of Hard Knocks (Jeff Prosise)

　　在日常工作中，我看到過許多由不同開發(fā)人員編寫的 COM 代碼。我為許多富于創(chuàng)造性的使用 COM 的工作方式感到驚訝，有一些使 COM 工作的巧妙代碼可能連 Microsoft 都沒有想到。同樣，看到一些錯誤一次又一次地重犯，使我免不了心灰意懶。這些錯誤很多都與線程和安全有關(guān)，完全不成比例，而這也正是 COM 文檔資料中最缺少的兩個領(lǐng)域。如果不仔細(xì)計劃，它們也是最可能遇到的并可能會絆住您的兩個領(lǐng)域。
　　本月的“超酷代碼”專欄與以前的大多數(shù)專欄有所不同。它并未提供一段可在您自己的應(yīng)用程序中使用的超酷代碼。相反，它將講述實現(xiàn)基于 COM 的應(yīng)用程序的正確方式和錯誤方式。它將講述一些來自艱難實踐的教訓(xùn)，以及如何避免落入已經(jīng)讓許多 COM 開發(fā)人員吃盡苦頭的陷阱。
　　在下面的篇幅中，您將讀到八位程序員的記述，這些教訓(xùn)都來自他們的痛苦經(jīng)歷。每個故事都是真實的，但為了保護(hù)無辜者，名字都已隱去。我的目的是，通過這些真實的 COM 故事，使您不再重蹈其他 COM 程序員的覆轍。它們還可能會幫助您在編寫的代碼中找出存在潛在問題的地方。無論情況如何，我想您都會獲得愉快的閱讀體驗。

總是調(diào)用 CoInitialize(Ex)
　　幾個月前，我收到了一封朋友的電子郵件，他就職于一家著名的硬件公司。他的公司編寫了一個非常復(fù)雜的基于 COM 的應(yīng)用程序，其中使用了許多進(jìn)程內(nèi)和本地（進(jìn)程外）的 COM 組件。在開始時，應(yīng)用程序創(chuàng)建了 COM 對象以服務(wù)于運行在多線程單元 (MTA) 中的各種客戶端線程。該對象還可以托管給 MTA，這意味著接口指針可以在客戶端線程之間自由交換。在測試中，我的朋友發(fā)現(xiàn)在應(yīng)用程序準(zhǔn)備關(guān)閉之前，一切都進(jìn)行得不錯。然后，不知是什么原因，對 Release 的調(diào)用（必須執(zhí)行此調(diào)用，以便正確釋放客戶端占用的接口指針）被鎖定了。他的問題是：“到底是哪里出了問題？”
　　其實答案非常簡單。應(yīng)用程序的開發(fā)人員其他都做得很對，只有一點例外，而這點又非常重要：他們沒有在所有的客戶端線程中調(diào)用 CoInitialize 或 CoInitializeEx。現(xiàn)代 COM 的基本原則之一，就是每個使用 COM 的線程都應(yīng)該先調(diào)用 CoInitialize 或 CoInitializeEx 來初始化 COM。這條原則是無法免除的。除了其他事情以外，CoInitialize(Ex) 應(yīng)將線程放入單元中，并初始化重要的每線程狀態(tài)信息（這對于 COM 的正確操作是必需的）。調(diào)用 CoInitialize(Ex) 失敗通常會在應(yīng)用程序生命期早期以失敗的 COM API 函數(shù)的形式表現(xiàn)出來，最常見的是激活請求。但有時問題很隱蔽，直到一切都太晚了（例如對 Release 的調(diào)用一去不復(fù)返了）才表現(xiàn)出來。當(dāng)開發(fā)小組將 CoInitialize(Ex) 調(diào)用添加到所有接觸 COM 的線程之后，他們的問題就迎刃而解了。
　　具有諷刺意義的是，Microsoft 竟是 COM 程序員有時不調(diào)用 CoInitialize(Ex) 的原因之一。Microsoft 知識庫中包含的一些文檔中說，調(diào)用 CoInitialize(Ex) 對基于 MTA 的線程來說不是必需的（有關(guān)示例，請參閱文章 Q150777）。是的，在很多情況下，我們可以跳過 CoInitialize(Ex) 而不會出現(xiàn)問題。但是，這樣是不應(yīng)該的，除非您知道自己在干什么，并且可以絕對肯定自己不會受到負(fù)面影響。調(diào)用 CoInitialize(Ex) 是沒有害處的，因此我建議 COM 程序員始終從某個與 COM 相關(guān)的線程中調(diào)用它。

不要在線程之間傳遞原始接口指針
　　我咨詢的首批 COM 項目之一就涉及到一個包含 100,000 行代碼的分布式應(yīng)用程序，該程序是由美國西海岸的一個大型軟件公司編寫的。該應(yīng)用程序在多個機(jī)器上創(chuàng)建了數(shù)十個 COM 對象，并從客戶端進(jìn)程啟動的背景線程中調(diào)用這些對象。開發(fā)小組遇到問題了，調(diào)用要么消失得無影無蹤，要么在沒有明顯原因的情況下失敗。他們給我演示的最驚人的癥狀是：當(dāng)一個調(diào)用無法返回時，在同一臺機(jī)器上啟動其他支持 COM 的應(yīng)用程序（包括 Microsoft Paint 等）會頻繁導(dǎo)致這些應(yīng)用程序被鎖定。
　　檢查他們的代碼后發(fā)現(xiàn)，他們違反了 COM 并發(fā)的一個基本規(guī)則，就是說，如果一個線程要與另一個線程共享一個接口指針，它應(yīng)首先封送該接口指針。如果有必要，封送接口指針可使 COM 創(chuàng)建一個新的代理（以及一個新的信道對象，將代理和存根結(jié)對），以允許從另一個單元向外調(diào)用。不通過封送而將原始接口指針（內(nèi)存中的一個 32 位地址）傳遞給另一個線程，會繞過 COM 的并發(fā)機(jī)制，并且如果發(fā)送和接收的線程位于不同的單元中，將出現(xiàn)各種不良行為。（在 Windows 2000 中，由于兩個對象可以共享一個單元，但又位于不同的上下文中，因此如果線程位于同一個單元中，可能會使您陷入困境。）典型的癥狀包括調(diào)用失敗和返回 RPC_E_WRONG_THREAD_ERROR。
　　 Windows NT 4.0 和更高版本可以使用一對名為 CoMarshalInterThreadInterfaceInStream 和 CoGetInterfaceAndReleaseStream 的 API 函數(shù)，在線程之間輕松地封送接口指針。假定您應(yīng)用程序中的一個線程（線程 A）創(chuàng)建了一個 COM 對象，繼而接收了一個 IFoo 接口指針，并且同一進(jìn)程中的另一個線程（線程 B）想調(diào)用這個對象。在準(zhǔn)備將接口指針傳遞給線程 B 時，線程 A 應(yīng)該封送該接口指針，如下所示：

CoMarshalInterThreadInterfaceInStream (IID_IFoo, pFoo, &pStream);

IFoo* pFoo;
CoGetInterfaceAndReleaseStream (pStream, IID_IFoo, (void**) &pFoo);

MSG msg;
while (GetMessage (&msg, 0, 0, 0))
DispatchMessage (&msg);

static int nCallCount = 0;
nCallCount++;

static int nCallCount = 0;
InterlockIncrement (&nCallCount);

• 在服務(wù)器（在防火墻后寄存遠(yuǎn)程對象的機(jī)器）上，將 DCOM 配置為使用 TCP 作為其所選協(xié)議，如圖 3 中所示。
• 在服務(wù)器上，限制 DCOM 將使用的端口范圍。記住為每個服務(wù)器進(jìn)程至少分配一個端口。圖 4 中的示例將 DCOM 限制為端口 8,192 到 8,195。
• 打開您在步驟 2 中選擇的端口，使 TCP 通信量能夠通過防火墻。同時打開端口 135。

圖 4 選擇端口

　　執(zhí)行這些步驟，DCOM 就可以很好地跨防火墻工作了。如果您愿意，SP4 和更高版本還可讓您為單獨的 COM 服務(wù)器指定終結(jié)點。更多信息，請閱讀 Michael Nelson 關(guān)于 DCOM 和防火墻的優(yōu)秀論文，該論文可在 MSDN Online 站點上找到（請參見 http://msdn.microsoft.com/library/en-us/dndcom/html/msdn_dcomfirewall.asp）。
　　還應(yīng)注意的是，通過在服務(wù)器上安裝 Internet 信息服務(wù) (IIS)，并使用 COM Internet 服務(wù) (CIS) 通過端口 80 路由 DCOM 通信量，SP4 和更高版本的用戶還可以使用 CIS 來提供與防火墻兼容的 DCOM。有關(guān)該主題的更多信息，請參閱 http://msdn.microsoft.com/library/en-us/dndcom/html/cis.asp。

使用線程或異步調(diào)用來避免 DCOM 超時設(shè)定太長
　　總是有人問我當(dāng) DCOM 無法完成遠(yuǎn)程實例化請求或方法調(diào)用時出現(xiàn)的超時設(shè)定太長的問題。典型的場景如下：客戶端調(diào)用 CoCreateInstanceEx 來實例化遠(yuǎn)程機(jī)器上的一個對象，但是這臺機(jī)器臨時離線了。在 Windows NT 4.0 上，激活請求不會立即失敗，DCOM 可能會花上一分鐘或更長時間來返回失敗的 HRESULT。DCOM 還可能花費很長時間，使指向已不再存在或其主機(jī)已離線的遠(yuǎn)程對象的方法調(diào)用失敗。如果可能，開發(fā)人員應(yīng)該如何避免這些較長的超時設(shè)定呢？
　　要回答這個問題，幾句話是講不清楚的。DCOM 高度依賴于基礎(chǔ)網(wǎng)絡(luò)協(xié)議和 RPC 子系統(tǒng)。并沒有什么神奇的設(shè)置可讓您限制 DCOM 超時設(shè)定的持續(xù)時間。但是，我經(jīng)常使用兩種技巧來避免較長超時設(shè)定的負(fù)作用。
　　在 Windows 2000 中，當(dāng)調(diào)用在 COM 信道中掛起時，您可以使用異步方法調(diào)用來釋放調(diào)用線程。（有關(guān)異步方法調(diào)用的介紹，請參 MSDN Magazine 2000 年 4 月刊的“Windows 2000: Asynchronous Method Calls Eliminate the Wait for COM Clients and Servers Alike”。如果異步調(diào)用在合理時間內(nèi)沒有返回，您可以通過調(diào)用用于初始化調(diào)用的調(diào)用對象上的 ICancelMethodCalls::Cancel 來取消它。
　　 Windows NT 4.0 不支持異步方法調(diào)用，甚至在 Windows 2000 中也不支持異步激活請求。怎么解決呢？從背景線程調(diào)用遠(yuǎn)程對象（或是實例化該對象的請求）。使主線程在事件對象上阻塞，并指定超時設(shè)定值以反映您愿意等待的時間長度。當(dāng)調(diào)用返回時，讓背景線程來設(shè)置事件。假設(shè)主線程使用 WaitForSingleObject 阻塞，當(dāng) WaitForSingleObject 返回時，返回值可以告訴您，返回是因為方法調(diào)用或激活請求返回，還是因為您在 WaitForSingleObject 調(diào)用中指定的超時設(shè)定到期。您不能在 Windows NT 4.0 中取消掛起調(diào)用，但是至少主線程可以自由地執(zhí)行自己的任務(wù)。
　　下面的代碼演示了基于 Windows NT 4.0 的客戶端如何才能從背景線程調(diào)用對象。

//////////////////////////////////////////////////////
// Placing a Method Call from a Background Thread 
/////////////////////////////////////////////////////　
HANDLE g_hEvent;
IStream* g_pStream;

// Thread A
g_hEvent = CreateEvent (NULL, FALSE, FALSE, NULL);
CoMarshalInterThreadInterfaceInStream (IID_IFoo, pFoo, &g_pStream);
DWORD dwThreadID;
CreateThread (NULL, 0, ThreadFunc, NULL, 0, &dwThreadID);
DWORD dw = WaitForSingleObject (g_hEvent, 5000);
if (dw == WAIT_TIMEOUT) {
    // Call timed out
}
else {
    // Call completed
}
...

// Thread B
IFoo* pFoo;
CoGetInterfaceAndReleaseStream (g_pStream, IID_IFoo, (void**) &pFoo);
pFoo->Bar (); // Make the call!
SetEvent (g_hEvent);
CloseHandle (g_hEvent);