(追記:2020/5/26)

COMについて、細々とですがこのページに誘導されてくるのが分かっています。もっとわかりやすく包括的に書いたページがありますが、残念ながら、なぜか検索エンジンのレートから外されているため、ここで案内しておきます。「ChalkTalk CLR – COMのすべて」 を最初に見ることをお勧めします。

ずいぶんご無沙汰になってしまった。未だにCoInitializeExとかRPC_E_CHANGED_MODEで検索してくる方が絶えないので、少しだけ続きを書く。

前回、アパートメントの種類は、ライブラリの呼び出し元（正確にはスレッドを生成したコードの設計者）が知っているはずと述べた。だが、現実には、STAとMTAのどちらを使用すべきか、はっきり分かっていない開発者が多いと思う。
また、STAは重く、MTAにすれば軽いと、「まことしやかに」ささやかれていたりもする。もっと印象的なのは、「マルチスレッド」だからというものだ。

CoInitializeExでSTAかMTAを指定する事の他に、スレッドにアパートメントを指定する「意味づけ」がある。以下にこれらをまとめる。

• STA – シングルスレッドアパートメント
  あるスレッドがCoInitializeExでSTAに設定した場合、そのスレッドはウインドウのメッセージループを持つと仮定する。つまり、そのスレッドが実行するコードの中核には、GetMessage・TranslateMessage・DispatchMessageによるメッセージループが存在する（しなければならない）。
  これは、極々一般的なWin32アプリケーションのメインスレッドの要件となる。同時に、例えワーカースレッドであっても、その中核がメッセージループで構成されているならば、STAとして設定する必要がある。
  もし、無理やりMTAとする場合、非常に難しい問題を自力で回避しなければならず（ウインドウメッセージとインターフェイス呼び出しの手動マーシャリング）、それが不可能な場合もある。通常はそのような事をする意味はない。
• MTA – マルチスレッドアパートメント
  あるスレッドがCoInitializeExでMTAに設定した場合、そのスレッドにSTAのようなメッセージループの要件は不要となる。しかし、これは同時に、ウインドウメッセージとの連携は「全くない」と仮定する事と同じである。
  自分がウインドウメッセージと関連が無い（それどころか、ウインドウと関連が無い）と決めてかかるのは危険だ。そのスレッドが、あらゆるユーザーインターフェイスを、「直接的」ないし「間接的」に操作していないと確信できるなら、MTAを使用する事が出来る。これは、特に自分が書いていないサードパーティのコードを流用する場合は難しい。
• メインSTA
  これはプロセスのメインスレッドがSTAに設定されている場合に、特にその状態を言う。コードの中には、メインスレッドでのみ操作可能な、特別な位置づけのAPIや変数などが存在する場合がある（つまり、例えSTAでも、ワーカースレッドからは操作してはならない、など）。これらを「メインSTAに紐づけられている」、と擬似的に考える。

スレッドにSTAを設定すると、スレッド毎に独立したSTAに所属する。つまり、スレッド＝STAとなる。複数のスレッド（メインスレッドやワーカースレッド）が、それぞれCoInitializeExでSTAに設定されると、STAの部屋がそのスレッドの個数用意され、それぞれのスレッドがそれぞれのSTA部屋に入ることになる。

これに対して、スレッドをMTAに設定すると、プロセス当たりたった一つのMTA部屋に、MTA設定されたスレッドが同居する。STAはn個存在する可能性があるが、MTAは常に一つとなる。そして、STAのうちメインスレッドが入ったSTAにのみ、メインSTAという名前がついていると考えればよい。

で、これが何の役に立つのかと言う事だが、スレッド同士が会話したい場合（あるスレッドが、別のスレッドにあるCOMのインスタンスのメソッドを呼び出したりする）、この擬似的な「部屋」によって挙動が変わることになる。

例えば、STAスレッド同士が会話する場合、相手のスレッドは別のSTA部屋に存在する（一つのスレッドには一つのSTA部屋が割り当てられるから、必ず別のSTA部屋になる）。すると、会話（メソッド呼び出し）は、ファサードとなるインターフェイスを経由しなければならない。COMの抽象化された世界では、メソッド呼び出しが直接成立しているように見えるが、実際には部屋が遠いので、秘書が電話でやりとりしているようなイメージだ。

物理的にはどうだろうか。それぞれのスレッドは両方ともウインドウメッセージのループを持っている。また、ウインドウメッセージの動作を邪魔すると困るので、お互いのスレッドに関与する場合はPostThreadMessageを使って、メッセージキューに内容を放り込むのが良いだろう（秘書に伝言する）。
時期的に都合がよくなる（ウインドウメッセージに同期）と、そのメッセージが取り出されて（秘書が社長に伝達）、「送り先のスレッド」で処理が実行される。返信も同様だ。元のスレッドのメッセージキューに結果が放り込まれ、元のスレッドの都合が良い時にとり出され、「送り元のスレッド」で処理が継続する。

この挙動が、一般的にWin32でワーカースレッドを生成して、時間のかかる処理をウインドウ処理から外だしした時と殆ど同じに見えるだろうか？ 俯瞰して眺めるなら、STAとして設定することで、面倒なスレッド間メッセージングを隠ぺいして、RPCライクに呼び出し出来るようになると言う事だ。

