在這一部分我將講解COM提出的各個(gè)類型的線程模型，并說明COM運(yùn)行時(shí)期庫(kù)是如何實(shí)現(xiàn)它們的。

本文講解COM提出的各個(gè)類型的線程模型，再說明COM運(yùn)行時(shí)期庫(kù)是如何實(shí)現(xiàn)它們的.

線程模型是一種數(shù)學(xué)模型，專門針對(duì)多線程編程而提供的算法，但也僅是算法，不是實(shí)現(xiàn)。本文講解COM提出的各個(gè)類型的線程模型，再說明COM運(yùn)行時(shí)期庫(kù)是如何實(shí)現(xiàn)它們的，就像說明Windows是如何實(shí)現(xiàn)線程這個(gè)數(shù)學(xué)模型的一樣，最后指明一下跨套間調(diào)用和各種類型套間編寫的要求以幫助理解。希望讀者對(duì)于Windows操作系統(tǒng)的線程這個(gè)概念相當(dāng)熟悉，對(duì)何謂“線程安全的”亦非常了解。

　　COM線程模型

　　COM提供的線程模型共有三種：Single-Threaded Apartment（STA 單線程套間）、Multithreaded Apartment（MTA 多線程套間）和Neutral Apartment/Thread Neutral Apartment/Neutral Threaded Apartment（NA/TNA/NTA 中立線程套間，由COM+提供）。雖然它們的名字都含有套間這個(gè)詞，這只是COM運(yùn)行時(shí)期庫(kù)（注意，不是COM規(guī)范，以下簡(jiǎn)稱COM）使用套間技術(shù)來實(shí)現(xiàn)前面的三種線程模型，應(yīng)注意套間和線程模型不是同一個(gè)概念。COM提供的套間共有三種，分別一一對(duì)應(yīng)。而線程模型的存在就是線程規(guī)則的不同導(dǎo)致的，而所謂的線程規(guī)則就只有兩個(gè)：代碼是線程安全的或不安全的，即代碼訪問公共數(shù)據(jù)時(shí)會(huì)或不會(huì)發(fā)生訪問沖突。由于線程模型只是個(gè)模型，概念上的，因此可以違背它，不過就不能獲得COM提供的自動(dòng)同步調(diào)用及兼容等好處了。

　　STA 一個(gè)對(duì)象只能由一個(gè)線程訪問（通過對(duì)象的接口指針調(diào)用其方法），其他線程不得訪問這個(gè)對(duì)象，因此對(duì)于這個(gè)對(duì)象的所有調(diào)用都是同步了的，對(duì)象的狀態(tài)（也就是對(duì)象的成員變量的值）肯定是正確變化的，不會(huì)出現(xiàn)線程訪問沖突而導(dǎo)致對(duì)象狀態(tài)錯(cuò)誤。其他線程要訪問這個(gè)對(duì)象，必須等待，直到那個(gè)唯一的線程空閑時(shí)才能調(diào)用對(duì)象。注意：這只是要求、希望、協(xié)議，實(shí)際是否做到是由COM決定的。如上所說，這個(gè)模型很像Windows提供的窗口消息運(yùn)行機(jī)制，因此這個(gè)線程模型非常適合于擁有界面的組件，像ActiveX控件、OLE文檔服務(wù)器等，都應(yīng)該使用STA的套間。

　　MTA 一個(gè)對(duì)象可以被多個(gè)線程訪問，即這個(gè)對(duì)象的代碼在自己的方法中實(shí)現(xiàn)了線程保護(hù)，保證可以正確改變自己的狀態(tài)。這對(duì)于作為業(yè)務(wù)邏輯組件或干后臺(tái)服務(wù)的組件非常適合。因?yàn)樽鳛橐粋€(gè)分布式的服務(wù)器，同一時(shí)間可能有幾千條服務(wù)請(qǐng)求到達(dá)，如果排隊(duì)進(jìn)行調(diào)用，那么將是不能想像的。注意：這也只是一個(gè)要求、希望、協(xié)議而已。


　　NA 一個(gè)對(duì)象可以被任何線程訪問，與MTA不同的是任何線程，而且當(dāng)跨套間訪問時(shí)（后面說明），它的調(diào)用費(fèi)用（耗費(fèi)的CPU時(shí)間及資源）要少得多。這準(zhǔn)確的說都已經(jīng)不能算是線程模型了，它是結(jié)合套間的具體實(shí)現(xiàn)而提出的要求，它和MTA不同的是COM的實(shí)現(xiàn)方式而已。
COM套間

