Ich glaube, dass TPL normalerweise einen Thread pro Kern verwenden wird, wenn Sie ihm nicht ausdrücklich mitteilen, dass er mehr verwenden soll. Es ist möglich , dass es erkennt, wenn das nicht genug ist - z. In Ihrem Fall, wo Ihre Aufgaben die meiste Zeit damit verbringen, auf Daten zu warten.

Gibt es einen Grund, warum Sie asynchrones Web-Abruf nicht verwenden können? Ich vermute, dass es hier keinen Thread pro Task oder gar einen Thread pro Core geben muss. TPL macht verschiedene Aspekte der asynchronen Programmierung einfacher, mit Dingen wie Fortsetzungen.

In Bezug auf Effizienz, ist Ihre Anwendung tatsächlich CPU-gebunden? Es hört sich so an, als müssten Sie die maximal mögliche Parallelität auf der Netzwerkseite erreichen - das ist der Punkt, auf den Sie sich konzentrieren sollten, es sei denn, die Berechnungen sind wirklich schwer.

UPDATES - NICHT VON URSPRÜNGLICHEM AUTOR

Die obige Antwort ist wie immer großartig, könnte aber irreführend sein, da sie in .NET 4.0 CLR einige wichtige Änderungen nicht enthält.

Wie Andras sagt, verwendet die aktuelle TPL-Implementierung den Thread-Pool und verwendet daher so viele Threads wie erforderlich ( Anzahl der Kerne ist jetzt irrelevant ):

  

Die Task Parallel Library (TPL) ist eine Sammlung neuer Klassen   speziell entwickelt, um die Ausführung zu erleichtern und effizienter zu gestalten   sehr fein abgestimmte parallele Workloads auf moderner Hardware. TPL war es   seit einiger Zeit als CTP separat erhältlich und wurde in   Visual Studio 2010 CTP, aber in diesen Releases wurde es auf gebaut   eigener dedizierter Arbeitsplaner . Für Beta 1 von CLR 4.0 der Standardwert    Scheduler für TPL ist der CLR-Thread-Pool , der TPL-Stil ermöglicht   Workloads, um mit vorhandenem, QUWI-basiertem Code "nett zu spielen" und erlaubt uns   einen Großteil der zugrunde liegenden Technologie im Thread Pool - in - wiederzuverwenden   insbesondere der Thread-Injection-Algorithmus, den wir in a diskutieren werden   zukünftiger Beitrag.

Von:

Ссылка

Als allgemeine Regel gibt es nichts, was die TPL daran hindert, mehr (oder weniger) Threads als Kerne zu verwenden.

Um die Situation etwas mit TPL zu steuern, wäre mein erster Ansatz: Stellen Sie sicher, dass threadpool max threads setting ist mindestens 30, dann parallelisieren Sie die Aufgabe mit maximale Concurrency-Ebene von 30. Innerhalb der Task können Sie ein Semaphor verwenden, bevor Sie die CPU-gebundene Berechnung starten, um die Parallelität zu beschränken Anzahl der Kerne. Wenn Sie nicht unter IIS oder SQL Server laufen, können und möchten Sie vielleicht die minimale / maximale Anzahl von Threadpool-Threads auf 30 setzen, um zu verhindern, dass die Thread-Pool-Heuristiken mit der Anzahl der Threads zu viel spielen. (Vorausgesetzt natürlich, dass TPL und der Thread-Pool während dieser Zeit nicht für andere Zwecke in Ihrer Anwendung verwendet werden.)

Die optimale Anzahl von Threads hängt von der Situation ab. Betrachten wir z.B. Ihr Szenario: Ihre Aufgaben sind beim Abrufen von Daten nicht an die CPU gebunden - sie sind netzwerkgebunden. Wenn Sie die Aufgaben starten, sollten Sie die Parallelität erhöhen, damit Downloads gleichzeitig ausgeführt werden. Ihre Berechnungen können jedoch CPU-gebunden sein. In diesem Fall führt die Verringerung der Anzahl der Threads, sodass nur ein Thread pro Kern ausgeführt wird, zu einer besseren Leistung.

TPL basiert nun auf der neuen CLR-Thread-Pool .
Der Thread-Pool verwendet Heuristiken, um über die Anzahl der Threads zu entscheiden.
Es gibt einen Channel9 Video über den neuen Thread-Pool mit ein wenig Einblick.
Die Heuristiken des alten Thread-Pools und einige Bits über den neuen Thread können hier gefunden werden < em> (letzter Absatz "Was hält die Zukunft?") .

Der Algorithmus und die Zahlen wurden in den verschiedenen Versionen der CLR geändert.
Das könnte auch in Zukunft so sein.

Es gibt viele Posts über die Nebenläufigkeitsebene, auf die ich stieß hier .

  

Ich habe eine Anwendung, die 30 unabhängige Tasks gleichzeitig mit Multithreading ausführt, jede Task ruft Daten über http ab, führt eine Berechnung durch und gibt ein Ergebnis an den ui-Thread zurück.

Das ist ein IO-gebundenes konkurrierendes Programm.

  

Kann ich mit TPL die gleichen Aufgaben ausführen?

Sie können, aber die TPL ist für CPU-gebundene parallele Programme konzipiert, so dass Sie es missbrauchen würden.

  

Erstellt TPL 30 neue Threads und verteilt sie auf alle verfügbaren Cores oder teilt es die Tasks einfach auf die verfügbaren Cores auf und verwendet einen Thread pro Core?

Weder. Die TPL verwendet im Wesentlichen warteschlange Work-Stealing-Aufgabenwarteschlangen pro Prozessor, um dynamisch CPU-intensive Berechnungen auszugleichen, während sie ausgeführt werden.

  

Wird es in diesem Fall einen Leistungsschub mit TPL über Multithreading geben?

Sie speichern 30 Fadenkreationen und die zusätzlichen Konflikte, die Ihre unnötigen Threads verursachen.

Die richtige Lösung für Ihr Problem besteht darin, ein asynchrones Programm zu schreiben, das Threads nicht blockiert. Dies geschieht, indem der Rest der Berechnung nach Abschluss der Downloads als Fortsetzung dargestellt wird, die nach Abschluss des Downloads mit den Daten aufgerufen wird.

Die neue Programmiersprache F # von Microsoft enthält Funktionen, die speziell dafür entwickelt wurden, dies zu vereinfachen. Zum Beispiel kann Ihr Problem mit nur 5 Zeilen Code in F # gelöst werden:

Diese Lösung blockiert niemals einen Thread, daher ist sie vollständig gleichzeitig.