だから、STAは「重い」のだ。

しかし、STAが重いからという理由だけでは、MTAに設定することは難しい。MTA同士の呼び出しでは、秘書も電話も存在しない。MTA部屋は一つしかない。その部屋の中で、社長が隣り合う席で直接話し合うようなイメージだ。ネイティブコードにおけるstd_callによって、直接メソッドが呼び出される。通常のプログラミングにおける「メソッド呼び出し」と完全に等価だ。それはすなわち、ウインドウメッセージやウインドウとの同期を一切行なわないと言う事だ。

仮にメッセージループを持つスレッドが、別のスレッドで生成されたCOMインスタンスのメソッドを直接呼び出した場合、メソッドは呼び出し元のスレッドで実行される。その結果、インスタンスが保持するウインドウハンドル（当然、別のスレッドに紐づいている）を、呼び出し元のスレッドが直接使用してしまうかもしれない。動作は予測不可能なものになる。

また、COMコンポーネントには、アパートメント属性の指定が無いものがある。このコンポーネントは、STAで生成される事を想定しているため、コンポーネント内でスレッド競合を特に考慮していない。MTAで生成すると、COMのインフラによって自動的にファサード（秘書通話に相当）が生成され、スレッド競合が回避される。

そのため、仮にだが、アパートメントを無視したような呼び出しを実行した場合（アパートメントを適当に設定すれば、結果的にそうなる可能性がある）、つまり、STAで生成されたこのようなインスタンスが、別のSTA/MTAからファサードの介在なく直接呼び出されたり、このインスタンスがコールバックすると、ウインドウメッセージの同期破綻はもちろん、ウインドウAPIの無効な呼び出し、スレッド競合による変数の破壊などの深刻な問題が発生する。

#以上の説明には、アパートメント設定の問題の他にも、プログラミング上の問題が含まれているが、そちらについては
#長くなるので、別の機会に。

この事を理解すれば、意味も分からずアパートメントを適当に設定するというのが、いかに危険か分かると思う。背景の理解は大変だが、判断の基準はシンプルで難しくない。

• スレッドで行われる操作が、ウインドウやウインドウメッセージに及ぶ可能性がある場合（特にメッセージループを内包する場合）は、STAとして設定する。
• それ以外であればMTAとすればパフォーマンスが向上する可能性があるが、心配ならSTAとして設定してもよい。
• スレッドを生成したら、即アパートメントを設定する事。
• COMインスタンスを操作する可能性が（直接的にも、間接的にも）完全にゼロである場合は、アパートメントを設定しなくて良い（CoInitializeExを呼び出す必要はない）。

.NETでコードを書いているのであれば、想像してほしい。Windows FormsならControl.Invoke、WPFならDispatcherを使いたくなる状況かどうかと同じ判断を、アパートメントに対しても行えば良い。これは、結局前回最後に書いた通り、これらのフレームワークのウィザードが生成するコードが「STAThread」とマークされ、メソッド呼び出しにマーシャリングを必要としていることに符丁するわけだ。

パフォーマンスが気になるというのなら、何が問題でSTAは遅いのか、と言う事を考えると答えが得られる。つまり、メソッド呼び出し（メッセージループにメッセージをポストしてやり取りする）にコストがかかることが問題なのであり、頻繁な呼び出しを避ければ良いのだ。プロパティを何度も参照したり、細かいメソッドを何度も呼び出したりすることを避けることで、一般的な使い方であればそうそう困ることはない。

COMコンポーネント側を設計するのであれば、頻繁なメソッド呼び出しを避けることができるように、拡張されたインターフェイスを設計しておくとよい。例えば、すべてのプロパティの値をまとめて取得・設定出来るようなメソッドや、バルク実行できるメソッド等が考えられる。

そして、COMインスタンスの操作を全く行わないのであれば、CoInitializeExを呼び出す必要はない。アパートメントの設定によって、STAならばウインドウメッセージキューが生成されてしまうし、MTAなら図中のスタックビルダーやインフラの準備でスレッドローカルストレージを消費するだろう。

例えば、素のWin32アプリケーションを作る場合、通常はCoInitializeExを呼び出したりはしない。しかし、ウインドウがActiveXコントロールを内包したり、WMI COMインターフェイスを使ったりするなど、直接的・間接的にCOMインスタンスを操作する可能性が生じれば、CoInitializeExでアパートメントを設定しなければならない。しかも、スレッドのエントリポイント（メインSTAなら、WinMain）の出来るだけ早い段階で、だ。

そして、ここが難しいところだが、アパートメントを設定しないのであれば、「間接的にも使われていない」と言う事を確認しておくことが重要だ（だから、心配ならSTAに設定する事をお勧めする）。

.NETのワーカースレッドで、スレッドのアパートメントを殆ど意識しないのは、COMインスタンスを.NETで操作する機会が（一般的には）あまり無いからだ。必要なければ、アパートメントを設定する必要もない。

(追記:2020/5/26)

COMについて、細々とですがこのページに誘導されてくるのが分かっています。もっとわかりやすく包括的に書いたページがありますが、残念ながら、なぜか検索エンジンのレートから外されているため、ここで案内しておきます。「ChalkTalk CLR – COMのすべて」 を最初に見ることをお勧めします。

さて、そろそろ架空のコードでは現実とどう違うのかわからなくなってくるので、現実のコードがどうなるのかを見ていくことにする。
COMで最初にお世話になるのは、CoInitializeとCoInitializeEx、CoUninitialize APIだ。
前回までの解説からなんとなくイメージを持ってもらえたかも知れないが、これらのAPIは、現在のスレッドにアパートメント属性を設定・解除する。
CoInitializeはCoInitializeExのバリアントなので、CoInitializeExで説明する。
CoInitailizeEx API

HRESULT hr = CoInitializeEx(0, COINIT_MULTITHREADED);

// COMに関する様々な処理...

CoUninitialize();

CoinitializeExの第一引数は使われていないので0（ないしNULL）を指定する。
第二引数は、初期化フラグを指定し、COINIT列挙値の値を使用する。ほとんどの場合、ここにはCOINIT_MULTITHREADEDかCOINIT_APARTMENTTHREADEDのどちらかを指定する。
COINIT_MULTITHREADEDにした場合、現在のスレッドのアパートメント属性として、MTA（マルチスレッドアパートメント）に属するように設定する。
COINIT_APARTMENTTHREADEDにした場合、STA（シングルスレッドアパートメント）に属するように設定する（そして、CoInitializeを使用すると、STA固定となる）。

マルチスレッドアパートメントに設定すると、そのスレッドは、COMコンポーネントとのやり取りで発生するすべてのスレッド同期作業を、自分で行うと宣言したことになる。
シングルスレッドアパートメントに設定すると、そのスレッドは、COMコンポーネントとのやり取りで発生するすべてのスレッド同期作業を、COMが背後で面倒見てほしいと宣言したことになる。

これらの違いについては次回に譲る。

これでCOMに関する下地が出来た訳だが、巷のコードを見ているとアパートメント選択以前の勘違いが多いことに気が付く。つまり、このAPIの呼び出しは、呼び出し元のスレッド（カレントスレッド）に対してアパートメントの設定を行うのであるが、まるでプロセスワイドにCOMの初期化が行われているかのような使い方だ。

たとえば、DLLによるライブラリを作成していたとする。このDLLは外部に以下のような公開エントリポイントを持つとする。

__declspec(dllexport) HRESULT __stdcall InitializeLibrary();
__declspec(dllexport) HRESULT __stdcall DoSpecialMakeMoney(const ULONG multiply);
__declspec(dllexport) HRESULT __stdcall TerminateLibrary();

このライブラリを初期化するには、InitializeLibraryを呼び出す。内部の実装（DoSpecialMakeMoney）では別のCOMコンポーネントを呼び出す予定なので、InitializeLibrary内でCoInitializeExを呼び出している。しかし、InitializeLibraryを呼び出したスレッドと、DoSpecialMakeMoneyを呼び出したスレッドは別のスレッドかも知れない。同じく、TerminateLibraryもまた、別のスレッドである可能性がある。

すると、CoInitializeExやCoUninitializeを呼び出す事は何の意味をも持たなくなってしまう（CoInitializeExは、「現在のスレッド」にアパートメントを「設定」するのだから）。

それどころか、InitializeLibraryを呼び出した時点で、すでにCOMの初期化が行われているかもしれない。しかもその時点のスレッドは、STAであるべきか、MTAであるべきかは、呼び出し元のみぞ知るわけであり、ライブラリの中では知りようがない（無理やり変更を試みると、RPC_E_CHANGED_MODEが返される）。

仮に、InitializeLibrary内でCoInitializeExのエラーコードを適切にハンドリングしたとする（RPC_E_CHANGED_MODEのほかにS_FALSEが返される可能性がある。これはすでに同じアパートメント属性で初期化されていることを示す）。これでエラーは回避できるかもしれないが、そもそも呼び出し元のスレッドはCOMの初期化を行っておらず、InitializeLibrary呼び出しの「後」で、自力でCoInitializeExを呼び出していたとしたらどうだろうか。その実装には関与できないかもしれず、従ってここで示したようなエラーの回避が行われているかどうかわからず、結局のところ、必要とされる正しいアパートメント属性に設定できたのかどうかもあやふやだ。

つまり、このようなコードは完全な「お手付き」と言える。最も、COMの初期化を行ってあげようという親切心は分からなくもないが…

堅牢なライブラリに仕上げるためには、まず、独自にCoInitializeEx（とCoUninitialize）の呼び出す事を止めることだ。また、CoInitializeExが呼び出されていない場合は、DoSpecialMakeMoneyの呼び出しに対して、COMの初期化が行われていない事を示すCO_E_NOTINITIALIZEDを返す（あるいはカスタムのエラーコードや、C++かつ環境限定なら例外をスローしても良い）。

CoInitializeExが呼び出されているかどうかは、COMの何らかのAPIを呼び出せばわかる。つまり、DoSpecialMakeMoneyの内部で実際にCOM APIを使用した時点でCO_E_NOTINITIALIZEDを検出し、異常処理を行えばよい。
また、呼び出し元のコードを記述する際は、スレッドを生成したら、速やかにCoInitializeExでアパートメント属性を確定しなければならない。生成したスレッドがどのアパートメントに属するのが適切なのかは、スレッドを生成した者にしかわからないからだ。

