Synchronisierung von Subthreads (VCL) + Pointerzugriff

[Delphi-Freak]

Das würde mich auch interessieren, wollte gerade einen Beitrag dazu schreiben...
also *PUSH*

LG, ich

[himitsu]

Wenn du den Schreib-/Lesezugriff innerhalb einer Klasse gegenseitig vor gemeinsamen Zugriff irgendwie (gibt ja mehrere Möglichkeiten) (b)locks, dann kannst du sie auch ohne Probleme von mehreren Thread aus ansprechen.

[Delphi-Freak]

War das die Antwort auf das hier, dann steh ich nämlich auf der Leitung...

Zitat:

Zitat von markusj

Ist es möglich, eine ganz normale Klasse einfach zu einenm Thread umzumodden?

LG, ich

[himitsu]

upps, da hab'sch wohl was falsch verstanden (also keine klasse für threads ummodden)

aber zu deiner Frage sollte es doch was geben ... ist in Delphi nicht schon 'ne Thread-Klasse drin?

[Delphi-Freak]

Nein, ich meine man hat irgendeine mehr oder weniger komplexe Klasse, die manchmal etwas länger braucht. Damit das Programm dabei nicht einfriert, und man z. B. den Vorgang abbrechen kann, wäre es gut, das ganze in einen Thread zu verpacken. Das war die Frage - zumindest so wie ich sie verstanden und dann auch "weitergefragt" hab...

LG, ich

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Delphi-Freak

Nein, ich meine man hat irgendeine mehr oder weniger komplexe Klasse, die manchmal etwas länger braucht.

Seit wann geht das denn?!
Eine Klasse braucht nicht lange, ein Task braucht lange. Eine Klasse in einen Thread auslagern zu wollen zeugt davon, irgendwas noch nicht vollständig verstanden zu haben.
Nur mal angenommen mit jeder Methode, die aufgerufen wird, wird ein Kindthread abgespalten und die Methode dort ausgeführt. Der Methodenaufruf würde dann sofort zurückkehren. Und wann zerstörst du das Objekt? Nachdem der Call zurückkehrt? Damit reißt du dem Thread das Objekt, auf das er arbeitet, unter den Füßen weg. Wartest du auf das Beenden des Threads? Dann hast du auch nichts gewonnen, weil du blockierend wartest oder mit ProcessMessages() periodisch die Nachrichtenschleife abarbeitest, und das kannst du auch direkt im Task machen. Gar nicht? Dein Anwender wird es dir danken.
Thread-Modelle und Klassenmodelle beißen sich prinzipbedingt. Das leuchtet ein, wenn man beispielsweise Äpfel mit Birnen vergleicht. Ein Thread ist ein Scheduler-Element, das die zeitliche Verarbeitung von Code regelt. Eine Klasse ist ein logisches, vollständig abstraktes Element, das Daten und Code beinhalten kann, und zwar Code mit mehreren Einsprungpunkten (viele Methoden). Es ergibt wenig Sinn, eine abstrakte Informationsgliederung in eine zeitliche Regelung zu packen, es würde ja ohnehin nichts passieren.
Das Problem, vor dem du stehst, ist nicht, daß deine "Klasse lange braucht", sondern daß dein Task lange braucht. Die Lösung des Problems hast du in eine Klasse gekapselt, aber die Klasse alleine führt noch nicht den Task aus. Also mach es richtig und lagere den Task in einen Thread aus, und nicht die Lösung des Problemes. Starte einen Thread und führe in ihm den Code aus, der das Objekt instanziert, initialisiert, den Task erledigt und wieder ordentlich aufräumt. Am Ende kannst du eine Message an den Hauptthread schicken, um in dessen Kontext den Anwender über das Ergebnis des Tasks zu benachrichtigen.

Zitat:

Zitat von markusj

Kann ich dann auf dessen Methoden zugreifen, und wenn ja, werden die dann im Hauptthread oder im Subthread ausgeführt?

