問題タブ [mta]

MTAThreadの Windows フォーム内でホストする必要がある WPF ユーザー コントロールがあります。また、ソリューションは STAThread と MTAThread の両方で機能するはずです。また、技術的には、運用環境でアパートメントの状態を変更するオプションはありません。

Program.cs

この場合、カウントが増加し、MTAThread で例外がスローされないため、ホストがコントロールに追加されるようになりました。しかし、WPF ユーザー コントロールはレンダリングされません。ただし、STAThread では、「呼び出し元のスレッドはこのオブジェクトにアクセスできません....」という例外をスローしています。

これで何か助けていただければ幸いです。

COM と STA/MTA に関する多くの質問がありますが (例:ここ)、そのほとんどは UI を備えたアプリケーションに関するものです。ただし、次の設定があります。

• デフォルトでマルチスレッド アパートメントであるコンソール アプリケーション (Main() には明示的に[MTAThread]属性があります)。
• メイン スレッドは、いくつかのワーカー スレッドを生成します。
• メイン スレッドは、シングル スレッドの COM オブジェクトをインスタンス化します。
• メイン スレッドは、ユーザーが「q」を押すまで Console.ReadLine() を呼び出します。その後、アプリケーションは終了します。

いくつかの質問：

• COM オブジェクトのメッセージ ポンプの必要性について言及している箇所は数多くあります。この質問が示唆するように、メイン スレッドのメッセージ ポンプを手動で作成する必要がありますか、それとも CLR が新しい STA スレッドでメッセージ ポンプを作成しますか?
• 念のために言っておきますが、CLR が必要な配管を自動的に作成すると仮定すると、明示的な同期を必要とせずに任意のワーカー スレッドから COM オブジェクトを使用できますか?
• 性能面で優れているのは次のうちどれですか。
  • COM オブジェクトとの間のマーシャリングは CLR に任せます。
  • 別の STA スレッドでオブジェクトを明示的にインスタンス化し、他のスレッドにConcurrentQueue.

MTA 準拠の COM の前提条件に関するソース コードが見つかりません。オブジェクトの ThreadingModel レジストリ キーを Apartment から Both に変更しようとしましたが、データにアクセスする前にセカンダリ スレッドがメソッドを呼び出すと、クラッシュが発生します。

STA COM にメッセージ ポンプが必要な場合、MTA COM オブジェクトにはどのような配管コードが必要ですか?

いくつかの COM オブジェクトを実行する非シングルトン WCF (スタンドアロン) サービスがあります。Thread.Start を使用する非 WCF 環境では、これらの COM オブジェクトは、すべての CPU を利用してほぼ同時に完了し、異なるスレッドで正常に並列実行されます。

しかし、特定の WCF サービスでそれらを使用しようとすると、奇妙なことが起こります。

レジストリ内でApartmentStateがBothに設定されている場合、WCF は機能しますが、タスクは順次実行され、互いの完了を待機しているように見えます。CPU 使用率が 1 CPU のシェアを超えることはありません。STAで強制的に実行するのと同じです。

レジストリでApartmentStateがFreeに設定されていると、クラッシュします。

私は単にそれを理解していません。これは何らかの配管が邪魔をしているのでしょうか？

私の WCF サービス クラスには、次の属性があります。

[ServiceBehavior(AddressFilterMode = AddressFilterMode.Any、InstanceContextMode = InstanceContextMode.PerCall、ConcurrencyMode = ConcurrencyMode.Single)]

COM オブジェクトは静的/グローバルです。

vb.net WebService でメモリリークを探しているときに、ファイナライザーがブロックされていることを検出したため、いくつかのオブジェクトが解放されていない (例: System.Threading.ReaderWriterLock)

STAThread 属性が私のメイン メソッドに設定されているため、Google はこれがその可能性があると私に言いました。VB.net がデフォルトで STA を使用しているのに対し、c# は MTA を使用していることを知るまでには長い時間がかかりました。

MTAThread-Attribute をメイン メソッドに追加すると、すべてが正常に機能し、オブジェクトが解放されました。したがって、私が正しく理解している場合、Finalizer-Thread は STA-Mode でブロックされています。

ここまでは順調ですが、正直なところ、STA と MTA については今日初めて知りました。何も考えずに STA と MTA を切り替えることはできますか?

更新 コードを壊さずに MTA と STA を切り替えることができるかどうかはまだわかりません。ここにいくつかの考えがあります

• 私のコードでは COM オブジェクトを使用していません。
• しかし、私が使用している他のいくつかのライブラリは、内部でそれらを使用しているようです。たとえば、OracleCommand
• 私のアプリケーションは vb.net で書かれているため、たまたま STA-Appartment に設定されています。これは、開発時にはわからなかった vb.net のデフォルトであるためです。
• アプリケーションを C# で記述した場合、デフォルトで MTA に設定されます。
• では、内部で使用されている COM オブジェクトを気にする必要があるのでしょうか?

サード パーティ アプリケーションによって呼び出される DLL を作成しています。DLL は MTA スレッドから呼び出され、サード パーティ アプリケーションへの呼び出しは同じスレッドで行う必要があります。アプリケーションからアウト プロセス COM サーバーを呼び出す必要があり、COM サーバーに渡されたオブジェクトを使用して、この COM サーバーからサードパーティ アプリケーションにコールバックしたいと考えています。

例えば

ここで、スレッドを STA に変更できれば問題なく動作しますが、残念ながらこれは私の手に負えません。

COM サーバーから戻ってくる呼び出しを強制的に同じスレッドにする簡単な方法はありますか?

呼び出し元のアプリケーションは、Windows フォームや WPF アプリケーションではなく、ウィンドウのないサービスであることに注意してください。

私が考えることができる唯一のことは、COM サーバーへの呼び出しを行う新しいワーカー スレッドを作成し、独自のイベント キューを実装して、EntryPoint 内で API 呼び出しを待機するループを作成することです。次に、API 呼び出しへのデリゲートをワーカー スレッドからイベント キューに配置し、EntryPoint でキューを処理するときにすべてのデリゲートが正しいスレッドから呼び出されるようにします。

これは、非常に一般的なはずの非常に醜い複雑なソリューションのように思えます...単純な（r）ソリューションはありますか？