＃筆者は過去にこのような不適切な実装を行っている、サードパーティ製のコンポーネントを目撃した。
＃実際に業務に使用していたため、非常に困り、最終的にはサードパーティに「直させた」経験があるが、問題が解消するまでに、結局3か月近く掛かった…
＃（技術的な問題点をお客様に理解してもらい、さらにサードパーティベンダーにも周知してもらい、修正され、解消されたことを確認するまでに掛かった時間）
＃ベンダーは技術の内容をよく理解して使ってほしいと思う。

.NETのメインエントリポイントが、[STAThread]や[MTAThread]属性を使ってアパートメントを簡単に指定できるようにしているのは、このような理由によるものと推測している。実際、Windows FormsやWPFアプリケーションをウィザードで生成すると、自動的に[STAThread]が適用される。

勿論、属性を指定していなくても、Thread.CurrentThread.SetApartmentState()を呼び出せば設定できる（内部ではおそらくCoInitializeExを呼び出しているのであろう）が、アパートメント初期化のベストプラクティスは、スレッド生成と同時に設定してしまうというものだ。

(追記:2020/5/26)

COMについて、細々とですがこのページに誘導されてくるのが分かっています。もっとわかりやすく包括的に書いたページがありますが、残念ながら、なぜか検索エンジンのレートから外されているため、ここで案内しておきます。「ChalkTalk CLR – COMのすべて」 を最初に見ることをお勧めします。

前回までの内容で、COMが裏で何をしているのか、少し見えたような気がすると思う。
ここで重要な「嘘」を公表しなければならない（大げさか）。

今まで、ファサードが存在する理由としてスレッド同期を挙げたのだが、そのこと自体は間違っていないのだが、同期の対象が違っていた。
コンポーネントの「単一のインスタンス」について同期を行うために、ファサードを挿入すべきか否かという話だったのだが、実はそうではない。

本当のCOMでは、同期の対象は「ウインドウ」である（ほぼ）。
Win32 APIの生の呼び出しで、一からウインドウを生成するコードを書いたことがあれば、これは自明である。ウインドウにまつわるAPIの大半は、対象とするスレッドを限定する。

たとえば、Visual C++で、新しくWin32のプロジェクトを開始してみてほしい。ひな形として生成されるCのコード（微妙にC++だが）は、Win32 APIの直接呼出しの、懐かしい、目を背けたくなるコードだ。そのコードには、CreateThreadや、beginthreadexのような、スレッド生成のAPI呼び出しは存在しない。つまり、このコードは「シングルスレッド」で実現されている。

実行すると、単一の味気ないウインドウが表示される。一通りの操作が可能である。ウインドウが生成されると、「ウインドウハンドル」が返される。ウインドウハンドルの値は不透明値なのだが、user32ライブラリ内で非公開の構造体を指しており、この構造体はウインドウを生成したスレッドと結びついている（スレッドハンドルを保持しているのか、スレッドローカルストレージに関連付いているのか、詳細はわからない）。

そして、ウインドウメッセージは、例のメッセージ転送ループ（GetMessage→DispatchMessage）によって、これらのウインドウに転送されるのだが、このループはウインドウが関連付けられているスレッドで実行される（というよりも実行するようにコードを書く）。
プロジェクトテンプレートでは単一のメインスレッドを使うので、これらが全て同じスレッドで実行されるわけだ。

さて、たとえばウインドウにボタンがあったとして、ボタンクリックに反応するコードを書いたとしよう。「シングルスレッド」なので、ボタンクリックの処理中に別のメッセージが発生することはない。
DispatchMessageからウインドウプロシージャが呼び出され、ボタンクリックのお手製コードが走っている。そのため、この処理が終わって、次にGetMessageが呼び出されるまでは、新しいメッセージが目に見える形では現れない。

したがって、マルチスレッド実行による、複数のメッセージの同時発生と実行を考慮する必要はないわけだ。
これは鶏と卵の関係だが、Win32のウインドウメッセージ処理にこういう制限があるから、競合処理は発生しないとも言えるし、競合処理が発生しないようにWin32 APIが設計されているともいえる。

この制限が時には苦痛となる。時間がかかる処理を行う場合だ。そのような処理をボタンクリックの処理で実装すると、ウインドウは他の処理が実行出来ない。ウインドウのサイズ変更・移動・ウインドウの描画まで含めて、「固まった」かのようになる。
仕方がないので、ここでワーカースレッドを生成して、長く時間のかかる処理を委譲したとする。これで、長い処理を並行して実行できるので、ウインドウの基本的な動作に支障は出なくなる（ボタンが2回クリックされないように無効化するなどの工夫は必要だが）。

しかし、このワーカースレッドの処理が完了したときに、それをどのようにウインドウに通知するかと考えた時に問題が発生する。
大半のウインドウAPIが、特定のスレッド（この場合はウインドウを生成したのがメインスレッドなので、メインスレッド）から呼び出されないと機能しない、あるいは誤動作を起こす。そこで、PostThreadMessageなどを使って、メッセージキューに結果となるメッセージを送信する。

