"Fixed"/"Load Balanced" C# Thread-Pool?

Question

Ich habe eine Komponente von Drittanbietern, die "teuer" ist, um hochzufahren. Diese Komponente ist nicht Thread-sicher. Diese Komponente wird (vorerst) in einem WCF-Dienst gehostet, also ... jedes Mal, wenn ein Anruf in den Dienst kommt, muss ich die Komponente neu aufbauen.

Was ich stattdessen tun möchte, ist ein Pool von sagen wir 16 Threads, die jeweils ihre eigene Kopie der Komponente hochfahren und einen Mechanismus haben, um die Methode aufzurufen und sie an einen der 16 Threads verteilen zu lassen der zurückgegebene Wert

So etwas Einfaches wie:

var response = threadPool.CallMethod(param1, param2); 

Sein feine für den Anruf zu blockieren, bis er eine Antwort bekommt, als ich die Antwort auf vorgehen muß.

Irgendwelche Vorschläge? Vielleicht überschätze ich es und eine ConcurrentQueue, die von 16 Threads bedient wird, würde den Job tun, aber jetzt sicher, wie der Rückgabewert der Methode an den Aufrufer zurückgegeben würde?

Answer 1

WCF wird bereits den Thread-Pool verwenden, um seine Ressourcen zu verwalten. Wenn Sie also eine Schicht Thread-Management hinzufügen, wird es nur schlecht gehen. Vermeiden Sie dies wenn möglich, da Sie bei Ihren Serviceanrufen in Konflikt geraten.

Was ich in Ihrer Situation tun würde, ist einfach eine einzigenThreadLocal oder Thread statische, die mit Ihrem teuren Objekt einmal initialisiert bekommen würde. Danach wäre es für den Thread-Pool-Thread verfügbar.

Das geht davon aus, dass Ihr Objekt in einem MTA-Thread in Ordnung ist; Ich schätze, es kommt von deinem Post, da es sich anhört, als würden die Dinge gerade funktionieren, aber nur langsam.

Es besteht die Sorge, dass zu viele Objekte erstellt werden und Sie zu viel Speicher verwenden, da der Pool zu groß wird. Prüfen Sie jedoch, ob dies in der Praxis der Fall ist, bevor Sie etwas anderes tun. Dies ist eine sehr einfache Strategie, die so einfach zu testen ist. Werden Sie nur komplexer, wenn Sie es wirklich brauchen.

Answer 2

In erster Linie stimme ich @briantyler: ThreadLocal<T> oder Thread statische Felder ist wahrscheinlich, was Sie wollen. Sie sollten damit als Ausgangspunkt gehen und andere Optionen erwägen, wenn es Ihren Bedürfnissen nicht entspricht.

Eine komplizierte, aber flexible Alternative ist ein Singleton-Objektpool. In seiner einfachsten Form wird Ihr Pool-Typ wie folgt aussehen:

public sealed class ObjectPool<T> 
{ 
    private readonly ConcurrentQueue<T> __objects = new ConcurrentQueue<T>(); 
    private readonly Func<T> __factory; 

    public ObjectPool(Func<T> factory) 
    { 
     __factory = factory; 
    } 

    public T Get() 
    { 
     T obj; 
     return __objects.TryDequeue(out obj) ? obj : __factory(); 
    } 

    public void Return(T obj) 
    { 
     __objects.Enqueue(obj); 
    } 
} 

Dies scheint nicht schrecklich nützlich, wenn Sie vom Typ denken T in Bezug auf die primitive Klassen oder Strukturen (dh ObjectPool<MyComponent>), wie der Pool hat keine Threading-Steuerelemente eingebaut. Aber Sie können Ihren Typ T für einen Lazy<T> oder Task<T> Monad ersetzen, und erhalten genau das, was Sie wollen.

Pool Initialisierung:

Func<Task<MyComponent>> factory =() => Task.Run(() => new MyComponent()); 
ObjectPool<Task<MyComponent>> pool = new ObjectPool<Task<MyComponent>>(factory); 

// "Pre-warm up" the pool with 16 concurrent tasks. 
// This starts the tasks on the thread pool and 
// returns immediately without blocking. 
for (int i = 0; i < 16; i++) { 
    pool.Return(pool.Get()); 
} 

Verbrauch:

// Get a pooled task or create a new one. The task may 
// have already completed, in which case Result will 
// be available immediately. If the task is still 
// in flight, accessing its Result will block. 
Task<MyComponent> task = pool.Get(); 

try 
{ 
    MyComponent component = task.Result; // Alternatively you can "await task" 

    // Do something with component. 
} 
finally 
{ 
    pool.Return(task); 
} 

Diese Methode ist komplexer als Ihre Komponente in einem ThreadLocal oder Gewinde statisches Feld beibehalten, aber wenn Sie brauchen etwas Phantasie wie Begrenzung zu tun Bei der Anzahl der Pool-Instanzen kann die Pool-Abstraktion sehr nützlich sein.

EDIT

Grund Pool-Implementierung mit einem Get, welche Blöcke einmal am Pool wurde abgelassen "von X-Instanzen gesetzt fixed":

public sealed class ObjectPool<T> 
{ 
    private readonly Queue<T> __objects; 

    public ObjectPool(IEnumerable<T> items) 
    { 
     __objects = new Queue<T>(items); 
    } 

    public T Get() 
    { 
     lock (__objects) 
     { 
      while (__objects.Count == 0) { 
       Monitor.Wait(__objects); 
      } 

      return __objects.Dequeue(); 
     } 
    } 

    public void Return(T obj) 
    { 
     lock (__objects) 
     { 
      __objects.Enqueue(obj); 

      Monitor.Pulse(__objects); 
     } 
    } 
}