Von einem Thread aus andere benachrichtigen, aber wie? (Event, Queue, usw.)

Hallo,

ich habe einen Thread, der Daten einliest. Der Thread ist in einer DLL und soll anderen Kollegen zur Verfügung gestellt werden.

Ich weiss nun nicht ganz, wie ich die Daten zur Verfügung stellen soll:

1. Event
   Meine Kollegen könnten die Klasse/Thread starten und sich über einen NewDataReceivedEvent die neuen Daten abholen. Nachteil: Während das Event bzw. die Funktion, die durch den Event ausgelöst wird, ausgeführt ist, ist mein Thread "lahmgelegt". Verwendet der Benutzer in der Event-Funktion eine komplizierte Auswertefunktion, dann ist ja quasi mein Thread solange lahmgelegt.

2. Queue
   Ich könnte einfach neue Daten in eine Queue legen und der Benutzer der DLL kann z. B. über einen Timer alle 50/100ms nachschauen, ob neue Daten da sind. Der Vorteil hier wäre, dass mein Thread und die Anwendung des Kollegen entkoppelt sind.

Wie löst Ihr solche Probleme?
Eigentlich sind für solche Fälle ja Events gedacht aber dann sind der Thread und die Anwendung ja nicht entkoppelt?

Oder sehe ich das falsch?

Danke im Voraus.

feuere das event doch in einem neuen thread.....

Event. Wie der thread auf der anderen seite das von dir angesprochene Problem löst muss deiner klasse egal sein. Du würdest hier ein spezialisiertes problem lösen.

1. Implementier das Abholen der Daten doch asynchron und lock die Daten solange, dann ist dein Thread nicht blockiert.

2. Das wär eine Fuckellösung meiner Meinung nach und vom Design her ein Alptraum

Gruß David

Es ist je nach Anwendungsfall abhängig ob nur bestimmte Funktionen an eine UI weitergeleitet werden sollen (Threadausführung kann fortgesetzt werden) oder aber du möchtest genau über einen definierten Status informieren bzw. sogar über einen Status informieren, der zusätzlich einer Antwort erwartet bzw. die Möglichkeit einer Antwort bietet, Beispiel wäre eine Exception ist aufgetreten.

Für den ersten Fall würd ich eine Queue benutzen. Der Ausführ-Thread schreibt die entsprechenden Stati-Werte in die Queue, die von einem Timer der Gui entsprechend abgefragt wird. Das ganze lässt sich auch gut mit dem Memento-Pattern verbinden. Ein Nachteil wäre, das nur ein Beobachter das ganze auswerten kann (Queue). Bei mehreren müsstest du jeweils mit einer Liste/Array das ganze machen.
Ein schmeißen des Events in dem Thread selbst ist schlecht, da darunter die Performance leitet (sinnloses warten bis die Gui aktualisiert ist). Ein schmeißen in einem seperaten Thread/ThreadPool ist auch schlecht, da du so dein Betriebssystem lahm legst bzw. den ThreadPool verstopfst, wenn du pro Sekunden über geänderte Statusmeldungen informieren möchtest.

Events selber schmeißen nur bei ganz wenigen Statis, das wären beispielsweise Start, Stop/Fertig. Ein anderes Beispiel wo es über Events gehen sollte ist wenn eine Exception aufgetreten ist, wo von extern entschieden werden kann, ob fortgesetzt werden soll oder nicht.

Naja, ich würde sagen es kommt darauf an, wie viele Daten du da einliest. Wenn du für jedes Datenpaket einen eigenen Thread aufmachst, dann kann es passieren, dass du dir einen Heavy Load heraufbeschwörst. In dem Fall wäre natürlich eine Queue das Mittel der Wahl. Der eine Beobachter, den das kleine Eichhörnchen angesprochen hat kann die Pakete ja dann noch weiter verteilen.

Bei wenigen Daten halte ich aber asynchrone Threads auch für eine schöne Lösung, wenn es aber gilt gewisse Peaks abzupuffern, dann ist das genau der Zweck, für den Queues erdacht worden sind.

Hallo peterchen72,

zu 1. Wie du richtige festgestellt hast, laufen Events und EventHandler immer in dem Thread, der den Event feuert. Das kommt also bei dir nicht in Frage.

zu 2. du brauchst keinen Timer, sondern kannst eine synchronisierte Queue verwenden (Applikation mit Warteschlange). Das wäre hier wohl die beste Lösung.

herbivore