メッセージキューはそのうちメインスレッドのGetMessageによって引き出され、晴れて「メインスレッド」でメッセージが処理される。この特別なメッセージの処理コードを書いておけば、ワーカースレッドの処理結果は間接的にメインスレッドの実行中に処理され、ウインドウに何らかの表示を行ったりすることが出来るようになる。

.NET Frameworkにおいても、System.Windows.Forms.Control.Invoke()などを使って、背景では同じことを行う。

乱暴な言い方をすれば、クリティカルセクションがウインドウに紐付いていて、ウインドウを基準に同期を行っていることに等しい。
分かっている人には当たり前のことではあるが、この制限をスレッド親和性のモデルとしたのが、COMのアパートメントというスレッド属性だ。何故か？ それはCOMの構造を設計したときに、それがスレッディングにまつわるWindows独自の問題だったからだ（多分）。

何らかのアプリケーションのソースコードが手元にあったとする。このソースコードはすでに規模が大きく、マルチスレッドに対してどこまで安全であるかが分からない。注意深く設計されていれば、スレッドの導入にも頑健であるだろうが、今までにファサード導入で見てきたように、スレッド親和性を担保するには相応のコストが必要だ。おまけに、ウインドウの制御に関しても、どのウインドウがどのスレッドに紐付いていて、どう安全でどう危険であるかも明らかではない。アプリケーションによっては、GetMessageとDispatchMessageによるメッセージループが「複数」の別々のスレッドで実行されている可能性すらある。

また、同じ問題が（一般的なCOMではない）コンポーネントライブラリにも存在する。このような状況下では、あるコンポーネントがあるアプリケーションやコンポーネントと協調して動作させるなど、効率以前の問題で、悪夢としか言いようがない。サードパーティ製のライブラリを結合するとき、スレッド親和性についてほとんどの場合は無視（つまり親和性などなく、ウインドウとスレッドの安全は自分で担保が必要と仮定）するはずだ。

幸い、COMは「インターフェイス境界」が非常にはっきりしている。そのため、この境界を基準として、ウインドウに紐付いた暗黙のスレッドとの競合についても、背後で面倒を見ようとしたわけだ。

つづく

さてと、アパートメントという用語がどのあたりから来るのか匂わせておいたところで、2つの軸をどのように対処するのかを見ていく。

一つ目は、ファサードの有無の選択だ。
main関数で例を示したように、このままではクラスの呼び分けをする必要がある。
そこで、newする実装を隠ぺいすることを考える。たとえば、以下のような関数を用意する。

IAdd *CreateInstance(const bool threadSafe)
{
　IAdd *pInstance = new AddCalculator();

　// スレッドセーフなコンポーネントが必要なら
　if (threadSafe == true)
　{
　　return new AddCalculatorFacade(pInstance);
　}
　else
　{
　　return pInstance;
　}
}

呼び出す側は、スレッドセーフな実装が必要であればtrueを、そうでなければfalseを与えれば良い。しかし、これではクラスの型を指定するのが、boolの値にすり替わっただけだ。
そこで、いよいよコンポーネント自身にスレッド親和性の情報を付加する時がやってきた。

まず、コンポーネントの実装に、コンポーネント自身のスレッドセーフ属性を加える。これはコンポーネントのインスタンスが生成される前に参照する必要があるので、static関数とする。

class AddCalculator : public IAdd
 {
 public:
　// 途中省略
　static bool IsThreadSafe() throw()
　{
　　// このコンポーネントはスレッドセーフではない
　　return false;
　}
 };

class AddCalculator2 : public IAdd
 {
 public:
　// 途中省略
　static bool IsThreadSafe() throw()
　{
　　// このコンポーネントはスレッドセーフだ
　　return true;
　}
 };

IAdd *CreateInstance()
{
　// コンポーネントのスレッドセーフ属性を得る
　const bool componentIsThreadSafe = AddCalculator::IsThreadSafe();
　// const bool componentIsThreadSafe = AddCalculator2::IsThreadSafe();
　IAdd *pInstance = new AddCalculator();

　// コンポーネントがスレッドセーフでなければ
　if (componentIsThreadSafe == false)
　{
　　// ファサードを挟んでスレッドセーフにする
　　return new AddCalculatorFacade(pInstance);
　}
　else
　{
　　return pInstance;
　}
}

まだ納得いかないだろう。特にスレッドセーフ属性を取得するくだりは、コンポーネントの型が分かっているのだから、意味がないように見えるかもしれない。今はテンプレートを使ってお茶を濁しておく。テンプレート経由だが、コンポーネントが自身でスレッドセーフ属性を提供している事がわかると思う。

template <typename T>  IAdd *CreateInstance()
{
　// コンポーネントのスレッドセーフ属性を得る
　const bool componentIsThreadSafe = T::IsThreadSafe();
　IAdd *pInstance = new T();

　// コンポーネントがスレッドセーフでなければ
　if (componentIsThreadSafe == false)
　{
　　// ファサードを挟んでスレッドセーフにする
　　return new AddCalculatorFacade(pInstance);
　}
　else
　{
　　return pInstance;
　}
}

