Zitat von Captnemo:

Klingt logisch und einfach. Ist es sicherlich auch, wenn mal mit Threads viel Erfahrung hat. Leider muß ich da noch viel lernen und die Umsetzung fällt einem dann nicht immer so leicht.
Das mit Assigned(TThread(Sender).FatalException) hab ich grad mal gar nicht verstanden.

Schau dir mal das OnTerminate-Event des TThread an. Das ist wie das OnClick der TButtons und im Sender steckt die Instand des angeklickten Buttons, also in diesem Fall natürlich die Instanz des beendeten Threads.

Ich weiß ja nicht wie ud wo die die Instanz deines Threads gespeichert hast, aber das ist ja egal, da der Sender immer passt und man die Instanz somit auch da auslesen kann.
Man muß halt nur das TObject in den richtigen Typen casten, wenn man das verwendet.


Ergebnis: Du erstellst dir eine passende Methode, rufst darin das Syncronize und auf darin dann den genannten Code.
Und nun natürlich nur noch das Event dem Thread zuweisen.

markieren

Delphi-Quellcode:

procedure TDeineForm{oder dein TThread-Nachfahre}.MyThreadTerminate(Sender: TObject);
begin
  // TThread(Sender).Synchronize nehm ich jetzt mal nicht, da der Thread ja eigentlich schon beendet ist
  // und ich jetzt nicht genau weiß, ob was passieren könnte, auch wenn es vermutlich doch funktionieren könnte
  TThread.Synchronize(nil, procedure
    begin
      if Assigned(TThread(Sender).FatalException) then
        ShowException(Exception(TThread(Sender).FatalException), nil);
    end);
end;

PS: Wäre es nicht besser, wenn dein WriteLog im inneren prüft, ob es im Hauptthread läuft und sich notfalls selber synchroonisiert?
(oder notfalls einfach immer blind synchronisieren ... das Synchronize prüft das intern bestimmt auch selber nochmal)
Würde das Logging vereinfachen und so einige Codezeilen sparen.

Wird der TCPClient im Thread-Kontext erzeugt? Achtung: Im Thread-Konstruktor erzeugte Dinge sind nicht im Thread-Kontext, sondern in dem des Hauptthreads!!! Die meisten Komponenten, die irgendwie mit Sockets und ähnlichen WinAPIs hantieren sind oft nur in dem Kontext zu benutzen, in dem sie auch erstellt wurden. Ich bin damit schon mal mit SQL-Komponenten übel auf die Nase gefallen. Du musst diese in der Execute-Methode erstellen.

Dies ist zumindest eines der potenziellen Probleme die mir noch aufgefallen sind, das andere wurde schon genannt.

Zitat von Medium:

Wird der TCPClient im Thread-Kontext erzeugt? Achtung: Im Thread-Konstruktor erzeugte Dinge sind nicht im Thread-Kontext, sondern in dem des Hauptthreads!!! Die meisten Komponenten, die irgendwie mit Sockets und ähnlichen WinAPIs hantieren sind oft nur in dem Kontext zu benutzen, in dem sie auch erstellt wurden. Du musst diese in der Execute-Methode erstellen.

Die Internet Direct (Indy) TCP Clientkomponenten können aus mehreren Threads verwendet werden, solange der Zugriffe threadsafe erfolgt. Ein Beispiel ist der Telnet Client "TIdTelnet" im Lib/Protocols Verzeichnis. Diese Klasse ist abgeleitet von TIdTCPClientCustom und startet einen Thread (TIdTelnetReadThread), der die vom Server gesendeten Daten empfängt. Die TIdTelnet Instanz wird zwar im Mainthread erzeugt, und aus dem Mainthread werden Befehle an den Server gesendet, aber aus dem ReadThread wird kontinuierlich auf den IOHandler der Komponente zugegriffen.

Möglicherweise besteht die Beschränkung (Verwendung nur im erzeugenden Thread) bei plattformgebundenen Komponenten wie ICS, die ein Windows Fensterhandle benötigen - aber mit ICS habe ich zuletzt 2008 kurz Kontakt gehabt.

Zitat von Sir Rufo:

Der Zugriff in der for-Schleife erfolgt eben nicht synchronisiert

Die erste Verwendung von frm_main.lv_waagen.Items.Count-1 ist nicht synchronisiert, die zweite schon.

Wobei diesesa andauernde Zugriff auf frm_main (und dann auch noch globale Variable ) sagen wir mal: potential zur Verbesserung bietet.

Zitat von Bernhard Geyer:

Zitat von Sir Rufo:

Der Zugriff in der for-Schleife erfolgt eben nicht synchronisiert

Die erste Verwendung von frm_main.lv_waagen.Items.Count-1 ist nicht synchronisiert, die zweite schon.

Warum?

Zitat von Bernhard Geyer:

Wobei diesesa andauernde Zugriff auf frm_main (und dann auch noch globale Variable ) sagen wir mal: potential zur Verbesserung bietet.

Wie kann man denn besser innerhalb des Threads auf Variablen / Daten des Hauptthreads (oder möglichweise auch anderen Threads) zugreifen?

Ich kenne bisher nur die Möglichkeit Daten an den Hauptthread mit Synchronize sicher zu übergeben.
Geht das mit Funktionen auch? Ich kenne das nur mit procedure.

Zitat von Captnemo:

Zitat von Bernhard Geyer:

Zitat von Sir Rufo:

Der Zugriff in der for-Schleife erfolgt eben nicht synchronisiert

Die erste Verwendung von frm_main.lv_waagen.Items.Count-1 ist nicht synchronisiert, die zweite schon.

Warum?

Weil du das so programmiert hast?

zusammenfalten · markieren

Delphi-Quellcode:

      FCS.Acquire;
      // nicht synchronisierter Zugriff auf eine VCL-Komponente
      for I := 0 to frm_main.lv_waagen.Items.Count-1 do
      begin
        Synchronize(
          Procedure
          begin
            // hier ist es synchronisiert
            frm_main.Writelog('Sende Register '+inttostr(i)+' von '+inttostr(frm_main.lv_waagen.Items.Count-1));
          end
        );
        FTCPClient.SendCmd('Register:'+frm_main.lv_waagen.Items[i].SubItems[2]+':@');
      end;
      FCS.Release;

Zitat von Captnemo:

Zitat von Bernhard Geyer:

Wobei diesesa andauernde Zugriff auf frm_main (und dann auch noch globale Variable ) sagen wir mal: potential zur Verbesserung bietet.

Wie kann man denn besser innerhalb des Threads auf Variablen / Daten des Hauptthreads (oder möglichweise auch anderen Threads) zugreifen?

Ich kenne bisher nur die Möglichkeit Daten an den Hauptthread mit Synchronize sicher zu übergeben.
Geht das mit Funktionen auch? Ich kenne das nur mit procedure.

Ab besten gar nicht, sondern man übergibt dem Thread die Informationen, die er zum Laufen braucht und der arbeitet das ab.

Zitat von Sir Rufo:

Zitat von Captnemo:

Zitat von Bernhard Geyer:

Zitat von Sir Rufo:

Der Zugriff in der for-Schleife erfolgt eben nicht synchronisiert

Die erste Verwendung von frm_main.lv_waagen.Items.Count-1 ist nicht synchronisiert, die zweite schon.

Warum?

Weil du das so programmiert hast?

Ach so, jetzt hab ich verstanden, was Bernhard damit meinte. Der zweite Aufruf von frm_main.lv_waagen.items.count ist ja für meinen Programmablauf nicht kritisch und diente lediglich den Protokollzwecken.

Gut, ich sollte vielleicht die gesamte Schleife synchronisieren.

Zitat von Sir Rufo:

zusammenfalten · markieren

Delphi-Quellcode:

      FCS.Acquire;
      // nicht synchronisierter Zugriff auf eine VCL-Komponente
      for I := 0 to frm_main.lv_waagen.Items.Count-1 do
      begin
        Synchronize(
          Procedure
          begin
            // hier ist es synchronisiert
            frm_main.Writelog('Sende Register '+inttostr(i)+' von '+inttostr(frm_main.lv_waagen.Items.Count-1));
          end
        );
        FTCPClient.SendCmd('Register:'+frm_main.lv_waagen.Items[i].SubItems[2]+':@');
      end;
      FCS.Release;

Zitat von Captnemo:

Zitat von Bernhard Geyer:

Wobei diesesa andauernde Zugriff auf frm_main (und dann auch noch globale Variable ) sagen wir mal: potential zur Verbesserung bietet.

Wie kann man denn besser innerhalb des Threads auf Variablen / Daten des Hauptthreads (oder möglichweise auch anderen Threads) zugreifen?

Ich kenne bisher nur die Möglichkeit Daten an den Hauptthread mit Synchronize sicher zu übergeben.
Geht das mit Funktionen auch? Ich kenne das nur mit procedure.

Ab besten gar nicht, sondern man übergibt dem Thread die Informationen, die er zum Laufen braucht und der arbeitet das ab.

Ab besten gar nicht ist toll. Nur in meinem Fall nicht möglich. Er baut beim erzeugen eine TCP-Verbindung auf, die während seiner Lebensdauer erhalten bleiben muss. Und in dieser muss er Daten über TCP empfange und ans Hauptprogramm weiterleiten, bzw. dort proceduren Auslösen und umgekehrt auch Daten vom Hauptprogramm empfangen, die er dann über TCP zu seinem Verbindungspartner weiterleitet.
Möglicherweise geht das nur über Messages.

Weiterleiten und empfangen hört sich gut an, dann mach das doch auch so.

Der Thread empfängt aber z.B. nicht, sondern greift lustig in die GUI und bedient sich.

Ein Control missbraucht man auch nicht als Datenspeicher, sondern als interaktives Element zum Anzeigen und Erfassen.

Zitat von Captnemo:

Ach so, jetzt hab ich verstanden, was Bernhard damit meinte. Der zweite Aufruf von frm_main.lv_waagen.items.count ist ja ...

Nicht ganz.

Die For-Schleife liest erst alles aus und speichert sich den End-Wert zwischen.
Die Start- und End-Werte werden also immer nur einmal zu Beginn abgerufen.
Manchmal läuft die Schleife "intern" sogar rückwärts, da ein Vergleich mit 0 einfacher ist und man sich dafür nicht den Endwert extra speichern muß.

Zitat:

Manchmal läuft die Schleife "intern" sogar rückwärts, da ein Vergleich mit 0 einfacher ist und man sich dafür nicht den Endwert extra speichern muß.

Mit abw. Grenzen bis 0 (jz)