Wir hatten mal eine ähnliche Anwendung. Dort sind Daten von Messgeräten eingetroffen, sollten in die
DB und parallel dazu angezeigt werden.
Wir haben es mit Threads und Messages (PostMessage) ausprobiert. Beides funktioniert gleich gut. In meinem Hinterkopf trällert aber immer noch, das man nicht mit Threads nicht um sich werfen sollte. Das kann ein Überbleibsel aus der der Steinzeit sein, aber ich finde Threads hierfür einfach oversized.
Ich würde zunächst das Observer-Pattern einführen, um Datenempfang und Visualisierung auch logisch zu entkoppeln und skalierbar zu machen.
Der Datenempfang implementiert einen Observer, an dem sich Formulare, die Daten anzeigen wollen, anmelden können.
Die Observerbenachrichtigungsschleife ist als Job eines Workerthreads implementiert, der wiederum eine Jobliste (=Queue) abarbeitet. So kann dieser Workerthread (besser : Pool) beliebige Jobs abarbeiten und das System kommt auch bei kurzzeitiger Überlastung nicht ins Schwitzen. Selbst wenn kurzzeitig sehr viele Benachrichtungen anstehen, blockiert der Observer nicht, da dann eben die Jobliste etwas voll wird...
Die Benachrichtigung an die einzelnen Subscriber (=Forms) kann nun als Postmessage verschickt werden. Das ist
imho leichtgewichtiger als noch einen Thread zu starten. Allerdings sind dabei die Einschränkungen von Sebastian zu beachten. Man kann hier die Daten z.B. in eine Datenklasse mit Referenzzählung wrappen (Stichwort: Interface) oder Strings verwenden (z.B. bei einem Logger), der die Referenzzählung auch eingebaut hat.
Das generelle Problem ist hier, das bei Überlastung die Messagequeue der einzelnen Subscriber zu voll werden könnte. Das muss man im Einzelnen bewerten, ob das eine Rolle spielt und wie man damit umgehen kann bzw. soll.
Zitat
Baum-Darstellung
