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)

Wie ist denn nun der beste Weg, um
a) Daten vom Hauptthread an den Zielthread zu senden?
b) Daten vom Hauptthread zu holen, wenn dieser die benötigt, sie aber nun mal zur Startzeit des Threads noch nicht existierten oder sich im Programmverlauf verändert haben?

Daten vom Thread in den Hauptthread ist keine Problem, aber meine ursprüngliche Frage zielte auf die beiden o.g. Punkte ab.

Ich habe mir dafür folgendes angewöhnt:
Sowohl der Thread als auch die GUI führen Listen von Daten, die jeweils "Aufgaben" in die entsprechende Richtung sind. Diese Listen sind mit Critical Sections komplett abgesichert.
Wenn der Thread der GUI etwas mitteilen will, werden die Infos in die entsprechenden Listen gepackt und eine Message an das Mainform geposted. (PostMessage(), NICHT SendMessage()!!!) (Wenn die Infos in WParam und LParam passen gerne auch ohne Liste.) Umgekehrt schreibt der GUI Thread einfach in die Listen des Arbeitsthreads, und dieser guckt in seiner Hauptschleife immer nach ob in den Listen Dinge zur Verarbeitung anstehen.

Wenn es nur ein paar Arten von Daten sind, und die Zugehörigkeiten klar ersichtlich, bin ich so faul die Listen in die Form-Klasse bzw. die Thread-Klasse zu legen. Sauberer wäre ein eigenes Kommunikationsobjekt, dass sich dann auch komplett selbst um die Synchronisierung kümmert. (Die ist hier lebensnotwendig.)

Ob dies immer der beste Weg ist will ich nicht beurteilen, und es gibt sicherlich zig andere ähnlich gute Lösungen. Mit dieser fahre ich zumindest bisher sehr gut.