問題タブ [apartments]

STA についての私の理解では、スレッドが STA アパートメントで実行されている場合、スレッドの安全性について心配する必要はなく、スレッドの関数への呼び出しは自動的にキューに入れられます。

私の質問は、STA でワーカー スレッドを開始し、関数を介してそのスレッドからオブジェクトを取得する場合、そのオブジェクトを使用するときにスレッド セーフについて心配する必要があるかということです。または、そのオブジェクトの関数呼び出しはスレッドセーフですか?

ATLCOMサーバーDLLでクロススレッドCOM呼び出しを行うことを示すコードサンプルを探しています。知っていますか？

詳細：

私のコンポーネントは、バックグラウンドスレッドで作業する必要があるIEブラウザヘルパーオブジェクトです。IEのメインスレッドから呼び出されたオブジェクトのメソッドの1つで、IEはIE DOM（IHtmlWindow2）へのポインターを提供し、それをローカルメンバー変数に格納します。

次に、保存したCOMインターフェイスポインターのメソッドを非同期的に呼び出すことができるワーカースレッドを作成します。

重要な場合は、IEからインターフェイスポインターを取得したメソッドから戻った後に呼び出しが発生するため、ワーカースレッドから呼び出しを行おうとすると、IE（コードではなく）が制御できます。

私のコンポーネントとホストアプリケーションはどちらもApartmentスレッドです。

これがどのように行われるかを示す優れたC++サンプルを知っている人はいますか？

この質問とその回答を読んで、実装を最初から作成するために必要な学習の量に恐れを感じたため、私は特に短くてわかりやすいサンプルを探しています（関連するドキュメントへのポインタだけではありません）。誰かがコードを書く前にドンボックスの本を読むことを勧めるときはいつでも、あなたはあなたが長くて混乱している夜にいることを知っています... :-)

簡単に言うと、COM inproc-server（dll）で動作するC＃アプリケーションで、「0x80010100：システムコールに失敗しました」という例外が発生し、デバッグモードでもContextSwitchDeadlock例外が発生します。

詳細は次のとおりです。

1）C＃アプリはSTAを初期化し、COMオブジェクト（「Apartment」として登録）を作成します。次に、inはその接続ポイントにサブスクライブし、オブジェクトの操作を開始します。

2）ある段階で、COMオブジェクトは多くのイベントを生成し、同じアパートで作成されたCOMオブジェクトの非常に大きなコレクションを引数として渡します。

3）C＃側のイベントハンドラーは上記のコレクションを処理し、オブジェクトのいくつかのメソッドを呼び出すことがあります。ある段階で、後者の呼び出しは上記の例外を除いて失敗し始めます。

COM側では、アパートはwinprocが次のように見える非表示のウィンドウを使用します。

イベントは、COMサーバーの他の部分からこのウィンドウに投稿されます。

イベントは、実際のパラメータにバインドされた標準のATL CP実装であり、要約すると次のようになります。

C＃では、ハンドラーは次のようになります。

==================

それで、アパートのメッセージキューが配信しようとするイベントでいっぱいになっているという理由だけで、上記の問題が発生する可能性がありますか？または、そのような動作を引き起こすために、メッセージループを完全にブロックする必要がありますか？

メッセージキューに、「onEvent」呼び出しと評価される2つの連続したイベントがあると仮定します。最初のコードはC＃マネージコードを入力します。これは、同じアパートであるアンマネージコードを再入力しようとします。通常、これは許可されており、私たちはこれを頻繁に行います。いつ、どのような状況で失敗する可能性がありますか？

ありがとう。

私は、通話の発着信時にブラウザー ウィンドウ (ExtendedWebBrowser) を開く VOIP クライアント (ウィンドウのフォーム) に取り組んでいます。通常は正常に動作しますが、コンピューターがスリープ モードになってから復帰すると、プログラムは次のエラーでクラッシュします。

コードで開始されたスレッドを設定しようとしましたthread.SetApartmentState(ApartmentState.STA)が、同じ結果が得られます。[STAThread]また、関数の前に持っていmain()ます。今、コンピューターがスリープ状態になったときにスレッドが正しく終了しないことにもっと関係があるのではないかと思っていますが、よくわかりません。私のバックグラウンドは C++ と DirectX です。これは私が取り組んだ最初の Windows フォームなので、助けていただければ幸いです。