int main()
{
　// まだ実質的な変化はない...
　IAdd *pInstance = CreateInstance<AddCalculator>();
　// IAdd *pInstance = CreateInstance<AddCalculator2>();

　// 使う...
　delete pInstance;
　return 0;
}

上のコードに意味が見いだせないのは当然で、今までやって来た事の形を変えただけだからだ。「ついに」、もう半分の肝心な部分を付け足す。それは、現在のスレッドの指標を加味することだ。

// スレッドローカルストレージ（スレッド毎に保存される変数）
static __declspec(thread) bool g_MultiThreadBound = false;

// 現在のスレッドにスレッド属性を設定する
void SetThreadBound(const bool isMultiThreaded) throw()
{
　g_MultiThreadBound = isMultiThreaded;
}

template <typename T>  IAdd *CreateInstance()
{
　// コンポーネントのスレッドセーフ属性を得る
　const bool componentIsThreadSafe = T::IsThreadSafe();
　IAdd *pInstance = new T();

　// 現在のスレッドがマルチスレッドで使用する前提でかつ、
　// コンポーネントがスレッドセーフでなければ
　if ((g_MultiThreadBound == true) && (componentIsThreadSafe == false))
　{
　　// ファサードを挟んでスレッドセーフにする
　　return new AddCalculatorFacade(pInstance);
　}
　// コンポーネントがスレッドセーフなら、現在のスレッドがどのような属性でも問題ない。
　// コンポーネントがスレッドセーフでなくても、現在のスレッドがシングルスレッドでのみ使用する属性なら問題ない。
　else
　{
　　return pInstance;
　}
}

さて、これで、コンポーネントを使用する側にとっては、スレッドの状態を表明さえすれば、そのコンポーネントがスレッドセーフだろうが、そうでなかろうが、安全に使用できるようになった。使用者はコンポーネントがスレッドに対して安全であるかどうかを考えなくてもよくなったという事だ。
シングルスレッドで使用するなら、

int main()
{
　// シングルスレッドでのみ使用する場合
　SetThreadBound(false);

　// どちらの実装を使ったとしても、最適なインスタンスが提供される。
　IAdd *pInstance = CreateInstance<AddCalculator>();
　// IAdd *pInstance = CreateInstance<AddCalculator2>();

　// 使う...
　delete pInstance;
　return 0;
}

マルチスレッドで使用するなら、

// スレッドのエントリポイント
int ThreadEntryPoint()
{
　// マルチスレッドで使用する場合
　SetThreadBound(true);

　// どちらの実装を使ったとしても、最適なインスタンスが提供される。
　IAdd *pInstance = CreateInstance<AddCalculator>();
　// IAdd *pInstance = CreateInstance<AddCalculator2>();

　// 使う...
　// （場合によっては別のスレッドにポインタを渡して使うかも）
　delete pInstance;
　return 0;
}

なんとなく、普段COMでやっていることに近づいてきたのが分かるだろうか。
つづく。

最新のCOM記事：

COMについて、ローカルディスカッションで大幅に拡充してまとめ上げた記事があるので、そちらもどうぞ：「ChalkTalk CLR – COMのすべて」

もうあとちょっと導入を。

前回のファサードクラスによる分離を進めてみる。
このファサードクラスは、AddCalculatorクラスを内包してしまっているため、インスタンスを外部から与えられるようにすると、柔軟性が増す。

class AddCalculatorFacade : IAdd
 {
 private:
 　AddCalculator *pInner_;
 　CRITICAL_SECTION cs_;

 public:
 　AddCalculatorFacade(AddCalculator *pInner) throw()
 　　: pInner_(pInner)
 　{
 　　::InitializeCriticalSection(&cs_);
 　}

　~AddCalculatorFacade() throw()
 　{
 　　delete pInner_;
 　　::DeleteCrirticalSection(&cs_);
 　}

　LONGLONG Add(const LONGLONG adder) throw()
 　{
 　　::EnterCriticalSection(&cs_);
 　　const LONGLONG result = pInner_->Add(adder);
 　　::LeaveCriticalSection(&cs_);
 　　return result;
 　}
 };

これならば、コンストラクタでインスタンスを指定することが出来る
（更にAddCalculator *を、IAdd *にすれば、もっと汎用的になる）。しつこいが、念のため例を示す。

int main(int argc, const char *argv[])
{
 　IAdd *pAddInner = new AddCalculator();

 　// ここだけで選択（ファサードを挿入するかどうか）
 　IAdd *pAdd = pAddInner;
 　//IAdd *pAdd = new AddCalculatorFacade(pAddInner);

　 const LONGLONG result = pAdd->Add(12345);
　 delete pAdd;

 　printf("Result=%I64dn", result);
　 return 0;
}

で、いよいよスレッド親和性の話になるのだが、以下の事が重要なポイントだ。

• あるコンポーネント（クラス）が、スレッドに対して安全かどうかを表明する。
• コンポーネントにアクセスしようとしているスレッドが、「安全なスレッド」かどうかを判別する。

ということが出来れば、コンポーネント毎にスレッドの安全性を「ファサード」を使って自動的に担保できるようになる。

あるコンポーネントは、最初のAddCalculatorのように、スレッドに対する安全性が無いとする。それを、単一のスレッドでしか実行しない場合は、ファサードが挿入されない。それによって、効率よくアクセスすることが出来る。