　　Apartment被翻譯成套間或是單元，是線程模型的一個(gè)實(shí)現(xiàn)者，就像在操作系統(tǒng)課程中講到的線程只是一個(gè)數(shù)學(xué)模型，而Windows的線程、進(jìn)程是它（數(shù)學(xué)模型的線程、進(jìn)程）的實(shí)現(xiàn)者。套間只是邏輯上的一個(gè)概念，實(shí)現(xiàn)時(shí)只是一個(gè)結(jié)構(gòu)（由COM管理）而已，記錄著相關(guān)信息，如它的種類（只能是上面那三個(gè)，至少現(xiàn)在是），并由COM根據(jù)那個(gè)結(jié)構(gòu)進(jìn)行相應(yīng)的處理。下面說明這三種套間的實(shí)現(xiàn)方式：

　　STA套間 一個(gè)套間如果是STA，那么那個(gè)套間有且只有一個(gè)線程和其關(guān)聯(lián)，有多個(gè)對(duì)象或沒有對(duì)象和其關(guān)聯(lián)，就像有多個(gè)線程和一個(gè)進(jìn)程關(guān)聯(lián)一樣，也就是說套間那個(gè)結(jié)構(gòu)和某個(gè)線程及多個(gè)對(duì)象之間有關(guān)系，關(guān)系具體是什么由COM說得算，幸運(yùn)的是COM正是按照上面的線程模型來定義互相之間關(guān)系的。根據(jù)上面的算法，很容易就知道只有這個(gè)線程可以訪問這個(gè)套間里的對(duì)象。

　　COM是通過在STA套間里的線程中創(chuàng)建一個(gè)隱藏窗口，然后外界（這個(gè)套間外的線程）對(duì)這個(gè)對(duì)象的調(diào)用都轉(zhuǎn)變成對(duì)那個(gè)隱藏窗口發(fā)送消息，然后由這個(gè)隱藏窗口的消息處理函數(shù)來實(shí)際調(diào)用組件對(duì)象的方法來實(shí)現(xiàn)STA的規(guī)則的。之所以使用一個(gè)隱藏窗口是為了方便組件代碼的編寫——只需調(diào)用DispatchMessage即可將方法調(diào)用的消息和普通的消息區(qū)分開來（通過隱藏窗口的消息處理函數(shù)）。外界對(duì)這個(gè)對(duì)象的調(diào)用都將轉(zhuǎn)變成對(duì)這個(gè)隱藏窗口的消息發(fā)送來實(shí)現(xiàn)同步。至于COM如何截獲外界對(duì)對(duì)象的調(diào)用，則是利于代理對(duì)象，后面再說明。

　　值得注意的是，如果使用標(biāo)準(zhǔn)匯集法生成代理對(duì)象，則代理對(duì)象會(huì)根據(jù)是進(jìn)程內(nèi)還是進(jìn)程外的跨套間調(diào)用，來決定具體操作。如果外界線程和STA線程在同一進(jìn)程內(nèi)，則代理對(duì)象將直接向STA線程中的隱藏窗口發(fā)送消息；如果不在同一進(jìn)程內(nèi)（包括遠(yuǎn)程進(jìn)程），代理對(duì)象將向RPC管理的一個(gè)線程池請(qǐng)求一個(gè)線程（RPC線程）來專門向另一進(jìn)程中的STA線程的隱藏窗口發(fā)送消息，而不是代理對(duì)象直接發(fā)送消息，以防止外界線程由于網(wǎng)絡(luò)等不穩(wěn)定因素而導(dǎo)致掛起。

　　因?yàn)镃OM利用消息機(jī)制來實(shí)現(xiàn)STA，因此STA套間里的線程必須實(shí)現(xiàn)消息循環(huán)，否則COM將不能實(shí)現(xiàn)STA的要求。

　　MTA套間 這種類型的套間可以和多個(gè)線程及多個(gè)或沒有對(duì)象相關(guān)聯(lián)。根據(jù)上面的MTA模型，可知只有這個(gè)套間里的線程才能訪問這個(gè)套間里的對(duì)象，和STA不同的只是可以多個(gè)線程同時(shí)訪問對(duì)象。

