Zitat von himitsu:

Zitat:

frm_main.lv_waagen.Items.Count

Und das ist auch threadsave?

Sicherlich nicht. Zumindest zur Zeit. Aber
1. Der Thread ist der einzige der darauf zugreift (weil ich nur einen erzeuge)
2. Auf das lv_waagen wird nach dem Füllen nicht mehr zugegriffen, und dieses passiert definitiv vor dem Erzeugen des Threads.

Mittlerweile habe ich folgendes herausgefunden:

Er bleibt beim FTCPClient.SendCmd hängen, weil: wenn ich die TCP-Verbindung vom Server aus trenne, dann läuft die Schliefe anschließen genau die 6 mal durch, jedoch schlägt dann das senden natürlich fehl.
Mit FTCPClient.IOHandler.Writeln läufts dann durch.
Durch Try Except hab ich das lokalisieren können. Danke himutsi.

Allerdings kann ich nur einmal was empfangen. Also scheint im FTCPClient.IOHandler.InputBuffer.ExtractToString der nächste Fallstick zu liegen.

Zitat von Captnemo:

Zitat von himitsu:

Zitat:

frm_main.lv_waagen.Items.Count

Und das ist auch threadsave?

Sicherlich nicht. Zumindest zur Zeit.

Doch ist er, da alles ja mit Synchronize entsprechend synchronisiert wird

Zitat von Captnemo:

Aber
1. Der Thread ist der einzige der darauf zugreift (weil ich nur einen erzeuge)

Das ist egal. Alles was im Hauptthread erzeugt wird und auf die WinAPI aufsetzt darf auch nur im Hauptthread verwendet werden da sonst die WinAPI nicht mitspielt.
Dort gilt das alls GDI-Objekte nur im erzeugten Thread gültig sind.

Der Zugriff in der for-Schleife erfolgt eben nicht synchronisiert

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.