同じコンポーネントで、複数のスレッドで同時にアクセスされることがわかっている場合の、「個々のスレッド」に対して、自動的にファサードを挿入したポインタを渡す。

これで、メソッドの呼び出しが同期化されて安全にアクセスできる。
初めからスレッドセーフなコンポーネントAddCalculator2を、単一のスレッドでしか実行しない場合は、ファサードは挿入されない。

同じコンポーネントで、複数のスレッドで同時にアクセスされることがわかっている場合の、「個々のスレッド」に対してファサードは挿入されない。
なぜなら、元からAddCalculator2はスレッドセーフだとわかっているからだ。

このように、スレッドとコンポーネントの両方に、何らかの「指標」やら「属性」があれば、スレッドセーフを自動的に担保することが出来る。
そして、スレッド側に付ける「指標」は、「アパートメント」という名前の属性だ。
つづく。

最新のCOM記事：

COMについて、ローカルディスカッションで大幅に拡充してまとめ上げた記事があるので、そちらもどうぞ：「ChalkTalk CLR – COMのすべて」

(追記:2020/5/26)

COMについて、細々とですがこのページに誘導されてくるのが分かっています。もっとわかりやすく包括的に書いたページがありますが、残念ながら、なぜか検索エンジンのレートから外されているため、ここで案内しておきます。「ChalkTalk CLR – COMのすべて」 を最初に見ることをお勧めします。

COMのわかりにくい概念のひとつに「アパートメント」がある。

COMのほとんどの概念は、抽象性を突き詰めていった結果として生まれているため、このアパートメントも解説がなければ非常に難しい。

DonBoxが書いた「Essential COM」に詳しく書いてあるが、それでも頭をひねって考える必要がある。
同じくEssential COMの第一章では、COMのインターフェイスという概念が生まれた背景について、非常にうまく説明している。ここでは、同じような方法でアパートメントを説明してみることにする。

＃導入は実は少々怪しいところがあるが、この方法でアパートメントを解説している文書は見たことがないので、お役にたてれば幸い。

非常に初期の、C言語が広まる機運が高まりつつあるころ、C言語でプログラムを書いていた人は、次のような疑問に遭遇した。つまり、いかにしてprintfやstrcpyのような独立性の高い、再利用可能な関数を書いて、それをライブラリ化するかということだ。
COMのインターフェイスはそこが基礎になっているのだが、これは言ってみれば「バイナリレベルのライブラリ（コンポーネント・クラス）の結合」を自由に行うための技術と言っていい。そのために、インターフェイス定義でコンポーネントの「顔」を抽象化して、綺麗さっぱりコンポーネントを分離できるようにしたというわけだ。

アパートメントはこれを更に推し進めて、「スレッド親和性」を抽象化したものだ。で、スレッド親和性って何？という話になるのだが、これを以下で説明する。

ここに、非常に単純な、足し算を行うCOMコンポーネントがある。本当にIDLから説明すると面倒なので、C++のクラスでこれを模式してみる。

class AddCalculator
{
private:
　LONGLONG value_;

public:
　AddCalculator() throw()
　　 : value_(0)
　 {
　 }

　LONGLONG Add(const LONGLONG adder) throw()
　 {
　　value_ += adder;
　　return value_;
　}
};

Add()を呼び出すことによって、引数の値を足し算して結果を取得する。結果は戻り値として得られる。
このクラスは一般的な使い方で十分機能する。しかし、それは「シングルスレッド」や「マルチスレッド中の特定のスレッド」で使用した場合のみだ。

たとえば、Add()をマルチスレッド中の複数の異なるスレッドから同時にアクセスした場合、計算や結果の戻り値が容易に破たんすることがわかるだろう。
32ビットプラットフォームならさらにひどい結果となる（だからLONGLONGで例を書いてみた）。

問題は、Add()のブロック内の足し算を行っている個所、そして結果をreturnで返している部分。ここが別々のスレッドで同時に実行されると、競合状態が発生する。
そのため、マルチスレッドでも問題なくコードを実行できるようにするためには、ここを「排他制御」で保護する必要がある。

一般的にはクリティカルセクションを使う。コードを書き直してみる。

class AddCalculator2
{
private:
　LONGLONG value_;
　CRITICAL_SECTION cs_;

public:
　AddCalculator2() throw()
　　: value_(0)
　{
　　::InitializeCriticalSection(&cs_);
　}

　~AddCalculator2() throw()
　{
　　::DeleteCrirticalSection(&cs_);
　}

　LONGLONG Add(const LONGLONG adder) throw()
　{
　　::EnterCriticalSection(&cs_);
　　value_ += adder;
　　const LONGLONG result = value_;
　　::LeaveCriticalSection(&cs_);
　　return result;
　}
};

足し算の計算を行っている部分と、戻り値として返す値を確定させる部分（resultに代入する）をクリティカルセクションで保護した。

resultに代入しなおすのは、32ビット環境ではこの一行が2つかそれ以上のマシン語命令に置き換えられてしまい、そのコードを実行し終わるまでを保護する必要があるからだ。そして、たとえ64ビットであっても、return文の実行の直前にvalue_が書き換えられてしまうと、adderに指定した値以上の結果が返されてしまう可能性がある。それを保護するため、一旦resultに値を代入して、絶対に結果が変わらないようにするというわけだ。