　　外界（不屬于這個(gè)套間的線程）對(duì)這個(gè)套間里的對(duì)象的調(diào)用將會(huì)導(dǎo)致調(diào)用線程（外界線程，也就是STA線程，因?yàn)镹A沒有線程）掛起，然后向RPC管理的一個(gè)線程池請(qǐng)求一個(gè)線程（RPC線程，并已經(jīng)進(jìn)入了這個(gè)MTA套間）以調(diào)用那個(gè)對(duì)象的方法。對(duì)象返回后，調(diào)用線程被喚醒，繼續(xù)運(yùn)行。雖然可以讓STA線程直接調(diào)用對(duì)象（而不用像前述的掛起等待另一個(gè)線程來調(diào)用對(duì)象），但這是必須的，因?yàn)榭赡軙?huì)有回調(diào)問題，比如這個(gè)MTA線程又反過來回調(diào)外界線程中的組件對(duì)象（假設(shè)客戶本身也是一個(gè)組件對(duì)象，這正是連接點(diǎn)技術(shù)），如果異步回調(diào)將可能發(fā)生錯(cuò)誤。

　　反過來，MTA的線程訪問STA里的對(duì)象時(shí)，COM將把調(diào)用轉(zhuǎn)換成對(duì)STA線程里那個(gè)隱藏窗口的一個(gè)消息發(fā)送，返回后再由COM轉(zhuǎn)成結(jié)果返回給MTA的線程（如果使用標(biāo)準(zhǔn)匯集法生成標(biāo)準(zhǔn)代理對(duì)象，則發(fā)生的具體情況就如上面STA套間所述）。因此STA和MTA都是只能由它們關(guān)聯(lián)的線程調(diào)用它們關(guān)聯(lián)的對(duì)象。而根據(jù)上面所說，當(dāng)MTA調(diào)STA或STA調(diào)MTA，都會(huì)發(fā)生線程切換，也就是說一個(gè)線程掛起而換成執(zhí)行另一個(gè)線程。這是相當(dāng)大的消耗（需要從內(nèi)核模式向用戶模式轉(zhuǎn)換，再倒轉(zhuǎn)好幾回），而NA就是針對(duì)這個(gè)設(shè)計(jì)的。

　　NA套間 這種套間只和對(duì)象相關(guān)聯(lián)，沒有關(guān)聯(lián)的線程，因此任何線程都可以直接訪問里面的對(duì)象，不存在STA的還是MTA的。

　　外界（其實(shí)就是任何線程）對(duì)這個(gè)套間里面的調(diào)用都不需要掛起等待，而是進(jìn)入NA套間，直接調(diào)用對(duì)象的方法。NA套間是由COM+提供的，COM+中的每個(gè)對(duì)象都有一個(gè)環(huán)境和其相綁定，環(huán)境記錄了必要的信息，并監(jiān)聽對(duì)對(duì)象的每一次調(diào)用，以保證當(dāng)將對(duì)象的接口指針成員變量進(jìn)行傳遞或回調(diào)時(shí)其操作的正確性（保證執(zhí)行線程在正確的套間內(nèi)，MTA線程就是通過將自己掛起以等待STA線程的消息處理完畢來保證的），從而避免了調(diào)用線程的掛起，因此這個(gè)代理（其實(shí)也就是環(huán)境的一部分）被稱作輕量級(jí)代理（相對(duì)于STA套間和MTA套間的重量級(jí)代理——需要掛起調(diào)用線程，發(fā)生線程切換）。

　　這個(gè)輕量級(jí)代理并不是永遠(yuǎn)都不發(fā)生線程切換。當(dāng)NA對(duì)象里有個(gè)對(duì)指向一個(gè)STA對(duì)象的指針的調(diào)用而調(diào)用線程不是那個(gè)STA對(duì)象關(guān)聯(lián)的線程時(shí)，調(diào)用將會(huì)轉(zhuǎn)成向被調(diào)用的STA對(duì)象的關(guān)聯(lián)線程發(fā)送消息，此時(shí)照樣會(huì)發(fā)生線程切換。同理，如果那個(gè)對(duì)象是MTA的，而調(diào)用線程是STA線程時(shí)，依舊發(fā)生線程切換。不過除此以外的大多數(shù)情況（即不在NA對(duì)象的方法中調(diào)用另一個(gè)套間對(duì)象的方法）都不會(huì)發(fā)生線程切換，即使出現(xiàn)上面的情況也只有必要（MTA調(diào)NA再調(diào)MTA就不用切換）才切換線程。

　　根據(jù)上面所說，STA其實(shí)和MTA邏輯上是完全一樣的，只是一個(gè)是關(guān)聯(lián)一個(gè)線程，一個(gè)是關(guān)聯(lián)多個(gè)線程而已。但把它們分開是必要的，因?yàn)榫€程安全就是針對(duì)是一個(gè)線程還是多個(gè)線程。而NA之所以不關(guān)聯(lián)線程是因?yàn)樗哪康氖窍厦婵缣组g調(diào)用時(shí)產(chǎn)生的線程切換損耗，關(guān)聯(lián)線程沒有任何意義。

　　COM強(qiáng)行規(guī)定（不遵守也沒轍，因?yàn)槿荂OM實(shí)現(xiàn)套間的，根本沒有插手的余地）一個(gè)進(jìn)程可以擁有多個(gè)STA的套間，但只能擁有一個(gè)MTA套間和一個(gè)NA套間，我想這應(yīng)該已經(jīng)很容易理解了（要兩個(gè)MTA套間或NA套間干甚？）。
套間生成規(guī)則

　　線程在進(jìn)行大多數(shù)COM操作之前，需要先調(diào)用CoInitialize或CoInitializeEx。調(diào)用CoInitialize告訴COM生成一個(gè)STA套間，并將當(dāng)前的調(diào)用線程和這個(gè)套間相關(guān)聯(lián)。而調(diào)用CoInitializeEx( NULL, COINIT_MULTITHREADED );告訴COM檢查是否已經(jīng)有了一個(gè)MTA套間，沒有則生成一個(gè)MTA套間，然后將那個(gè)套間和調(diào)用線程相關(guān)聯(lián)。接著在調(diào)用CoCreateInstance或CoGetClassObject等創(chuàng)建對(duì)象的函數(shù)時(shí)，創(chuàng)建的對(duì)象將以一個(gè)特定規(guī)則決定和哪個(gè)套間相關(guān)聯(lián)（后敘）。這樣完成后，就完成了線程、對(duì)象和套間的關(guān)聯(lián)（或綁定）。

　　前面提到的決定對(duì)象去向的規(guī)則如下。

　　當(dāng)是進(jìn)程內(nèi)組件時(shí)，根據(jù)注冊(cè)表項(xiàng)<CLSID>\InprocServer32\ThreadingModel和線程的不同，列于下表：

　　進(jìn)程內(nèi)的主STA套間是進(jìn)程中第一個(gè)調(diào)用CoInitialize的線程所關(guān)聯(lián)的套間（即進(jìn)程中的第一個(gè)STA套間）。后面說明為什么還來個(gè)進(jìn)程內(nèi)的主STA套間。

　　當(dāng)是進(jìn)程外組件時(shí)，由主函數(shù)調(diào)用CoInitializeEx或CoInitialize指定組件所在套間，與上面的相同，CoInitialize代表STA，CoInitializeEx( NULL, COINIT_MULTITHREADED );代表MTA，沒有NA。因?yàn)镹A是COM+提供的，而COM+服務(wù)只能提供給進(jìn)程內(nèi)服務(wù)器，因此只使用上面的注冊(cè)表項(xiàng)的規(guī)則決定DLL組件是否放進(jìn)NA套間，而沒有提供類似CoInitializeEx( NULL, COINIT_NEUTRAL );來處理EXE組件。而且如果可以使用CoInitializeEx( NULL, COINIT_NEUTRAL );將導(dǎo)致調(diào)用線程和NA套間相關(guān)聯(lián)了，違背了NA的線程模型，這也是為什么ThreadingModel鍵在<CLSID>\InprocServer32鍵下。

　　跨套間調(diào)用

　　STA線程1創(chuàng)建了一個(gè)STA對(duì)象，得到接口指針I(yè)ABCD*，接著它發(fā)起STA線程2，并且將IABCD*作為線程參數(shù)傳入。在線程2中，調(diào)用IABCD::Abc()方法，成功或者失敗天注定。由于線程2所在的STA套間不同于線程1所在的STA套間，這樣線程2就跨套間調(diào)用另一個(gè)套間的對(duì)象了。按照前述的STA規(guī)則，IABCD::Abc()應(yīng)該被轉(zhuǎn)成消息來發(fā)送，而如果如上面做法，可以，編譯通過，不過運(yùn)行就不保證了。

