スレッドセーフなライブラリを使用するためのクイックフィックス

Question

スレッドセーフではありませんが、他のスレッドセーフでない外部リソースは使用しないライブラリを使用しています。

スレッドセーフ（スレッドセーフではない主な理由は、インスタンスごとに読み取り/書き込みを行う静的フィールドが多く、処理される多くのインスタンスで正常に動作することですシーケンシャルに複数のインスタンスを並列に使用すると明らかに失敗します）

私はハックを感じる迅速な修正として、このアプローチを本質的に間違っているのだろうかと思っています。

スレッドごとにアプリケーションドメインを作成し、そのドメインにスレッドデータをマーシャリングし、各ドメインでライブラリを読み込み、スレッドを持つアプリケーションドメインを実行してから、アンロードします。

これは、減速（多くのライブラリがロードされ、背中合わせの力がたくさんあります）を意味していますが、これを不可能にする明白なものがあります。

Answer 1

どのくらいのライブラリと対話する必要がありますか？あまりにも巨大ではない場合は、その周りにラッパーを構築することができます。ラッパーのメソッドを呼び出すと、ロックを処理し、内部ライブラリへのスレッドセーフな呼び出しを行います。

インターフェイスを宣言することができ、実装はラッパークラスです。現在、スレッドの安全性の問題を解決することに加えて、静的メソッドへのテスト可能でない直接の依存関係を削除しました。

静的メンバーの別々の「インスタンス」を保持するだけのアプリドメインを作成するよりもはるかに洗練されたものになるでしょう（ライブラリによっては可能です）。

// Class with static memebers 
public class FooManager 
{ 
    public static void ManageFoo(Foo foo) 
    { 
     // Does some non thread-safe stuff 
    } 
} 

public interface IFooManager 
{ 
    void ManageFoo(Foo foo); 
} 

public class FooManagerWrapper : IFooManager 
{ 
    private static readonly object FooManagerLock = new object(); 

    public void ManageFoo(Foo foo) 
    { 
     lock (FooManagerLock) 
     { 
      FooManager.ManageFoo(foo); 
     } 
    } 
} 

This blog postが含まれています。スレッドの安全性が問題ではない場合でも、私は自分のコードが静的なクラスとメソッドに直接依存することは望ましくありません。（私がそれらを書いたとしても）