Aktualisierung und SendMessage

[Furtbichler]

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.

[jaenicke]

Zitat von Furtbichler:

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.

Ob der Overhead der Messagebehandlung da wirklich so viel geringer ist?

Messages sind jedenfalls gerade bei größerem Datenaufkommen ungeeignet, da alles über einzelne Nachrichtenwarteschlangen läuft. Wenn diese dann zu stark belastet werden, merkt man das an einer etwas träge auf Eingaben reagierenden Anwendung, da die dazu gehörenden Nachrichten entsprechend langsamer behandelt werden können. Zudem kann es sein, dass eine Nachricht länger braucht bis sie abgearbeitet wird und so die Aktualisierung aller Fenster laggt.

Davon ganz abgesehen kann man mit Messages erst einmal nur zwei Zahlenwerte schicken. Alles andere läuft dann als Pointer- und Speicherspielerei. Ein Thread hingegen kann typsicher und sauber direkt mit den Daten arbeiten, diese aufbereiten und gezielt an die passenden Empfänger weitergeben.

[yogie]

vielen Dank!
Das ist genau die Art Beiträgen die mich weiterbringen.
(keine Ironie!!) Man ist als Einzelkämpfer immer dankbar,
wenn mal Anregungen mit einem anderen Blickwinkel kommen.
Sonst kopiert man nur immer wieder die Vorgehensweise,
die man schon vor 5 Jahren entwickelt hat.

@Furtbichler : Diese Ausführungen sind (zumindest für mich)
schon ein ziemlich großes Geschütz, trotden danke für die
ausfühliche Antwort. Ich werde das mal durchgehen und
schauen, was davon in meinem Fall verwertbar und macbar ist.

Für alle die es interessiert : Es werden Ströme und Spannungen
unter bestimmten Bedingungen gemessen (Elektrochemie, Potentiostaten)
Das Ganze findet eventuell auch noch auf mehreren Kanälen statt
und soll per serieller Schnittstelle (ev. Netzwertk) an einen
PC gekopplet werden.

[Furtbichler]

Zitat von jaenicke:

Ob der Overhead der Messagebehandlung da wirklich so viel geringer ist?
...Messages sind jedenfalls gerade bei größerem Datenaufkommen ungeeignet

Kann ich nicht bestätigen. Bei einer Implementierung eines Loggers wurden auch mehrere Tausend Messages pro Sekunde nicht langsamer abgearbeitet als per Thread. Der Bottleneck war hier eindeutig die Darstellung (wie immer).