フォローアップ:プログラムを再開した後、メイン スレッドではなくワーカー スレッドで開始されていることを発見した後、この問題を解決することができました。詳細については、こちらを参照してください:スリープ (サスペンド) および Windows フォームの再開は、メイン スレッドではなくワーカー スレッドでプログラムを開始します。

アウトプロセス環境で COM アパートメントを理解するのに苦労しています。

CoInitializeEx基本的に、クライアントが自分のスレッドをアパートに登録するために呼び出す必要がある理由がわかりません。サーバー スレッドが使用するオブジェクトと、STA または MTA に存在するサーバー スレッドを理解できます。しかし、なぜクライアントがこれについて心配する必要があるのか​​ 理解できません。

すべてのドキュメント/ガイドには、クライアントがCoInitializeExアパートに登録するために電話する必要があると書かれています。これは、サーバーがクライアントのスレッドを追跡しているということですか? それとも、クライアント プロセスにもアパートメント データが割り当てられているのでしょうか。

フリー スレッドとして作成されたアウト プロセス COM (ATL) サーバーがあります ( CComMultiThreadModel)

それがオブジェクトへの呼び出しの再入可能性にどのように関連するかについて少し混乱しています。たとえば、複数のクライアントから同時に呼び出すことが許可され、それらの要求を同時に処理できると想定していましたが、(私のログによると)各リクエストがシリアル化されていること。

私が見逃しているのは、MTAとしてクラスを作成するだけで、それが本当にそうであるか、他にやらなければならないことがあります。ここでは、単一プロセス内のスレッドではなく、すべてが同時呼び出しを行う複数のプロセスについて言及しているためCOINIT_MULTITHREADED、問題ではないことに注意してください。

MTA に関する一部の MS ドキュメントからのこのスニペットは、すべてがそのまま使用できるように思われます。

複数のクライアントが、異なるスレッドから、フリースレッドをサポートするオブジェクトを同時に呼び出すことができます。フリー スレッドのアウトプロセス サーバーでは、COM が RPC サブシステムを介してサーバー プロセス内にスレッドのプールを作成し、クライアント呼び出し (または複数のクライアント呼び出し) をこれらのスレッドのいずれかによっていつでも配信できます。

Wcf サービス ライブラリを作成していて、アンマネージ com dll をロードしたいと考えています。com dll スレッド モデルは設定されていないため、メインの STAスレッド モデルでのみ実行されるシングル スレッドのレガシー コンポーネントです。

wcf サービスでは、アパートを STAのように設定しました

com コンポーネントのインスタンスを作成しようとすると、例外が発生します。

com dll をデバッグすると、エラーがスローされましたRPC_E_WRONG_THREAD。

スレッド モデルを に設定することで問題を解決できますFree Threaded Marshaller。しかし、com dll の現在のスレッド モデルを変更することはできません。

どうすれば wcf サービスから com dll にアクセスできますか?

.Net フレームワーク 4.0、Windows 7 x64

CoRegisterClassObject を使用して、com オブジェクトを含む dll をロードする方法をカスタマイズしようとしています。スレッドのアパートメント タイプが com オブジェクトのものと一致しないときに発生していた問題を解決する方法を試しています。coregisterclassobject が S_OK を返すという問題がありますが、com オブジェクトはまだ作成されるレジストリに依存しているため、何もしていないようです。これは、失敗している概念実証として私が書いたサンプルです (TestComObj はアパートメント スレッドです)。

そして、これが私の主な機能の関連部分です。

CoRegisterClassObject でレジストリを使用するべきではないため、現在の MTA スレッドではなく、STA でアパートメント スレッド オブジェクトを手動で作成する必要があるという考えでした。CoRegisterClassObject を使用していない場合、CoGetClassObject は新しいスレッドを生成し、そのスレッドで DllGetClassObject を呼び出すことに気付きました。そのため、クラス ファクトリを STA で作成するだけで、オブジェクトがそこに存在することがわかりました。

私が見ている問題は、上記のコードでは、ClassFactory が正常に動作しているにもかかわらず、まだレジストリを使用して TestComObj を作成していることです。今はとてもシンプルです。正しい dll に対して LoadLibrary を呼び出し、次に dllgetclassobject を呼び出し、その結果に対して createinstance を呼び出すだけです。アパートメントとスレッド化の問題を扱っていないときは、これを使用して、登録せずに com オブジェクトを作成できます。したがって、ここで何が問題なのかわかりません。