4

特定のニーズに合わせて最適化されたカスタムThreadPoolを作成しました。ただし、プロセスに複数のAppDomainがある場合、CLR ThreadPoolはすべてのAppDomain間で共有できるため、この動作を再現できるようにしたいと思います。

これは、分散ThreadPoolを作成するためにMarshalByRefObjectとRemotingを使用して実行できますが、カスタムスレッドプールの主な目標はパフォーマンスであるため、不要なオーバーヘッドが追加されるのではないかと心配しています。

もう1つの理論的な解決策は、アンマネージオブジェクトを使用してAppDomainのメモリ境界をハックすることです。私が正しければ、AppDomainのメモリ境界は管理対象オブジェクトにのみ適用されるため、各AppDomainに1つの管理対象ラッパーがあり、すべて同じ非管理対象オブジェクトを指している可能性があります。

だから私の質問は：

  1. 最小限のオーバーヘッドでリモート処理を使用してカスタムスレッドプールを作成する方法はありますか？
  2. そうでない場合、AppDomain間でアンマネージオブジェクトを共有することは可能ですか？
4

2 に答える 2

2

各appdomainに新しいスレッドプールインスタンスを作成しますが、セマフォを使用して、すべてのインスタンスで実行されているスレッドの総数を制御します。これは、同じ合計同時ジョブを処理できることを意味しますが、マーシャリングの悲しみはありません。

MSDNドキュメントに例があります。

于 2009-11-19T00:33:33.027 に答える
0

それについてもっと考えた後、プロセス全体のThreadPoolを再実装しようとするのはおそらく悪い考えです。CLRThreadPoolはすでにこれに最適化されています。

私の場合、プールにキューに入れられた作業項目に優先順位を付けることができるように、より柔軟性が必要でした。これは、既存のCLRThreadPoolの上に構築されたレイヤーで実行できます。

于 2009-11-19T16:31:53.390 に答える