　　COM之所以能夠?qū)崿F(xiàn)前面所說的那些規(guī)則（STA、MTA、NA），是因?yàn)榭缣组g調(diào)用時(shí)，被調(diào)用的對(duì)象指針是指向一個(gè)代理對(duì)象，不是組件對(duì)象本身。而那個(gè)代理對(duì)象實(shí)現(xiàn)前述的那三個(gè)實(shí)現(xiàn)算法（轉(zhuǎn)成消息發(fā)送，線程切換等），而一般所說的代理/占位對(duì)象（Proxy/Stub）等其實(shí)都只是指進(jìn)行匯集工作的代碼（后述）。而按照上面直接通過線程參數(shù)傳入的指針是直接指向?qū)ο蟮?#xff0c;所以將不能實(shí)現(xiàn)STA規(guī)則，為此COM提供了如下兩個(gè)函數(shù)（還有其他方式，如通過全局接口表GIT）來方便產(chǎn)生代理：CoMarshalInterface和CoUnmarshalInterface（如果在同一進(jìn)程內(nèi)的線程間傳遞接口指針，則可以通過這兩個(gè)函數(shù)來進(jìn)一步簡(jiǎn)化代碼的編寫：CoMarshalInterThreadInterfaceInStream和CoGetInterfaceAndReleaseStream）。
現(xiàn)在重寫上面代碼，線程1得到IABCD*后，調(diào)用CoMarshalInterface得到一個(gè)IStream*，然后將IStream*傳入線程2，在線程2中，調(diào)用CoUnmarshalInterface得到IABCD*，現(xiàn)在這個(gè)IABCD*就是指向代理對(duì)象的，而不是組件對(duì)象了。

　　因此，前面所說過的所有線程模型的算法都是通過代理對(duì)象實(shí)現(xiàn)的。要跨套間時(shí)，使用CoMarshalInterface將代理對(duì)象的CLSID和其與組件對(duì)象建立聯(lián)系的一些必要信息（如組件對(duì)象的接口指針）列集（Marshaling）到一個(gè)IStream*中，再通過任何線程間通信手段（如全局變量等）將IStream*傳到要使用的線程中，再用CoUnmarshalInterface散集（Unmarshaling）出接口以獲得指向代理對(duì)象的接口指針。因此之所以要獲得代理對(duì)象的指針是因?yàn)橄胧褂肅OM提供的線程模型（但在COM+中，這不是唯一的理由），如果不想使用大可不必這么麻煩（不過后果自負(fù)），并沒有強(qiáng)制要求必須那么做。

　　當(dāng)線程1和線程2都是MTA時(shí)，則可以像最開始說的那樣，直接傳遞IABCD*到線程2中，因?yàn)镸TA線程模型同意多個(gè)線程同時(shí)直接調(diào)用對(duì)象，線程1和線程2在同一個(gè)MTA套間中，而那個(gè)對(duì)象通過某種形式（如ThreadingModel = Free）向COM聲明了自己支持MTA線程模型。

　　而當(dāng)a.exe的線程1和b.exe的線程2都是MTA時(shí)，則依舊需要像上面那樣進(jìn)行接口指針的匯集（列集→傳輸→散集這個(gè)過程）以得到指向代理而非對(duì)象的指針，即使線程1和線程2都是在MTA套間中，卻是在兩個(gè)不同的MTA套間中，因此是跨套間調(diào)用，需要匯集操作。

　　匯集代碼

　　前面已經(jīng)說明了套間的規(guī)則都是通過對(duì)代理對(duì)象而非組件對(duì)象發(fā)起調(diào)用以截取對(duì)組件對(duì)象的調(diào)用由代理對(duì)象來實(shí)現(xiàn)的。代理對(duì)象要和組件對(duì)象交互，將方法參數(shù)傳遞給組件對(duì)象，需要使用到匯集技術(shù)，也就是列集→傳輸→散集這個(gè)過程。

　　列集（Marshaling）指將信息以某種格式存為流（IStream*）形式的操作；散集（Unmarshaling）則是列集的反操作，將信息從流形式中反還出來；傳輸則只是流形式的傳遞操作。

