COM 公寓模型下的執行緒調度深度解析

前言：為何需要公寓概念

公寓是邏輯概念，作業系統僅為執行緒/程序配置資源。COM 引入公寓模型（STA/MTA），根本目的是在多執行緒環境下同步存取元件，免除開發者自行實作同步控制的負擔。

STA 同步機制：隱含視窗訊息佇列

呼叫 CoInitializeEx(COINIT_APARTMENTTHREADED) 時，系統自動建立隱含視窗及其訊息佇列。外部執行緒呼叫 STA 內物件方法時，呼叫被封裝為訊息放入佇列。訊息佇列的線性特性天然實現同步序列化。

MTA 同步機制推測

文獻雖未明述，但 MTA 應同樣擁有隱含視窗佇列機制，以相同方式達成同步。

公寓間調度的雙重含義

1. 介面指標封送處理

COM 介面指標與公寓綁定，不可跨公寓直接使用。跨公寓傳遞需經過封送：

• 來源公寓（STA1）：CoMarshalInterThreadInterfaceInStream 將指標封送至資料流。
• 目標公寓（STA2）：CoGetInterfaceAndReleaseStream 反封送，取得Proxy（代理）指標。

STA2 拿到的是指向 Proxy 的指標，而非真實物件指標。

2. 方法呼叫轉發

STA2 透過 Proxy 呼叫方法，Proxy 將呼叫封裝放入 STA1 的訊息佇列，由 STA1 執行緒取出執行，回傳結果再透過 Proxy 送回。這也是「調度」。

Proxy/Stub 架構差異

• 公寓間： 僅有 Proxy，無 Stub。Proxy 工作單純：將呼叫投遞至目標公寓訊息佇列。
• 程序間/遠端： 有 Proxy/Stub 雙方。須處理不同位址空間對應、參數封裝/解封裝，複雜度高得多。

關鍵結論

1. MTA 同樣擁有隱含視窗佇列實現同步。
2. 跨公寓必須封送介面指標，獲得 Proxy 指標。
3. 跨公寓方法呼叫必須透過 Proxy。
4. 公寓調度純粹為同步服務，不涉及位址空間轉換。
5. 無 Stub 證明無參數封裝需求，Proxy 僅負責訊息投遞。
6. 公寓調度非強制： 若元件自行實作同步（如使用 FTM 自由執行緒封送器），可繞過公寓調度直接呼叫。

啟發

理解公寓本質是「同步服務提供者」而非「隔離邊界」，有助於設計高效能 COM 系統：對於高頻呼叫物件，可考慮實作免公寓或自行同步，避免訊息佇列延遲；對於 UI 物件，善用 STA 天然同步特性簡化開發。