Ist Parallel.ForEach veraltet. alt, aus der Mode?

Question

Guten Tag,

Parallele Ausführung kann durch mehrere Möglichkeiten erreicht werden. Vom rein manuellen "Multithreading" bis zur Verwendung verschiedener "Helfer" von Microsoft. Einer dieser Helfer ist die Parallel-Klasse.

Einer meiner Kollegen besteht darauf, dass Parallel.ForEach (oder Parallel-Klasse insgesamt) ist "alt" und sollte nicht verwendet werden. Stattdessen, sagt er, sollte man asynchrone Operationen verwenden. Mit anderen Worten sollten Sie Task.WhenAll() anstelle von Parallel.ForEach() verwenden.

die Frage, warum Parallel.ForEach(), nicht verwenden, wenn dies ist genau das, was nötig war - mehr teueren Operationen parallel ausgeführt, antwortete er, dass Parallel.ForEach() alt ist und dass Microsoft mit Asynchron/erwarten empfiehlt, wo immer möglich.

Ich suchte überall auf MSDN und Stackoverflow und überall konnte ich, aber ich konnte nichts finden, das auf die Notwendigkeit des Verwendens async/erwarten statt .Parallel verweist. Obwohl Sie oft ähnliche Ergebnisse erzielen können, wenn Sie diese Werkzeuge austauschen, bedeutet dies nicht, dass Parallel.ForEach veraltet ist. Oder tut es?

Jeder hat einen Link zu einigen "Best Practices" oder "Empfehlungen" von einem seriösen Gremium (MSDN?), Das würde sagen, dass Parallel.ForEach() wird auslaufen und man muss mit dem Erstellen, Ausführen und Warten auf Aufgaben bleiben?

Bitte posten Sie keine Antworten zu Parallel VS Async für dies als das ist nicht die Frage.

Die Frage ist: Da Sie können Aufgaben parallel mit Asynchron laufen make/erwarten WhenAll (WaitAll etc.), ist es 'Parallel' Klasse veraltet, alt, oder nicht in Mode in .NET 4.5 weiter machen?

Answer 1

Ich glaube nicht Parallel.ForEach ist veraltet.

Seit Einführung der Task Parallel Library (TPL) mit .NET 4 hat Microsoft distinguished between "Data Parallelism" (e.g. Parallel.ForEach) and "Task Parallelism" (Task). Von MSDN:

• "Datenparallelismus bezieht sich auf Szenarien, in denen der gleiche Vorgang gleichzeitig durchgeführt wird (das heißt, parallel ) auf Elemente in einer Quellensammlung oder Array".
• "[T] fragen Parallelität bezieht sich auf eine oder mehrere unabhängige Aufgaben unter gleichzeitig."

^{(Hervorhebung durch mich wie dcastro commented (above). "Ihr Freund ist verwirrend Parallelität mit Asynchronität.")}

Diese beiden Arten von Parallelität/Parallelität unterschiedliche Ziele verfolgen, so dass die TPL bietet für jede von ihnen unterschiedliche Fähigkeiten.

Konzeptionell gehört Task.WhenAll in die Aufgabe Parallelitätskategorie, also glaube ich nicht, dass es etwas veraltet, das zu der anderen (Datenparallelismus) -Kategorie gehört.

Answer 2

Parallel.ForEach (und PLINQ als Ganzes) verfügt über Fähigkeiten, die nicht in der async Sprachunterstützung verfügbar sind.

Zum Beispiel können Sie den Grad der Parallelität begrenzen (z. B. 100 Elemente zu verarbeiten, aber nicht mehr als 10 zu einer Zeit). So ist es nicht obsolet.

Grundsätzlich async geht es darum, gleichzeitige Operationen - ohne irgendwelche Annahmen von Threading - einfacher zu schreiben. PLINQ beschäftigt sich mit der Berechnung von vielen Kernen.

Ich vermute, dass Ihr Kollege liest zu viel in direkte Verwendung von Task Parallel Library (TPL) mit async in der Sprache weitgehend unnötig (mit Ausnahme der Rückgabetyp von async Funktionen). Aber PLINQ war immer eine andere Schicht als TPL. Wenn etwas PLINQ und async sind zwei separate Möglichkeiten, TPL für verschiedene Zwecke zu verwenden.

Answer 3

async und await haben nichts mit Parallelität zu tun. Sie sind Technologien, mit denen vorhandene asynchrone APIs leichter konsumiert und verfügbar gemacht werden können. async und await keine Parallelität oder Parallelität initiieren. In der Tat await endet Parallelität durch Warten auf etwas, das bereits läuft.

Parallel.ForEach wird verwendet, um eine Reihe von homogenen Objekten auf die gleiche Weise auf mehreren Kernen zu verarbeiten. Sie können Parallel.ForEach simulieren, indem Sie eine große Anzahl von Aufgaben erzeugen. Das hat keinen Vorteil. Tatsächlich führt es Ineffizienzen ein und verschleiert den Code. Es ist möglich und funktioniert, aber es ist eine minderwertige Art, Dinge zu tun, wenn Parallel.ForEach anwendbar ist.

Ich denke, Ihr Kollege versteht nicht, dass warten wirklich nur wartet. Es startet nichts.

Verwenden Sie Parallel. * Und PLINQ (meistens) für CPU-gebundene Arbeit.