Soc hat folgendes geschrieben : |
| nun, sicherlich könnte ich alle Aufgaben in einen Thread durchführen, würde aber den Thread extrem aufbläahen und hilft bei der Übersicht nicht besonders. |
Huch? Wenn die Entscheidung, welche Methode in welchem Thread laufen soll, dein Design beeinflusst, hast du imho etwas falsch gemacht

. Jeder andere Ansatz kann in puncto Threading jedenfalls nur wesentlich komplizierter werden.
Es gibt sicherlich Probleme, bei denen "Ein Thread pro Schritt" Sinn macht, bin nur nicht überzeugt, dass das bei dir zutrifft

. Die Lösung für solche Fälle heißt
BlockingCollection<T> - jedenfalls ab .NET 4.0

. In
diesem Paper (das insgesamt nur zu empfehlen ist

) findest du auf Seite 52 eine Implementierung einer ähnlichen Klasse:
C#-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18:
| class BlockingQueue<T> { private Queue<T> _queue = new Queue<T>(); private Semaphore _semaphore = new Semaphore(0, int.MaxValue); public void Enqueue(T data) { if (data == null) throw new ArgumentNullException("data"); lock (_queue) _queue.Enqueue(data); _semaphore.Release(); }
public T Dequeue() { _semaphore.Wait(); lock (_queue) return _queue.Dequeue(); } } |
Die kannst du als Basis für ein Producer/Consumer-Schema benutzen: Ein Thread schiebt per Enqueue Daten an den nächsten, der durch Dequeue am anderen Ende darauf wartet.