Wenn ThreadPool, Task Parallel Library und async/await nicht das Ziel sind

Der rote Faden

Jonathan Naumann


.NET bietet eine Vielzahl an mächtigen und vielseitig einsetzbaren Bausteinen für die asynchrone threadbasierte Entwicklung. Jede Version des Frameworks brachte einen neuen Baustein mit – den ThreadPool, die Task Parallel Library (TPL) und seit Neuestem async/await. Diese Bibliotheken sind allesamt extrem mächtig und bieten viele Vorteile. Gleichzeitig nehmen sie uns aber auch viel Arbeit ab, indem sie viel bzw. sogar fast alles selbstständig unter der Haube machen.

In den meisten Fällen reicht aber noch heute der „normale“ Thread, um Aufgaben asynchron abarbeiten zu lassen. Die hier vorgestellte Klasse bietet genau dies an: eine Methode zur Bearbeitung einer Aufgabe in einer selbstbestimmten Anzahl an Threads. Komplizierte Implementierungen des Aufrufs, wie z. B. für Namespaces in XML nötig, wollen wir verhindern. Zur Verwendung der Klasse soll möglichst wenig Quellcode in der eigenen Anwendung benötigt werden.

Dabei ist nur zu beachten, dass jeder Thread die übergebene Funktion jeweils genau einmal asynchron ausführt. Daher ist der MiniThreadPool natürlich nur für solche Aufgaben gedacht, bei denen es z. B. gilt, eine bestimmte Anzahl an Aufgaben abzuarbeiten. Hierfür eignen sich besonders lange Suchalgorithmen, große und aufwändige Berechnungen (z. B. für jede Aktie eines Fonds bestimmte Zahlen zu berechnen) oder vergleichbare Aufgaben.

Warum nicht der .NET-ThreadPool?

Natürlich stellt sich hier ernsthaft die Frage, warum wir nicht einfach den .NET-eigenen ThreadPool verwenden. Schließlich soll die Verwendung in unserer Anwendung einfach sein und die Verwaltung der Threads ähnlich gut organisiert wie der Garbage Collector.

Der ThreadPool ist ein konfigurierbares Konstrukt. Die Standardwerte liegen bei 1 000 Eingabe-/Ausgabethreads und 25 Arbeitsthreads pro Prozessor (hier zählen auch die Kerne mit). Jeder Thread wird dabei intern bis zu zwei Minuten am Leben gehalten, was natürlich sehr effektiv und ressourcenschonend ist.

Unsere Implementierung arbeitet genauso. Es wird nur die gewünschte Anzahl an Threads erstellt und dann auch nur diese verwendet. Sie werden dabei als Worker-Threads betrachtet, eigene Eingabe-/Ausgabethreads sind nicht nötig. Aber ein eigener ThreadPool bietet eine ganze Reihe an Vorteilen, die wir uns zunutze machen wollen. Folgende Punkte stehen dabei besonders im Fokus:

einfachere Nutzung des Poolseinfache Konfiguration durch Angabe der gewünschten Threadslange Berechnungen werden nicht wie beim .NET-ThreadPool blockiertdie Threads ar...

Wenn ThreadPool, Task Parallel Library und async/await nicht das Ziel sind

Der rote Faden

Jonathan Naumann


.NET bietet eine Vielzahl an mächtigen und vielseitig einsetzbaren Bausteinen für die asynchrone threadbasierte Entwicklung. Jede Version des Frameworks brachte einen neuen Baustein mit – den ThreadPool, die Task Parallel Library (TPL) und seit Neuestem async/await. Diese Bibliotheken sind allesamt extrem mächtig und bieten viele Vorteile. Gleichzeitig nehmen sie uns aber auch viel Arbeit ab, indem sie viel bzw. sogar fast alles selbstständig unter der Haube machen.

In den meisten Fällen reicht aber noch heute der „normale“ Thread, um Aufgaben asynchron abarbeiten zu lassen. Die hier vorgestellte Klasse bietet genau dies an: eine Methode zur Bearbeitung einer Aufgabe in einer selbstbestimmten Anzahl an Threads. Komplizierte Implementierungen des Aufrufs, wie z. B. für Namespaces in XML nötig, wollen wir verhindern. Zur Verwendung der Klasse soll möglichst wenig Quellcode in der eigenen Anwendung benötigt werden.

Dabei ist nur zu beachten, dass jeder Thread die übergebene Funktion jeweils genau einmal asynchron ausführt. Daher ist der MiniThreadPool natürlich nur für solche Aufgaben gedacht, bei denen es z. B. gilt, eine bestimmte Anzahl an Aufgaben abzuarbeiten. Hierfür eignen sich besonders lange Suchalgorithmen, große und aufwändige Berechnungen (z. B. für jede Aktie eines Fonds bestimmte Zahlen zu berechnen) oder vergleichbare Aufgaben.

Warum nicht der .NET-ThreadPool?

Natürlich stellt sich hier ernsthaft die Frage, warum wir nicht einfach den .NET-eigenen ThreadPool verwenden. Schließlich soll die Verwendung in unserer Anwendung einfach sein und die Verwaltung der Threads ähnlich gut organisiert wie der Garbage Collector.

Der ThreadPool ist ein konfigurierbares Konstrukt. Die Standardwerte liegen bei 1 000 Eingabe-/Ausgabethreads und 25 Arbeitsthreads pro Prozessor (hier zählen auch die Kerne mit). Jeder Thread wird dabei intern bis zu zwei Minuten am Leben gehalten, was natürlich sehr effektiv und ressourcenschonend ist.

Unsere Implementierung arbeitet genauso. Es wird nur die gewünschte Anzahl an Threads erstellt und dann auch nur diese verwendet. Sie werden dabei als Worker-Threads betrachtet, eigene Eingabe-/Ausgabethreads sind nicht nötig. Aber ein eigener ThreadPool bietet eine ganze Reihe an Vorteilen, die wir uns zunutze machen wollen. Folgende Punkte stehen dabei besonders im Fokus:

einfachere Nutzung des Poolseinfache Konfiguration durch Angabe der gewünschten Threadslange Berechnungen werden nicht wie beim .NET-ThreadPool blockiertdie Threads ar...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang