Multithreading

Hallo

ich hab soeben eine Berechnung über eine Ableitung von TThread quasi ausgelagert und kommuniziere mit dem entsprechenden Formular über abgesicherte Queues.
Das scheint soweit gut zu funktionieren.

Nun meine Frage:

Kann man auch die Visualisierung / Interaktion mittels verschiedener Komponenten durch einen gesonderten Thread treiben lassen.

Also quasi aus jedem Formular eine abgeschlossene Umgebung machen, die mit anderen (außerhalb) nur mittels abgesicherter Queues kommuniziert, und durch einen eigenen Thread getrieben wird?

ist das möglich oder kommt einem da die möglicherweise ungesicherte komplexe Eventlogik der VCL-Komponenten in die Quere?

Z.B. die Visualisierung einer Paintbox wird ja von außen (außerhalb der Applikation ) auch getriggert ( z.B. OnPaint Event ). Würde das z.b. reichen, wenn ich den Inhalt des OnPaint-Events synchronisiere, d.h. gegen doppelte gleichzeitige Zugriff absichere?

Anmerkung: Borland C++ 6.0 EE

Zero01

Warum denn nicht anders herum:
Der Thread erzeugt das Formular und ist somit gekapselt und die VCL Geschichten kannst du ja in deinem Thread synchronisieren damit es nicht zu Zugriffsverletzungen führt. Das hab ich vor 7 Jahren das letzte mal gemacht aber hab es noch als sehr gut Umsetzbar in Erinnerung

So herum geht es natürlich auch noch.

Die Frage ist nur, ob das Eventsystem mit Threading klarkommt. Könnte ja sein, dass die VCL-Komponenten dafür gar nicht ausgelegt sind, weil jeder irgendwie mit jedem herumfummelt und dadurch z.B. doppelte Zugriffe auf Daten auftreten.

Wie würde man denn bei der Synchronisierung vorgehen. Z.B. beim OnPaint-Event? Einfach nur ne CritSect reinlegen und gut ist?

DocShoe

Nein, das funktioniert nicht. Die VCL ist nicht threadsafe und IIRC muss alles, was irgendwie mit der GUI zu tun hat, im Hauptthread der Anwendung passieren.

Ja sowas in der Richtung hab ich befürchtet...

Schade eigentlich.
Ich finde es gut, wenn man sich wirklich echt abgeschlossenen Objekte bauen kann, die genau ihre Aufgabe erledigen und die mit Außenwelt nur über Queues kommunizieren. Macht zwar möglicherweise einige Dinge komplizierter, verringert aber die Fehlerquote und unterstützt ein sauberes Design. Das saubere Design geht natürlich auch ohne Extrathreads, aber es ist irgendwie nicht dasselbe...

Mich würde die Verwendung der Queues interessieren. Um genauer zu sein: Welche Art von Objekten hast Du wie übergeben? Auto- oder Smart-Pointer? Echte Objekte? Ich hab mir damals echt einen abgebrochen um simple (Ansi-) Strings zwischen Threads auszutauschen... Seeeeehr unschöner Code... Aber ebenfalls BCB 6, wenn ich deine Versionsangabe richtig lese.

Als Transportobjekte für meine Queues benutze ich eine Klasse, die als Basisklasse nur einen MessageTyp (int) enthält und instantiierbar ist ( nicht abstrakt oder so ). Alle weiteren Transportobjekte leite ich davon ab. Keine Auto/Smartpointer im Einsatz. Alles echte Objekte. Bisher Problemlos. Die Queues sind spezielle Queues und werden bei uns in der Abteilung für allem im Serverbereich ( Kursdatenströme, bis 100.000 Msg/sec ) eingesetzt. Aber für die Frontendentwicklung missbrauche ich die gelegentlich auch, wenngleich das vielleicht etwas oversized ist.