Also wenn ich TThread.Sleep(2) vor Synchronize() setze, dann funktioniert alles.

markieren

Delphi-Quellcode:

  IF ( I1 >= 1000 ) THEN
        BEGIN
          TThread.sleep(2);
          Inc( I2 );

          Synchronize(

Muss man das so machen, dass das Synchronize() genug Zeit bekommt?

Bei mir ist es halt lediglich 1x synchronize und zwar wenn der thread mit seiner Arbeit durch ist.

Also, MainThread erzeugt eine Klasse mit einem OnEvent für den MainThread, die Klasse erzeugt einen Thread mit einem OnEvent für die Klasse, das Klassen-Event gibt dem MainThread Event bescheid wenn es fertig ist.
Von der Logik her denke ich das es so korrekt ist.

Mit WinAPI Threads habe ich dieses Phänomen nicht, da wird nicht der MainThread blockiert obwohl es von der Sache her der gleiche ablauf ist (nur halt per PostMessage als ersatz für OnEvent).

Da ich wirklich nur 1x sync mache denke ich das dies bei mir nicht der Fehler ist, aber ich werde es später gerne mal testen.

Ich denke hier liegt das Problem:

markieren

Delphi-Quellcode:

  FMy_Thread2 := TTheThread2.Create;
  FMy_Thread2.OnChange := DoOnChange; { ! }

Der Thread wird erzeugt und läuft gleich los, aber das OnChange ist noch nicht gesetzt.

Versuch mal dies:

markieren

Delphi-Quellcode:

  FMy_Thread2 := TTheThread2.Create(False);
  FMy_Thread2.OnChange := DoOnChange; { ! }
  FMy_Thread2.Start;

BTW, die Zugriffe aus dem Thread auf frm_Main halte ich für gefährlich, während die Zugriffe auf frm_Main in den Methoden von Tfrm_Main lediglich kontraproduktiv sind.

DoOnChange als Parameter ans Create übergeben?

Kann OnChange zur Laufzeit des Threads sich ändern? (theoretisch ja, da public Property ohne abgesicherten Setter)
Und wenn, passiert das dann auch definitif immer nur im Hauptthreads?

Wenn es sich nicht ändern kann/soll, dann darf das nicht als Property ungesichert öffentlich zugänglich sein.

Und wenn es sich nie während der Threadlaufzeit ändern kann, dann IF-Assigned vor das Synchronize, da bei NIL sonst immer sinnlos Synchronize ausgeführt wird und bremst.

markieren

Delphi-Quellcode:

        IF Assigned( FOnChange ) THEN
          Synchronize(
            PROCEDURE
            BEGIN
              FOnChange( Self, I1, I2 ); // Beispiel
            END );

Das "IF Assigned(FOnChange)" vor dem Synchronize kann man zwar zusätzlich prüfen.
Verlassen kann man sich darauf allein aber nur, wenn FOnChange nicht von außen durch den Haupthread verändert werden kann.
Also kein Property dafür existiert, sondern der Wert z.B. als Parameter dem Constructor übergeben wurde.

Der Hauptthread führt die synchronisierte Prozedur erst beim nächsten Processmessages() aus.
Inzwischen könnte FOnChange aber durch den Hauptthread auf nil gesetzt worden sein, was dann zur Zugriffsverletzung führt.
Deshalb würde ich solche Property immer auch in der synchronisierten Prozedur prüfen und den Zugriff mit einer CriticalSection absichern.

Wurde zwar eigentlich bereits gesagt, aber ist leicht zu überlesen.

Auch wenn das dann irgendwie doppelt ist würde das dann helfen:

markieren

Delphi-Quellcode:

 
IF Assigned( FOnChange ) THEN
  Synchronize(
    PROCEDURE
    BEGIN
      if Assigned( FOnChange ) then
        FOnChange( Self, I1, I2 ); // Beispiel
    END );

Dein TTheThread2 hat uMain in den Uses.

Das ist nicht so gut. Sollte auch ohne gehen. Dann ist der Thread wirklich für sich.

Sonst könntest du Synchronize ganz weg lassen da du ja auch frm_Main.gb_ist_Thread2_aktiv := True; machst.

Könntest auch frm_Main.CounterLabel2.Caption := CurrentValue.ToString; direkt im tread machen.

@Uwe,
Wenn ich das so anwende bekomme ich folgenden Fehler:

Zitat:

---------------------------
Benachrichtigung über Debugger-Exception
---------------------------
Im Projekt Thread_Tech_Demo.exe ist eine Exception der Klasse EThread mit der Meldung 'Start kann für einen laufenden oder unterbrochenen Thread nicht aufgerufen werden' aufgetreten.
---------------------------
Anhalten Fortsetzen Hilfe
---------------------------

@himitsu,
Das Assigned( FOnChange ) vor Synchronize zu setzen klingt generell logisch, behebt aber das Problem nicht.
Es ist ja ein worst case Fall mit der while-Bedingung. Da werden riesige Mengen von Events ausgelöst, was auch völlig unnötig ist. Daher habe ich das jetzt so gelöst:

zusammenfalten · markieren

Delphi-Quellcode:

          IF ( I2 mod 10000 ) = 0 THEN { ! sonst blockiert auf Grund der schieren Menge von Events das Hauptprogramm }
          BEGIN
            IF Assigned( FOnChange ) THEN
            BEGIN
              Synchronize(
                PROCEDURE
                BEGIN
                  FOnChange( Self, I1, I2 ); // Beispiel
                END );
            END;
          END;

@Blup,

Zitat:

Wurde zwar eigentlich bereits gesagt, aber ist leicht zu überlesen.

Wenn man sich nicht auskennt ist es schwierig das alles so zu deuten.
Mir (uns) Neulingen in diesem Thema würde am besten ein fertiges *korrektes* Beispiel helfen. Es geht mir persönl. hier um Grundlagen für die Zukunft, die ich mir auch gerne weiter erarbeite, aber von allein kommt man da nur schwer drauf.

Schon mal vielen Dank bis hierher!

Edit: Ich hab hier mal mein jetzigen Stand angehängt.

Zitat von juergen:

@Uwe,
Wenn ich das so anwende bekomme ich folgenden Fehler:

Na klar! Das muss ja auch True heißen:

markieren

Delphi-Quellcode:

  FMy_Thread2 := TTheThread2.Create(True);
  FMy_Thread2.OnChange := DoOnChange; { ! }
  FMy_Thread2.Start;

Hallo zusammen,

Zitat:

Wenn man sich nicht auskennt ist es schwierig das alles so zu deuten.
Mir (uns) Neulingen in diesem Thema würde am besten ein fertiges *korrektes* Beispiel helfen. Es geht mir persönl. hier um Grundlagen für die Zukunft, die ich mir auch gerne weiter erarbeite, aber von allein kommt man da nur schwer drauf.

Ist das von #Jürgen gepostete Beispiel nun das erwähnte *korrekte* Beispiel für die gestellte Aufgabe oder sind da noch Verbesserungen angezeigt?