Code wird in dem Kontext ausfgeführt, in dem er aufgerufen wird. Wenn du in Thread A eine Methode eines Objektes aufrufst, wird diese Methode auch in Thread A ausgeführt.

[Delphi-Freak]

Ja, das ist mir (zumindest nach dem Lesen :mrgreen: ) schon klar, es geht im Konkreten um eine von IdFTP abgeleitete Komponente. Nachdem ja das Verbindungs-Aufbauen etc. länger braucht und dann das Formular einfriert, möchte ich alle Kommunikation mit dem Server in einem eigenen Thread machen. Jetzt gibt es die eine Möglichkeit, in einer von TThread abgeleiteten Klasse alle wichtigen Funktionen (Connect, aber auch Put, Get etc.) nochmals zu deklarieren und dort dann die Parameter in Feldern zwischenspeichern und dann eine Variable auf 'connect' oder einen bestimmten Index setzen, die die Execute-Prozedur in einer while-Schleife immer wieder abfragt und demnach dann die Connect-Funktion der IdFTP-Klasse aufruft.
Gibt es da dann eine bessere Methode? :roll:

LG, ich

[Frickeldrecktuxer_TM]

Zitat:

Zitat von Delphi-Freak

Gibt es da dann eine bessere Methode? :roll:

Als dieses Polling? Aba sischa.
Den Thread starten und ihm eine Message-Loop verpassen. GetMessage() ist synchron und blocking, also vergeudest du damit nichtmal Ressourcen, selbst wenn es auf den ersten Blick nach Polling aussieht. Für ein Beispiel brauchst du dir nur ein beliebiges nonVCL-Programm anzuschauen. Dem Thread postest du mit PostThreadMessage() deine Messages, und dieser arbeitet sie ab. Die Message-Queues arbeiten in-order, das heißt du ganz erstmal eine Connect- und eine Get-Message abschicken, die Get-Message wird bearbeitet, sobald das Connect fertig ist. Der Thread reagiert also auf jede Nachricht, die er bekommt, dein Hauptthread läuft aber weiter. Damit die Oberfläche etwas davon mitgekommt, was der Thread gerade tut, kann der Thread ebenfalls Nachrichten an deinen Haupt-Thread (oder besser: irgendein Fenster, dann hast du Unterstützung durch Delphis message-Schlüsselwort), in denen er mitteilt, daß gerade die Verbindung etabliert wurde oder daß er gerade x Bytes empfangen hat und sie dort und dort hinterlegt sind, damit der Thread die empfangenen Daten entgegennehmen kann.
Kurzum: Alles, was du bei normaler IPC anwendest, kannst du auch bei prozessinternen Threads anwenden, oft ist es nicht verkehrt.

[Delphi-Freak]

Aha! Aber gibt es auch was einfacheres, außer jetzt alle Methoden nochmals zu implementieren? Also dass man das gleich für alle Methoden einer Klasse macht? Anscheinend nicht - oder doch :coder2:

LG, ich

Edit: Oder gibt es wenigstens eine Möglichkeit, einen Pointer auf die Methode und einen Pointer auf alle Parameter zu speichern und die Methode mit Parametern nachher so aufzurufen?

[markusj]

@Frickeldrecktuxer_TM ... ich habe die Thread-Materie sehr wohl verstanden.
Und ich habe mir gedanken gemacht, bevor ich diese Frage stellte ...
in meinem Programmkontext macht das Auslagern ganzer Klassen Sinn, damit der Benutzer mit anderen Programmteilen arbeiten kann, während sich meine Thread-Klassen-Hybrid selbst verwaltet und nach der Ausführung auf die nächste Aufgabe wartet ...
Ich habe meinen Grund für diese Idee ... aber danke für die Antworten (und an Gerhard Pfister danke fürs Pushen, ich hatte den Thread schon beerdigt ...)

mfG

Markus

*einbisschensauer*

EDIT: @Gerhard ... vielleicht kapselst du den Thread in ein Objekt, welches den Statues des Threads kontrolliert und bei Bedarf an das Hauptprogramm weiterleitet ... als eine Art Dolmetscher ... oder Vermittler