　　這里經(jīng)常發(fā)生誤會(huì)。前面的CoMarshalInterface所做的列集，是將代理對(duì)象的CLSID及一些持久信息（用于初始化代理對(duì)象）格式化為一種格式（網(wǎng)絡(luò)數(shù)據(jù)描述——Network Data Representation）后放到一個(gè)流對(duì)象中，可以通過網(wǎng)絡(luò)（或其他方式）將這個(gè)流對(duì)象傳遞到客戶機(jī)，由客戶通過CoUnmarshalInterface從傳來的流對(duì)象中反還出代理對(duì)象的CLSID和初始化用的一些持久信息，生成代理對(duì)象并使用持久信息初始化它以用于匯集操作。這就是發(fā)生誤會(huì)的地方——這里的匯集操作不同于上面的匯集操作，其匯集的是接口方法的參數(shù)而不是什么CLSID和一些初始化信息。

　　因此CoMarshalInterface和CoUnmarshalInterface是用于匯集接口指針的，再準(zhǔn)確點(diǎn)應(yīng)該是用于生成代理對(duì)象的。代理對(duì)象應(yīng)由讀者自己實(shí)現(xiàn)，用于匯集接口方法的參數(shù)。一般有兩種代理對(duì)象的實(shí)現(xiàn)方式：自定義匯集和標(biāo)準(zhǔn)匯集。

　　對(duì)于自定義匯集，組件需實(shí)現(xiàn)IMarshal接口和一個(gè)代理組件（即完全實(shí)現(xiàn)真正組件所有接口的一個(gè)副本，實(shí)現(xiàn)了匯集方法參數(shù)及線程模型的規(guī)則，也必須實(shí)現(xiàn)IMarshal接口），并將這個(gè)代理組件在客戶機(jī)上注冊(cè)，以保證代理對(duì)象的正確生成。注意：如果參數(shù)中有接口指針，必須用CoMarshalInterface和CoUnmarshalInterface進(jìn)行匯集，否則無法實(shí)現(xiàn)正確的線程模型，且代理組件是線程模型的實(shí)現(xiàn)者，這點(diǎn)組件必須自己保證（如發(fā)送消息等）。

　　對(duì)于標(biāo)準(zhǔn)匯集，組件無需實(shí)現(xiàn)IMarshal接口及代理組件，代替的，組件則需要為自己生成一個(gè)代理/占位組件（Proxy/Stub），其由于可通過MIDL由IDL文件自動(dòng)生成，效率高，代碼的正確性有保證，因而被鼓勵(lì)使用。COM提供了一個(gè)標(biāo)準(zhǔn)代理對(duì)象的實(shí)現(xiàn)，其通過聚合組件的代理/占位組件以表現(xiàn)出其好像是組件的代理對(duì)象。與自定義匯集一樣，需要將這個(gè)代理/占位組件在客戶機(jī)上注冊(cè)以保證代理對(duì)象的正確生成。

　　至于這兩種匯集的具體工作機(jī)理，由于與本文無關(guān)，在此不表，這里僅僅只為消除代理對(duì)象和代理/占位組件之間的混淆。

　　注意：對(duì)于將運(yùn)行于NA套間的組件，由于COM+的強(qiáng)制要求，其必須使用標(biāo)準(zhǔn)匯集進(jìn)行代理對(duì)象的生成而不是自定義匯集（COM+運(yùn)行時(shí)期庫(kù)重寫了標(biāo)準(zhǔn)代理對(duì)象來截獲對(duì)組件對(duì)象的調(diào)用和其自身的某些特殊處理——如保證NA套間正確工作）。

套間實(shí)現(xiàn)規(guī)則

　　如前面所說，COM的套間機(jī)制要成功，必須服務(wù)器（組件）、客戶和COM運(yùn)行時(shí)期庫(kù)三方面合力實(shí)現(xiàn)，其中有任何一方不按著規(guī)矩來，將不能實(shí)現(xiàn)套間機(jī)制的功能，不過這并不代表什么錯(cuò)誤，套間機(jī)制不能運(yùn)作并不代表程序會(huì)崩潰，只是不能和其他COM應(yīng)用兼容而已。

