本日は「ChalkTalk CLR – COMのすべて」と題して、COM(Component Object Model)についてのディスカッションを行ってきました。
参加された方はCOM方面に強い方が半数近くいて(MVP4人、元MVP2人、中には現役で開発やってるという人も)、とにかくこれ以上ないぐらい強力なメンバーで、濃い議論が交わされました。多分、もうこういう企画は無いかな感全開 (;´Д`) 遠方からの参加もありがとうございます。 ChalkTalkバンジャーイ
この記事では、内容を「要約」して記載します。図については内容を考えて起こしなおしました。
前回と同じく、Maker Lab NAGOYAさんのスペースをお借りしました。ありがとうございました。
事前の洗い出し
まず、各参加者のCOMに対してのスキルセットを「バリバリ解説OK」~「COMって何」のレベルで、かつ自分がCOMに対して抱えている課題、という切り口で、いつも通り付箋に5分で書いてもらって張り出しました。
写真は横に集約した後の状態なので分かりにくいですが、上から「COMって何」~「バリバリ解説OK」の順で並べてあります。要約すると:
- COMの概念的なものへの疑問
- COMとWinRTとの関係
- COMの将来展望
- COMの実践的な実装方法
- スレッドアパートメントとは何か
- マーシャリングとは何か
という内容が全体的に知りたいとことと認識できたので、順に掘り下げていきました。
COMの概念的なものへの疑問
そもそもCOMとは何で、何のための技術?技法?なのか? という基本的な疑問です。ディスカッションでは、Essential COM第一章や、Inside OLEでのIUnknownインターフェイスの実装例の話から:
- 処理系の問題1: リンカー(C言語の)のリンケージの問題
- 処理系の問題2: メソッドの呼び出し規約の問題
- コンポーネントインスタンスの生存期間の問題
- インターフェイス型の認識の問題
と言う問題の解決に集約されるという意見交換がなされました。
処理系の問題
処理系の問題とは、C/C++コンパイラ・リンカーが、それぞれの製品(例:VC++、gcc、BC++など)で、シンボル名の内部的な命名規約が独自仕様である事と、メソッドのエントリポイントが特定されたとしても、その呼び出し規約が異なる事がある、と言う事です。
処理系によってシンボル名が異なる(特にC++において)問題は、シンボル名に引数の型情報を含ませることから発生します。このシンボル名の操作の事を「マングリング(Mangling)」と呼び、その仕様は処理系によって異なります。また、同じ処理系でもバージョンによっても異なる可能性があります。
(.NETではなく)Win32レベルでのDLLのエクスポートシンボルを調べるツールとして「Dependency Walker」と言うツールがあります。これを使ってEXEやDLLを調べると、エクスポートシンボルの名前が分かります。
このスクリーンショットでは「KERNEL32.DLL」のエクスポートシンボルを見ています。赤枠に表示されていますが、普通にWin32 APIのシンボル名が見えます。シンボル名が普通に見える関数は、呼び出し規約が「stdcall」である事を示しています。
対比する形で、「MSVCRT.DLL」を見てみます。赤枠を見ると、「exception」とか「badcast」とか読み取れる単語もありますが、何やらわけのわからない記号が沢山見えます。これがマングリングされた状態のシンボル名で、VC++のシンボル名規約に従って変換された結果です。
そういえば、実際のところこれがC++のどんなシンボルに相当するのかを実演しなかったのを思い出しました。これが、デマングリングした結果です(メニューから「Undecorate C++ symbol」を選択すると表示されます。見比べてみると面白いと思います)。
このような、C言語で言うところの関数名だけでは表現できない、C++のオーバーロードやクラスメンバ関数、const関数などを、シンボル名だけで識別可能にするために、マングリング操作が行われます。そしてこのマングリング操作が、処理系依存(かつバージョン依存)なのです。
したがって、例えばVC++ 6.0で普通に作ったDLLとVBで作ったDLLを直接静的にリンクすることは出来ません。他の処理系についても同様です。COMは、これらの処理系依存シンボルを使わず、COMのランタイムが提供する情報だけでクラスのファクトリを特定し、メンバ関数の位置はvtableと呼ばれる関数ポインタのテーブルの並びの整合性を担保することで、この問題を回避します。
# vtableの話はディスカッションでやらなかったですね。vtableはC++のvtableそのままで、仮想関数へのポインタのテーブルです。
どうやってクラスを特定するのかは、レジストリのHKEY_CLASSES_ROOT配下の情報を使います。ATLでプロジェクトを新規に生成すると、プロジェクト内に*.rgsのようなファイルが配置されます。これはコンポーネントレジストラスクリプトと呼び、要するにregsvr32された時にレジストリのどこにどんな値を書き込むのかを表し、このスクリプトでCOMのクラス(coclass)が特定できるようにします。
# 特定には、COMコンポーネントの実装が、どこのパスにあるDLL内にあり、どのクラス(CLSID –> GUID)なのかという情報を含みます。
もう一つの問題がメソッドの呼び出し規約で、これはWikipediaにあるように複数の規約があり、VC++では各関数単位でこれを指定して実装できるのですが、COMでは例外なく「stdcall」を使います。
生存期間
生存期間とは、COMのクラスのインスタンスが、いつまで生き続けるのかと言う問題です。.NETのインスタンスは、誰からも参照されなくなり、GCが回収する(場合によってはファイナライザーが呼び出され)と死んだ事になるのですが、C言語のようなアンマネージな世界では、「malloc」や「new」によってインスタンスが(ヒープに)生成され、「free」や「delete」によってメモリから取り除かれます。
// 確保する auto p = static_cast<int*>(malloc(123 * sizeof(int))); // 使う... // 解放する free(p);
このような簡単な例であれば、確保して解放するというサイクルから、解放のタイミングの時点で正しく解放されることが分かります。しかし:
static const int* pUseLate = nullptr; static void ComputeStep1(const int* pTarget) { // 後で使いたいので保存 pUseLate = pTarget; } static void ComputeStep2() { // (pUseLateを使って何かやる) } // 確保する auto p = static_cast<int*>(malloc(123 * sizeof(int))); // 使う... // 処理その1 ComputeStep1(p); // 処理が終わったので解放する free(p); // 処理その2 ComputeStep2();
このような処理があった場合、ComputeStep2の内部実装では、既にpが解放されていることを知る由はありません。このサンプルコードは非常に短く、メインの処理とComputeStepの実装が並べて書いてあるので「こんなのダメに決まってるじゃん!」と分かりますが、ComputeStepの実装は「別のだれか」がやるとしたらどうでしょうか? あるいは、既にComputeStepは別の誰かが実装済みであり、これからメインの処理を書く場合、ComputeStep2の実行前にpを解放してはならない事はどうやって分かるのでしょうか?
このような、インスタンスの生存期間の問題を解決する方法として、COMではクラス実装側に参照カウンタを持ち、このカウンタ値を監視することで不要になったかどうかを判定します。
生存期間のカウンタは、IUnknownインターフェイスのAddRefによってカウントアップされ、Releaseによってカウントダウンされます。カウンタの初期値は1で、AddRefのたびにインクリメントされ、Releaseが呼び出されるとデクリメントされます。カウンタが0になると、自己消滅するように実装します。
使用する側は、ポインタをコピーするときにはAddRef、使い終わったらReleaseするという規約を守る事により、生存期間が正しく管理されるようになります。
インターフェイス型の認識
インターフェイス型の認識の問題もあります。C++上でインターフェイスを示すポインタをキャストして、目的のインターフェイスへのポインタを取得しようとしたとします。
// CoCreateInstanceなどで取得したインターフェイスポインタ IUnknown* pUnknown = ...; // 目的のインターフェイスポインタを得るためにキャスト ICalc* pCalc = static_cast<ICalc*>(pUnknown);
このキャストが正しく解釈されるかどうかは、処理系に依存します。IUnknownをICalcにするにはダウンキャストが必要ですが、C++の世界ではコンパイラがその判断を行えるものの、COMの世界ではインターフェイスの情報しか存在しないため、正しくキャストできる保証がありません。そのため、キャストと言う処理自体も、IUnknown.QueryInterfaceメソッド呼び出しで解決します。
// CoCreateInstanceなどで取得したインターフェイスポインタ IUnknown* pUnknown = ...; // 目的のインターフェイスポインタを得るためにキャスト ICalc* pCalc = nullptr; pUnknown->QueryInterface(IID_ICalc, reinterpret_cast<void**>(&pCalc));
第一引数はインターフェイスID(GUID)で、これが必要なのはCOMの世界は.NETとは異なりリフレクションが存在しないので、インターフェイス型を一意に識別するIDが必要だからです。勿論、この場合のIID_ICalcは、ICalcインターフェイスのIDである前提です。
QueryInterfaceメソッド内でキャストを実装することにより、処理系の範囲内で正しくキャストが行えます。返されるポインタはキャスト後のポインタであるため、呼び出し元は処理系に依存することなくキャスト出来たことになります。
このようなメソッドを提供することで、処理系に(C++固有の)型を認識させる必要をなくし、互換性を維持します。
COMの概念への展開
結局、IUnknownの実装を通じて、どうやって処理系に依存しないでバイナリ互換性を維持するのかという事が、COMの中心にある概念であることを確認しました。COMのIUnknownとその実装はこんな感じだ!というのを、C#ライブコーディングで疑似実装して、参照カウンタの動きや、QueryInterfaceによるキャストの挙動を示して、内容の共有をしました。
# 以下のコードは、クラスファクトリも含めて穴埋めしたコードです。
// (あくまで概念コードです。これは正式なCOMのコードではありません) public interface IUnknown { T QueryInterface<T>() where T : IUnknown; int AddRef(); int Release(); } public interface ICalc : IUnknown { int Add(int a, int b); } // クラスは直接公開されない internal sealed class CalcImpl : IUnknown, ICalc { private int count_ = 1; public int AddRef() { return Interlocked.Increment(ref count_); } public int Release() { var current = Interlocked.Decrement(ref count_); if (count == 0) { // インスタンスの破棄処理 // Disposeに近いが、メモリストレージも削除される。 // 破棄処理を隠蔽することで、処理系依存を排除。 } } public T QueryInterface<T>() where T : IUnknown { // CやC++にはリフレクションは無いので、本当はインターフェイスID(GUID)で判定する。 // キャスト処理を隠蔽することで、処理系依存を排除。 if (typeof(T) == typeof(ICalc)) { Interlocked.Increment(ref count_); return (T)(object)this; } if (typeof(T) == typeof(IUnknown)) { Interlocked.Increment(ref count_); return (T)(object)this; } throw new NotImplementedException(); } public int Add(int a, int b) { return a + b; } } public interface IClassFactory { T CreateInstance<T>(Guid clsid) where T : IUnknown; } // クラスファクトリクラスも公開されない internal sealed class CalcClassFactory : IClassFactory { public T CreateInstance<T>(Guid clsid) where T : IUnknown { if (clsid == CLSID_Calc) { // newの実装を隠蔽することで、処理系依存を排除。 return new CalcImpl(); } throw new NotImplementedException(); } } // CalcImplを外部から特定するためのGuid public static readonly Guid CLSID_Calc = new Guid("BD4D1DDD-9C28-4432-A8DD-9CFA77E6433F"); // DLL外からはこのエントリポイントだけが見える public static IClassFactory DllGetClassObject() { return new CalcClassFactory(); }
もう既にかなりアレですが、まだまだ続きます。
COMとWinRT
WinRT(ストアアプリ・UWPのフレームワークとして使われるライブラリ)は、基礎がCOMで出来ていることは分かっていましたが、それ以上の理解は私の中になく、あんまり調べる意欲もなかったので、知りたかった部分です。
全てのCOMクラスはIUnknownインターフェイスを実装しますが、WinRTのクラスは、IInspectableインターフェイスも実装します。COMの世界ではITypeInfoインターフェイスをタイプライブラリ情報を公開するのに使いますが、これのWinRT版のような位置づけです。WinRTでは型情報は.NETのメタデータをそのまま使用します(winmd)。この情報との対応付けにIInspectableインターフェイスを使います。したがって、ITypeInfoのように、情報の細部までトラバース可能なメソッドセットは持っていません。
なお、COMにおいてITypeInfoインターフェイスの実装は任意ですが、WinRTのIInspectableの実装は必須です。
WinRTにおいてのもう一つの事情は、スレッドアパートメントの扱いです。WinRTでは、メインスレッドに相当するスレッドがASTAに属し、それ以外のスレッドはMTAに属するそうです。各アパートメント間の関係は、通常のCOMと同一とのこと。なるほど。
# 余談ですが、MSDNライブラリのリンク壊れてたりするよねー、直してほしいよねーみたいな話が… TechNetもぶっ壊れてるなー |д゚) チラッ
こんな話をすると、当然「アパートメントとは何か」みたいなところを避けては通れないけど、とりあえずは次の課題へ。
COMの実践的な実装方法
ようするに、どうやってCOMを書けば良いのかわからない(.NETとかVB6以外で)。
ATLでやる
ということで、一からIUnknownをCで実装するというハードは方法は時間もないのでパスし、ATL(Active Template Library)での実装方法をライブデモしました。ライブデモは私がやったのですが、ATLでバリバリ書いていたのはVisual Studio 2005の時だったので、2005を使ってデモ(こんなこともあろうかと、2005はインスコしてあるのだよ)。ATLは途中から、C#のような属性ベースの指定で楽に書けるようになったはずなのですが、結局私的には移行しなかったので分からず…
新しいプロジェクトの追加で、「ATLプロジェクト」を追加し、「プロジェクト-追加-クラス」で、「ATLシンプルオブジェクト」を選択すると、COMをATLで実装するクラスのひな型が追加されるウィザードが表示されます。短い名前の所にクラス名を入れると、各ファイル名とか良しなに決定されます。問題は次のウィザード。
ここのスレッドモデルとアグリゲーションの選択も、結構ディープだよね、ああそれとフリースレッドマーシャラーとかも。でもこの説明をするには、やっぱりアパートメントを避けては通れないしデモが中断してしまうので、ちょっと横に置いておく事に。
これでひな型が生成されたら、あとは「クラスビュー」のCOMインターフェイスのツリーから「追加-メソッド」とか「追加-プロパティ」とかやると、メンバを追加するウィザードが表示されて、メンバ定義を簡単に追加できます。もし、手動で定義するとなると、IDLファイル・ヘッダファイル・ソースファイルを同時に修正しなければならないため、かなり面倒です。そして、追加はウィザードで簡単にできますが、修正するとなると同じように全部直さなければならないので、結構苦痛…
で、実装出来たらビルドしますが、Visual Studioが管理者権限で起動していないと、最後にエラーが出ます。これはregsvr32でDLLを登録しようとしたときに、コンポーネントレジストラスクリプトがレジストリを変更するためで、素直に再起動。
TestPropという文字列(BSTR)のプロパティを追加し:
// メンバには以下のようなフィールドを定義 private: _bstr_t temp; STDMETHODIMP CTest::get_TestProp(BSTR* pVal) { // TODO: ここに実装コードを追加してください。 *pVal = temp.copy(); return S_OK; } STDMETHODIMP CTest::put_TestProp(BSTR newVal) { // TODO: ここに実装コードを追加してください。 temp = newVal; return S_OK; }
テストするコードはC#で書きました。
COM側のビルドとregsvr32が完了していれば、C#の参照設定でCOMコンポーネントが参照出来ます。
using ATLSampleLib; class Program { static void Main(string[] args) { var testClass = new TestClass(); testClass.TestProp = "ABCX"; Console.WriteLine(testClass.TestProp); } }
これで無事、コンソールに”ABCX”が表示されました。
WinRTでは文字列をHSTRING型で扱いますが、これはリテラル文字列をいちいちメモリ確保してコピーして…というコストを削減するためだそうです。なるほど、それだとCLRの世界での文字列と同じように扱われる訳で、イメージは湧きやすい。BSTRを使うと、内部ではSysAllocString APIなどでメモリを確保したり解放したりするので、コストは高いです。
いつ解放されるのか
上記テストコードで、AddRefもReleaseも呼び出していないのは?という疑問に対し、CLRの世界にはRCW(ランタイム呼び出し可能ラッパー)があって、これがAddRefとかReleaseを呼び出しているのだ、しかし、この例では使用後にすぐプロセスが終了してしまうので、果たして呼び出されるのか?という疑問があり、じゃあ、Marshal.FinalReleaseComObjectを呼び出せばどうだ、いや、それを呼び出すと挙動がおかしい、などの説があって、試しました。
using ATLSampleLib; class Program { static void Main(string[] args) { var testClass = new TestClass(); testClass.TestProp = "ABCX"; Console.WriteLine(testClass.TestProp); Marshal.FinalReleaseComObject(testClass); } }
ATL側では、インスタンスの寿命が尽きる時(参照カウンタが0になったとき)、FinalReleaseメソッドが呼び出されます。ここにブレークを張ってテストしたのですが、やってこない…
FinalReleaseComObjectの代わりにGCを手動実行したらどうだろうと言う事でテスト:
using ATLSampleLib; class Program { static void Main(string[] args) { var testClass = new TestClass(); testClass.TestProp = "ABCX"; Console.WriteLine(testClass.TestProp); GC.Collect(2, GCCollectionMode.Forced, true); GC.Collect(2, GCCollectionMode.Forced, true); GC.Collect(2, GCCollectionMode.Forced, true); } }
すると来ましたFinalRelease。うーむ、FinalReleaseComObjectとは何なのか? これだとインターフェイスポインタを直接弄った方が安心感があるよなぁと思わなくもない(真相は分からず)。
もう一つ気が付いたことが。FinalReleaseでブレークを張ったところ、スタックトレースがこのように。
これワーカースレッドから呼ばれてるよね、何でだ?と思ったらMainメソッドに、STAThread属性を付けていなかった。
で、STAThreadを追加したところ、無事にメインスレッドから呼び出された(このCOMコンポーネントがワーカースレッドから呼び出されること自体に問題はないんですが、一瞬えっと思ったので気が付いた次第)。
# しかし、このスタックトレースも大概だなぁ。当然こうなる事は予測できるんだけど…
さて、これの何が問題かと言う事は、やっぱりアパートメントの話に踏み込まないと説明できないよね。と言う事で、そろそろ参加者の意識共有も出来たので、アパートメントを話をし始めました。
アパートメントとは何なのか?
アパートメントとは、スレッドとCOMのインスタンスをグループ分けする概念で、そのグループとは何なの?というディスカッションをしました。グループの種類は「STA(シングルスレッドアパートメント)」と「MTA(マルチスレッドアパートメント)」の二種類(あと、概念的にはメインSTA)があります。
アパートメントの概念が難しいのは、用語の説明から入らざるを得ないからかなーと思います。このような図が一般的に説明に用いられますが、内部実装的にこうなっているわけではなく、あくまで概念的に分割される、という事も、難解なところかなと。混乱すると良くないので、内部もこの通りになっていると仮定してもいいんじゃないかと思います(実際は違うって事が分かるようになったら、もう説明も不要になってるはず)。
シングルスレッドアパートメント
一つのスレッドだけが特定のSTAに属します。新たなスレッドを作り、STAに属させると、図の通り新しいSTAが作られます。メインスレッドがSTAとなった場合は、特別に「メインSTA」と呼びます(実際には、プロセス内で最初にSTAとして初期化されたスレッドです)。スレッドをSTAに属させるには、CoInitializeEx APIを実行します。.NETの場合は、メインスレッドであれば、Mainメソッドに「STAThread属性」を適用し、ワーカースレッドを作る場合は、Thread.SetApartmentStateメソッドで指定します。
図のように、STAは他のアパートメントと(概念的に)分離されており、そこに属するスレッドやインスタンスは、別のアパートメントから直接参照することが出来ないという原則に従います。
マルチスレッドアパートメント
MTAは、プロセス内にただ一つだけ存在します。そして、MTAに属するスレッドは複数存在できます。スレッドをMTAに属させる方法も、STAとほぼ同等です。Mainメソッドに適用する場合は、「MTAThread属性」を使用します。
STAとアパートメント間の特性
STAとMTAの最大の違いは、STAは「ウインドウメッセージキュー」に依存していると言う事です。今までのCOMの説明にはウインドウとかコントロールのようなユーザーインターフェイスの話は全く出て来なかったので、「えっ」てなってました。
ここで説明の順序を逆にして、遠い昔、Win16(つまりWindows 3.1以下)の頃は、マルチスレッド対応がそもそも無く(_beginthreadex APIとか存在しない)、すべての操作を非同期的に処理するためには、メッセージポンプにメッセージを配信する形で協調的に動作させる(ノンプリエンティブマルチタスク)必要がありました。
この頃に作られたアプリケーションは、マルチスレッドのように横から突然割り込まれてメソッドが実行されるような事を全く想定していません(スレッドがそもそも存在しないので)。今でいうところのモニターロックや排他制御がまったく不要だったのです。そのため、マルチスレッド環境で別のスレッドからこのような実装を呼び出すと、容易に破たんします。そして、現在のユーザーインターフェイスも全く同様の構造なのです。
つまり、異なるスレッドからウインドウ要素を操作したりする場合は、すべからく安全策をとる必要があります。WPFであればDispatcherを使う、Windows FormsであればInvokeメソッドを使って簡単に呼び出しの「マーシャリング」を実行できます。しかし、COMが考案されたころには、そのような強力な道具立てがなかったのです。
更に、既存のマルチスレッド非対応コードがバイナリライブラリとして「変更不能」な状態で存在するため、互換性も担保する必要があります。この問題をフレームワーク(COMランタイムライブラリ)で隠蔽し、どうにかして安全性と実装の軽減を両立させたかったのだと推測されます。
STAがウインドウメッセージキューに依存しているとは、STA内のCOMコンポーネントインスタンスを操作する場合は、このキューに一旦要求(メソッド呼び出し情報)を格納し、「協調的」に処理させると言う事です。
勿論、STA内のスレッドであれば、同じSTA内のインスタンスは、キューを介することなく操作できます。勿論、メソッド呼び出し結果の返却も、キューに一旦結果を格納して受け取ります。このときのキューは、呼び出し側のキューを使います。
このように、ウインドウメッセージキューを介在させることで、ウインドウメッセージ(ウインドウの移動やリサイズ・ボタンのクリック・テキストの変更など)にいきなり割り込むことなく、順番に規則的に実行されるので、マルチスレッド競合について考えなくても良くなる、というのが、STAに属する利点となり、同時に高いオーバーヘッドが欠点となります。
ところで、STAとMTA間で呼び出しを処理する場合は、呼び出し側がMTAであれば、呼び出し時はSTAのキューを使いますが、処理結果はキューに入らず、直接元のスレッドに伝達されます。逆であれば、呼び出しがキューに入らず、結果は一旦キューに入ります。
これは、MTAは特定のウインドウメッセージキューに紐づく事がないからです。したがって、ユーザーインターフェイスを含むCOMコンポーネントをMTAに属させると、クラッシュするなどの予期しない結果を引き起こします。
そして、MTAには複数のスレッドが同居出来て、MTA内のCOMインスタンスはすべて介在される事なく直接呼び出しが成立するので、ほぼコスト0で高速にメソッド呼び出しが行われます。これが、IISにホストされるCOMコンポーネントをSTAではなくMTAで動作させなければならない理由です(MTAにするとパフォーマンスが向上するらしい、という理由で、背景を考えずにMTAに属させるコードを書くと、間違いなくハマります)。
COMインスタンスはどこのアパートメントに配置されるか
あるアパートメントに属しているスレッドがCOMコンポーネントのインスタンスを生成(CoCreateInstance API)すると、コンポーネントに指定された属性に従って、インスタンスが配置されるアパートメントが変わります。再びATL COMオブジェクトウィザードのスクリーンショットですが、ここで、「スレッドモデル」を選択可能です。
このスレッドモデルの選択と、現在のスレッドがどのアパートメントに属しているのかによって、配置されるアパートメントが決定されます。昔、この組み合わせの表をどこかで見た記憶があるのですが、改めて書き出してみました(ただし、すべて検証しているわけではないので、間違っているかもしれません)。
メインSTA | STA | MTA | |
シングル | メインSTA | メインSTA | メインSTA |
アパートメント | メインSTA | STA | STA |
両方(Both) | メインSTA | STA | MTA |
フリー(Free) | MTA | MTA | MTA |
ニュートラル | メインSTA | STA | MTA |
この表を眺めていると、何を選択すべきかが見えてきます。
- ユーザーインターフェイス(ウインドウメッセージを必要とする)を含むコンポーネントであれば、「アパートメント」を選択する。これには、俗に言う「ActiveXコントロール」も含まれます。
- その中でも特にメインスレッド(メインSTA)でのみ動作可能なコンポーネントであれば、「シングル」を選択する。
(今やこのようなコードは想像しにくいかもしれません。例えばグローバル変数に状態を持っていて、これを操作しているようなUIコンポーネントは、多分メインSTAでしか動作しません) - アパートメントの影響を受けないコンポーネントであれば、「両方」又は「ニュートラル」を選択する。
- MTAにのみ必ず属させ、ハイパフォーマンスでローコストな環境を必要とするコンポーネントであれば、「フリー」を選択する。
再度確認したのが、MTAに属させたからと言ってハイパフォーマンスになるわけではなく、マーシャリングコストを最小化可能であることがミソなので、ここで不用意に「フリー」を選択すると、アパートメントの選択同様ドツボにはまる事に注意が必要です。
一番無難な選択肢が「両方(Both)」ですが、表の上では「ニュートラル」も同じとなっています。両方とニュートラルの違いは、両方とすると、メインSTA・STA・MTAのどこにでも配置出来るものの、配置されるとそのアパートメントに完全に紐づきます。対して、ニュートラルとは、本当のところは「どのアパートメントにも属さない」状態となります。この違いは、マーシャリングの動作に影響します。
マーシャリングとは
アパートメントの話は抽象的なので、もう少し実装に近寄ります。
アパートメントの境界を超えるために、COMのランタイムによって「プロキシ・スタブ」という一種のファサードが自動的に介在し、メソッド呼び出しを自動的にメッセージキューに保存し、目的のSTAのスレッドでこれを取り出して実行する、という処理を行う事を説明しました。一般的にこのような操作を行う事を「マーシャリング」と言います。
マーシャリングは、カスタム「プロキシ・スタブ」コードで完全に独自の実装を行うか、あるいは「COMスタンダードマーシャラー」を使うかを選択できます。正直カスタムマーシャラーは深くて闇で資料も少なく、これを自前で実装する事は殆ど無いと思います。
どちらにしてもこの図のように、アパートメント境界の間に入って、メッセージキューの操作をしたり、スタックを操ってリモートメソッド呼び出しを成立させる役割を担います。呼び出し元は、カスタムマーシャラーが「何故か」目的のインターフェイスを実装したインスタンスに見えるので、アパートメント内呼び出しと全く同じように、インターフェイスメソッドを呼び出す事が出来ます。
# IUnknown.QueryInterfaceメソッドは、インターフェイスIDを受け取って、そのインターフェイスへのポインタを返します。と言う事は、COMスタンダードマーシャラーが、実際には実装を用意していなかったとしても、IID_ICalcのようなインターフェイスIDが存在して、キャストも成立させたように見せかければ、この状況を作り出す事ができます。返されるインターフェイスポインタは、ICalcを動的に実装したスタブクラスです。
さて、このマーシャラーが一体いつ挿入されるのかが、背景を知っていないと分からないと思うため、その説明をしました。
インスタンス生成時
CoCreateInstance APIでインスタンスを生成するとき、呼び出し元のスレッドが属するアパートメントと、COMコンポーネントに指定された「スレッドモデル」に応じて、インスタンスが配置されるアパートメントが決定されます。では、呼び出し元スレッドのアパートメントと異なるアパートメントにインスタンスが生成され、配置された場合、呼び出し元はどうやってそのインスタンスにアクセス出来るのか?
答えは、CoCreateInstanceが返すインターフェイスポインタが、「既にCOMスタンダードマーシャラーなどのファサードを示している」ので、呼び出し元は何も考えなくても良い、と言う事です。
この図のように、MTAのワーカースレッドは、CoCreateInstanceが返すインターフェイスポインタを、本物の「ICalc」を実装したインスタンスだと思い込んでいます。しかしその実態はマーシャラーであり、ICalcのメソッドを呼び出すとマーシャラーのメソッドを呼び出し、後は前述のとおり、マーシャリング動作が行われます。
インターフェイスポインタの自動伝搬時
内部的にはここが難しい所で、一度マーシャラー経由のインターフェイスポインタを取得した後は、メソッド呼び出し引数や戻り値にインターフェイスポインタが含まれていれば、マーシャラーが自動的にそのインターフェイスポインタにもマーシャラーを挿入します。
// 呼び出し元の例: IHogeService* pHogeService = ...; // 例えば、戻り値がインターフェイスポインタの場合 IResultData* pResultData = nullptr; pHogeService->GetResult(&pResultData); // (pResultDataは何を指しているか?)
GetResultメソッドの戻り値がIResultDataという、別のCOMコンポーネントインスタンスへのポインタである場合、その実態は呼び出し先のアパートメントに存在する可能性が高いです(必ずと言うわけではない)。
その場合、戻り値として返されるインターフェイスポインタは、あくまで呼び出し先のアパートメントのインスタンスを示しているので、それがそのまま呼び出し元に返されても、その後が困ります(そのまま使うとマーシャリングが行われないので、アパート境界が守られず、酷い問題が発生する)。
そのため、スタンダードマーシャラーは、戻り値のインターフェイスポインタを「マーシャリング」し、新たなマーシャラーを割り当て、マーシャラーのインスタンスへのポインタを呼び出し元に返却します。
呼び出し元がIResultDataのメソッドを呼び出すと、裏ではマーシャラーを介してインスタンスを操作することになり、安全性が担保されます。呼び出し元はIResultDataがマーシャラーである事は知る由もなく、直接呼び出しているのと変わりません。
さて、これを実現するには、引数や戻り値に「インターフェイスポインタが含まれているかどうか」を認識出来なければなりません。CやC++のソースコード上では、インターフェイス型を指定するので(人間の目には)判別できます。しかし、コンパイル後のバイナリには、型情報が含まれないため、自動的に検出する事が出来ません。COMスタンダードマーシャラーが、ノーメンテで動作するには、型の自動判別が可能である必要があるのです。
方法は2つあります。一つは、インターフェイス型のメタデータをタイプライブラリ(*.tlb)として読み取り可能になるようにファイルを配置するか、リソースとしてDLLに埋め込み、「プロキシ/スタブデータ」を提供することです。これにより、COMスタンダードマーシャラーは、引数や戻り値の型情報にアクセスし、それがマーシャリングの対象である事を認識できます。
もう一つは、同じくタイプライブラリを提供する必要がありますが、引数や戻り値の型にVARIANT型を使う事です(プロキシ/スタブデータは不要)。VARIANT型は、格納できるサブタイプを指定して値を格納します。サブタイプの種類にハードコーディングされた制限がありますが、基本的なプリミティブ型やインターフェイスポインタなどを含むことが出来、何が含まれているのかを検知出来ます。但し、VARIANT型を使うと、タイプセーフ性は低下します。
# もちろん、カスタムマーシャラーを書いた場合は、自分でマーシャリングを行うため、タイプライブラリの準備やVARIANT型への依存は不要です。また、IDispatchインターフェイス経由でのみ公開されるメソッドの場合は、すべてVARIANT型である事を想定可能なので、タイプライブラリは不要です。
インターフェイスポインタの手動伝搬時
自動マーシャラーを全く介さないというソリューションもあります。一つは「フリースレッドマーシャラー(FTM)」を集約する事です。詳細は省きますが、この場合はマーシャリングを自分で面倒見なければなりません。もう一つが、スレッドモデルを「ニュートラル」とした場合です。この場合もマーシャリングは自分で面倒を見る必要があります。
マーシャラーを全く介さないと、メソッド呼び出しはダイレクトにCOMインスタンスのメソッドを呼び出す事になります。当然、引数や戻り値に渡されるインターフェイスポインタも生ポインタであるので、アパートメントの境界を越えてアクセスして良いかどうかは全く分かりません。
そのような場合に自分でマーシャリングを実行する必要がありますが、2つの方法があります。
- CoMarshalInterThreadInterfaceInStream APIを使って、インターフェイスポインタを抽象的なデータに変換しておき、目的のアパートメントスレッドで、CoGetInterfaceAndReleaseStream APIを使って、安全なインターフェイスポインタを取得する。 #名前を思い出すのが大変だった (;´Д`)
- グローバルインターフェイステーブル(GIT)を使う。
APIやGITを使うと、インターフェイスポインタを再取得したときに、マーシャリングが必要だと判断されれば、マーシャラーが生成されて、マーシャラーへのポインタが返されます。不要と判断されると、直接COMコンポーネントインスタンスへのポインタが返されます。
# 回り回って元のアパートメントでインターフェイスポインタを取得すると、ちゃんと再計算されて、生ポインタが取得できた、ハズ…
現在ではGITを使う方が簡単です。特にATLを使う場合は、CComGITPtrクラスを使うと、非常に簡単にマーシャリングを行うことが出来ます。GITで言うところの「Cookieデータ」が、APIを使う場合の抽象的なデータに相当します。
何故、FTMやニュートラルというオプションがあるのかと言うと、お互いのCOMコンポーネントが何であるかが確実で、お互いに共謀出来るのであれば、異なるアパートメントであろうが、直接生ポインタを操作しても問題ない(と分かっている)はず、という非常に厳しい制約の元でマーシャリングコストを0にすることも出来る、ということです。つまり、ただでさえ複雑なスレッドモデルを正しく理解する必要があるので、FTMやニュートラルを使う事は、よほどの理由がない限り避けた方が良いと言えます(せっかくCOMのランタイムが色々頑張ってくれる機能を放棄することに近しいです)。
DCOMへの拡張
ここまで見てきたアパートメントとマーシャリングの話が分かれば、「DCOM(Distributed COM)」は、延長上の技術でしかない事がわかります。
- 今までの話は、プロセス内でのアパートメント境界を超える場合のマーシャリング処理ですが、
- プロセス間通信にも応用できますね?(アウトプロセスCOMサーバー・サービス)
- プロセス間通信が出来るなら、マシン間でも通信できるよね?(DCOM)
DCOMとは、要するにそういう事です。勿論、マシン境界をまたぐ場合は、セキュリティのトピック(認証と認可をどうするかなど)が存在しますが、基本は全く変わりません。
COMの将来展望(クロージング)
時間が押してきたので、ほかにもトピックはあるのですがクロージングに入りました。
今回、主題として「All about COM」と銘打ったのですが、実は「隠された副題」がありました。それは、「COM requiem」です。COMの全盛期は2000年頃(つまりもう15年も前)と思っているのですが、まだまだいたるところで使われており、すぐにomitすることは当面出来そうにありません。しかし、プログラミング環境は完全に.NETが主体となり、C++でコードを書く際も、ライブラリのインフラとしてCOMを選択すると言う事は殆ど無くなりました。
自分なりの答えはあったのですが、「何故COMは失敗したのか」あるいは「何故COMは継続してメジャー足り得なかったのか」と言う事を、参加者に聞いてみたかったのです。
意見としては:
- 設計思想は凄かった。特に「コンポーネント指向」として、処理系依存の排除やバイナリ互換性を維持する方法論、スレッド安全性をランタイムで担保する抽象性の高さ。
- 「インターフェイス指向設計」に根差している。COMは実態のクラスに一切タッチしないので、インターフェイス分割設計と言う事に強く意識させられた。
- やっぱり複雑すぎた。時代が早すぎた。複雑性を軽減する開発環境の補助も、現在と比べて全く不足していた。
- .NETで複雑な処理も簡単に実装できるようになったので、相対的にCOMのランタイムが複雑に見えるようになった。
- アパートメントという抽象性の高い概念が理解できなくて躓く。
- COMを正しく実装するのが大変。VB6か、スクリプトコンポーネント(VBSやJSをCOMコンポーネントとして実行可能な、今考えるとやはり早すぎた感のある技術)でないと辛い。
これだけ複雑であるにも関わらず、COMを知っていて良かったと思える事として、やはり「インターフェイス」を強く意識する事になったことが、数人の意見で一致しました。この経験が、現在の.NETのインターフェイスや、ウェブシステムでのAPI設計の粒度やさじ加減と言った点にとても役立っています。
これは、COMのインターフェイスがほぼ最小のメソッドレベルの粒度で公開可能で、しかもDCOMによってマシン間のRPC呼び出しへの簡単にスケールアップ出来るにも関わらず、その細かい(Chatty)呼び出しが、システムのパフォーマンスと安定性に問題を起こす事が経験として理解できたと言う事です。
なので、COMはとても良い経験を与えてくれた良き技術・通過点でした。そろそろ卒業の頃だと思います。
個人的な思い
このブログでも、COMの解説を試みた記事を書いています(未完)。
COMのアパートメント (1) スレッド同期の隠蔽
COMのアパートメント (2) コンポーネントファサード
COMのアパートメント (3) スレッドの属性とコンポーネント
COMのアパートメント (4) スレッド親和性
COMのアパートメント (5) CoInitializeExは初期化ではない
COMのアパートメント (6) アパートメントの種類はどのように決まるのか
これが未完となっていたのと、内容としてこなれていないのが、ずっと喉の奥に引っかかっていたのです。今回のChalkTalkで完全に咀嚼して、完了させたかった。その目的は達成できたかなと。やってよかったなと思います。
COMは愛すべき対象でしたね。「ナナリィ…」って感じです。
次回もよろしくお願いします!
追記
ここで扱っていない、COMの重要な要素として以下のものがあります。メモとして残しておきます。
- インターフェイスの集約(Aggregation)
- IDispatchインターフェイス・スクリプティングサポート・イベントソースインターフェイス
- モジュール生存期間の管理(ATLを使うなら、自動でやってくれる)
- フリースレッドマーシャラー(FTM・FTMを集約すると、ニュートラルスレッドモデルと同じように振る舞える)
- モニカ(IMoniker)
- 情報管理(IStorage・IStream・IPropertyBag)
- インターフェイスポインタのキャッシュや動的生成
- ActiveX Controlとは
- COM+とステートレス設計