さて、これでマルチスレッド環境で、複数のスレッドから同時にAddを呼び出しても問題なく動作するようになった。このAddCalculator2クラスは、すべてAddCalculatorクラスと置き換えることが出来る。つまり、マルチスレッド環境だけではなく、シングルスレッド環境でも問題ない。シングルスレッド環境ではクリティカルセクションで保護する意味はないが、保護していたとしても動作に影響はないからだ。

パフォーマンスの問題を除けば。

要するに、シングルスレッド環境で動かす場合、クリティカルセクションによる排他処理は完全に無駄になる。たとえば、上記のような単純な例でも1000万回呼び出されるとすれば、小さな排他制御のコードでさえ大きな無駄になる可能性がある。もちろん、コード全体からみて、この処理にどれだけの実行割合があるかによるのだが。

一つの方法としては、コンパイルオプションで、シングルスレッドの場合はAddCalculator、マルチスレッドの場合はAddCalculator2を使い分けるという方法がある。しかし、この方法には問題がある。

• 常に二つの似て異なるクラスを保守しなければならない。
• これらのクラスを使う側は、クラスのスレッドに関する安全性に気を配らなければならない。どちらのクラスがスレッドに対して安全なのか、そうではないのか、知っている必要がある。
• 実行時に切り替える事は出来ない。

実はこの方法は、すでになじみのある方法だ。VC++ではシングルスレッドとマルチスレッドのライブラリを選択出来る（出来た。新しいVCではシングルスレッドライブラリは廃止されている。廃止された理由は、やはり「保守」の問題ではないだろうか）。

シングルスレッドなプログラムのコンパイルにマルチスレッドのライブラリを使っても実害はないが、速度は遅くなる。
さて、もう少し前向きな方法を考えてみる。同期処理をファサードで分離してみてはどうだろうか。AddCalculatorクラスのファサードAddCalculatorFacadeを作る。

class AddCalculatorFacade
{
private:
　AddCalculator inner_;
　CRITICAL_SECTION cs_;

public:
　AddCalculatorFacade() throw()
　{
　　::InitializeCriticalSection(&cs_);
　}

　~AddCalculatorFacade() throw()
　{
　　::DeleteCrirticalSection(&cs_);
　}

　LONGLONG Add(const LONGLONG adder) throw()
　{
　　::EnterCriticalSection(&cs_);
　　const LONGLONG result = inner_.Add(adder);
　　::LeaveCriticalSection(&cs_);
　　return result;
　}
};

これで、計算の実態はAddCalculatorのまま、スレッドセーフなクラスとしてAddCalculatorFacadeを使えばよくなった。計算ロジックの保守は、AddCalculatorクラスだけを行えばよい。マルチスレッドの安全性が欲しい場合は、AddCalculatorFacadeを使い、シングルスレッドで安全であることがわかっていればAddCalculatorを使って「最速」を手に入れることが出来る。

このままでは、コンパイルオプションで切り分けるという部分は未解決だ。そこで、共通のインターフェイス「IAdd」を定義して分離してみる。

class IAdd
{
public:
　virtual ~IAdd() throw()
　{
　}
　virtual LONGLONG Add(const LONGLONG adder) throw() = 0;
};

class AddCalculator : public IAdd
{
private:
　LONGLONG value_;

public:
　AddCalculator() throw()
　　: value_(0)
　{
　}

　LONGLONG Add(const LONGLONG adder) throw()
　{
　　value_ += adder;
　　return value_;
　}
};

class AddCalculatorFacade : IAdd
{
private:
　AddCalculator inner_;
　CRITICAL_SECTION cs_;
public:
　AddCalculatorFacade() throw()
　{
　　::InitializeCriticalSection(&cs_);
　}

　~AddCalculatorFacade() throw()
　{
　　::DeleteCrirticalSection(&cs_);
　}

　LONGLONG Add(const LONGLONG adder) throw()
　{
　　::EnterCriticalSection(&cs_);
　　const LONGLONG result = inner_.Add(adder);
　　::LeaveCriticalSection(&cs_);
　　return result;
　}
};

これで、コードを使う実態は常にIAddインターフェイスを使ってアクセスし、クラスをnewするところだけで、AddCalculatorかAddCalculatorFacadeかの選択を行えばよい。

int main(int argc, const char *argv[])
{
　// ここだけで選択
　IAdd *pAdd = new AddCalculator();
　// IAdd *pAdd = new AddCalculatorFacade();
　const LONGLONG result = pAdd->Add(12345);
　delete pAdd;
　printf("Result=%I64dn", result);
　return 0;
}

さて、以上のようになっても、どちらのクラスを使用すべきか？という問題が残る。そして、シングルスレッドで使っていたクラスが、ある時から別のスレッドによってアクセスされるような場合に、この方法では対処出来ない。そのような場合、仕方がないから初めからマルチスレッド対応のAddCalculatorFacadeを使うという事になる。

これをどうやって解決するのかということの、頭をひねった結果が「アパートメント」という考え方だ。
つづく。