　　比如：對(duì)象中的屬性1在設(shè)計(jì)的算法中肯定不會(huì)被兩個(gè)以上的線程寫入，只是會(huì)被多個(gè)線程同時(shí)讀出而已，因此不用同步，可以用MTA，但對(duì)象的屬性2卻可能被多個(gè)線程寫入，因此決定使用STA。從而在客戶端，通過前面說的CoMarshalInterface和CoUnmarshalInterface將對(duì)象指針傳到那個(gè)只會(huì)寫入對(duì)象的屬性1的線程，其實(shí)這時(shí)就可以直接將對(duì)象指針傳到這個(gè)線程，而不用想上面那樣麻煩（而且增加了效率），但是就破壞了COM的套間規(guī)矩了——兩個(gè)線程可以訪問對(duì)象，但對(duì)象在STA套間中。所以？！！什么事都不會(huì)發(fā)生，因?yàn)橐呀?jīng)準(zhǔn)確知道這個(gè)算法不會(huì)捅婁子（線程訪問沖突），即使破壞COM的規(guī)矩又怎樣？！而且組件仍可以和其他客戶兼容，因?yàn)椴话匆?guī)矩來的是客戶，與組件無關(guān)。不過如果組件破壞規(guī)矩，那么它將不能和每一個(gè)客戶兼容，但并不代表它和任何客戶都不兼容。這里其實(shí)就是客戶和組件聯(lián)合起來欺騙了COM運(yùn)行時(shí)期庫(kù)。

　　上面的例子只是想幫助讀者加深對(duì)套間的理解，實(shí)際中應(yīng)該盡量保持和COM規(guī)范的兼容性（但不兼容并不代表是錯(cuò)誤的）。客戶要做的工作前面已經(jīng)說過了（那兩個(gè)函數(shù)或全局接口表或其他只要正確的方式），下面說明組件應(yīng)該做的工作。組件可以存在于四個(gè)套間中（多了一個(gè)主STA套間），所需工作分別如下：

　　STA 當(dāng)一個(gè)組件是STA時(shí)，它必須同步保護(hù)全局變量和靜態(tài)變量，即對(duì)全局變量和靜態(tài)變量的訪問應(yīng)該用臨界段或其他同步手段保護(hù)，因?yàn)椴僮魅趾挽o態(tài)變量的代碼可以被多個(gè)STA線程同時(shí)執(zhí)行，所以那些代碼的地方要進(jìn)行保護(hù)。比如對(duì)象計(jì)數(shù)（注意，不是引用計(jì)數(shù)），代表當(dāng)前組件生成的對(duì)象個(gè)數(shù)，當(dāng)減為零時(shí)，組件被卸載。此變量一般被類廠對(duì)象使用，還好ATL和MFC已經(jīng)幫我們實(shí)現(xiàn)了缺省類廠，這里一般不用擔(dān)心，但自定義的全局或靜態(tài)變量得自己處理。

　　主STA 與STA唯一的不同是這是傻瓜型的，連靜態(tài)和全局變量都可以不用線程保護(hù)，因?yàn)樗胁皇前踩L問靜態(tài)和全局變量的對(duì)象都通過主線程（第一個(gè)調(diào)用CoInitialize的線程）的消息派送機(jī)制運(yùn)行，因此不安全的訪問都被集中到了一個(gè)線程的調(diào)用中，因而調(diào)用被序列化了，也就實(shí)現(xiàn)了對(duì)靜態(tài)和全局變量的線程保護(hù)。至于為什么是主線程，因?yàn)檫M(jìn)程要使用STA，則一定會(huì)創(chuàng)建主線程，所以一定可以創(chuàng)建主STA。因此主STA并不是什么第四種套間，只是一個(gè)STA套間，不過關(guān)聯(lián)的是主線程而已，由于它可以被用作保護(hù)靜態(tài)和全局變量而被單獨(dú)提出來說明。因此一個(gè)進(jìn)程內(nèi)也只有一個(gè)主STA套間。

　　MTA 必須對(duì)組件中的每個(gè)成員和全局及靜態(tài)變量的訪問使用同步手段進(jìn)行保護(hù)，還應(yīng)考慮線程問題，即不是簡(jiǎn)單地保護(hù)訪問即可，還應(yīng)注意線程導(dǎo)致的錯(cuò)誤的操作，最經(jīng)典的就是IUnknown::Release()。