Zitat:

Versuche mal an die Aufgabenstellung erst mal anders ranzugehen.

Ich würde auch diesen Quatsch mit DoIt weglassen. Geb den Dingern entweder richtige Namen oder lass die besser jetzt erstmal komplett weg.

Hallo zusammen,

ich habe mich seit gestern mal tiefer mit Threads beschäftigt und da kam das Beispiel von Stahli hier genau richtig.

Nun habe ich mal eine "Demo" erstellt, mit den 2 verschiedenen Varianten von Stahli und Haentschmann.
In meiner VM-Entwickler-Maschine laufen beide Thread-Varianten so wie erwartet. Man sieht wie das Label refresht wird und das Hochzählen der Zahlen anzeigt.
Auf meinem Haupt-PC läuft es nicht so wie ich es erwarten würde. Das Programm wird blockiert (evtl. selbes Problem wie bei KodeZwerg?), sobald das Programm den Fokus hat oder man mit der Maus nur über das Programm drüber gleitet. Wenn man ein anderes Programm in den Vordergrund holt, zeigt das Label wieder das Hochzählen an und die Blockade ist weg.
Ich hoffe, ich konnte ausdrücken was das Problem ist.

Hier die Hauptunit:

zusammenfalten · markieren

Delphi-Quellcode:

UNIT uMain;

INTERFACE

USES
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Vcl.ExtCtrls;

TYPE
  TOnChangeEvent = PROCEDURE( Sender: TObject; MaxValue: Integer; CurrentValue: Integer ) OF OBJECT; { mein Event-Hanlder für den 2. Thread }

  Tfrm_Main = CLASS( TForm )
    Btn_Start_Thread1: TButton;
    CounterLabel1: TLabel;
    Btn_End_Thread1: TButton;
    Label1: TLabel;
    Bevel1: TBevel;
    Btn_Start_Thread2: TButton;
    Btn_End_Thread2: TButton;
    Counterlabel2: TLabel;
    PROCEDURE FormClose( Sender: TObject; VAR Action: TCloseAction );
    PROCEDURE Btn_Start_Thread1Click( Sender: TObject );
    PROCEDURE Btn_End_Thread1Click( Sender: TObject );
    PROCEDURE DoOnChange( Sender: TObject; MaxValue: Integer; CurrentValue: Integer );
    PROCEDURE Btn_Start_Thread2Click( Sender: TObject );
    PROCEDURE Btn_End_Thread2Click( Sender: TObject );
    PROCEDURE FormCreate( Sender: TObject );

  PRIVATE
    { Private-Deklarationen }

  PUBLIC
    { Public-Deklarationen }
  VAR
    gb_ist_Thread1_aktiv, gb_ist_Thread2_aktiv: Boolean;

  END;

VAR
  frm_Main: Tfrm_Main;

IMPLEMENTATION

{$R *.dfm}


USES
  uThread_mit_Erzeugung_Controls_fuer_Zugriff_auf_VCL_im_Hauptthread, uThread_mit_Businesslogic_kennt_somit_nicht_den_HauptThread;


{ mein Event-Handler von dem 2. Thread }
PROCEDURE Tfrm_Main.DoOnChange( Sender: TObject; MaxValue: Integer; CurrentValue: Integer );
BEGIN
  frm_Main.CounterLabel2.Caption := CurrentValue.ToString;
END;

PROCEDURE Tfrm_Main.FormCreate( Sender: TObject );
BEGIN
  gb_ist_Thread1_aktiv := False;
  gb_ist_Thread2_aktiv := False;
END;

PROCEDURE Tfrm_Main.Btn_Start_Thread1Click( Sender: TObject );
BEGIN
  Btn_Start_Thread1.Enabled := False;
  Btn_Start_Thread2.Enabled := False;
  Btn_End_Thread2.Enabled := False;

  FMy_Thread1 := TTheThread.Create( CounterLabel1 );
END;

PROCEDURE Tfrm_Main.Btn_End_Thread1Click( Sender: TObject );
BEGIN
  IF frm_Main.gb_ist_Thread1_aktiv THEN FMy_Thread1.Terminate;
  Btn_Start_Thread1.Enabled := True;
  Btn_End_Thread1.Enabled := True;
  Btn_Start_Thread2.Enabled := True;
  Btn_End_Thread2.Enabled := True;
END;

PROCEDURE Tfrm_Main.Btn_Start_Thread2Click( Sender: TObject );
BEGIN
  Btn_Start_Thread1.Enabled := False;
  Btn_End_Thread1.Enabled := False;
  Btn_Start_Thread2.Enabled := False;

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

PROCEDURE Tfrm_Main.Btn_End_Thread2Click( Sender: TObject );
BEGIN
  IF frm_Main.gb_ist_Thread2_aktiv THEN FMy_Thread2.Terminate;
  Btn_Start_Thread1.Enabled := True;
  Btn_End_Thread1.Enabled := True;
  Btn_Start_Thread2.Enabled := True;
  Btn_End_Thread2.Enabled := True;
END;

PROCEDURE Tfrm_Main.FormClose( Sender: TObject; VAR Action: TCloseAction );
BEGIN
  IF frm_Main.gb_ist_Thread1_aktiv THEN FMy_Thread1.Terminate;
  IF frm_Main.gb_ist_Thread2_aktiv THEN FMy_Thread2.Terminate;
END;

END.

Und hier die Unit eines der beiden Thread-Beispiele:

zusammenfalten · markieren

Delphi-Quellcode:

UNIT uThread_mit_Businesslogic_kennt_somit_nicht_den_HauptThread;

INTERFACE

USES
  Winapi.Windows, Winapi.Messages, System.Classes, System.SysUtils, Vcl.Graphics, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, uMain;

TYPE

  TTheThread2 = CLASS( TThread )
  PRIVATE
    FOnChange: TOnChangeEvent; { Event-Handler in uMain }
  PUBLIC
    PROPERTY OnChange: TOnChangeEvent READ FOnChange WRITE FOnChange;
    PROCEDURE Execute; OVERRIDE;
  END;

VAR
  FMy_Thread2: TTheThread2;

IMPLEMENTATION

PROCEDURE TTheThread2.Execute;
VAR
  I1, I2: Cardinal;
BEGIN
  I1 := 0;
  I2 := 0;
  TRY
    frm_Main.gb_ist_Thread2_aktiv := True;
    TRY
      WHILE ( NOT Terminated ) DO
      BEGIN
        Inc( I1 );
        IF ( I1 >= 1000 ) THEN
        BEGIN
          Inc( I2 );

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

          I1 := 0;
          IF I2 > 4200000000 THEN I2 := 0; // wegen Gefahr eines Überlaufs wenn jemand mal den Thread laufen lässt...

          // ================================= !!! um Fehler zu testen im(!) Thread ===============================
          // I2 := I2 DIV I1;
        END;
      END;
    FINALLY
      frm_Main.gb_ist_Thread2_aktiv := False;
    END;
  EXCEPT
    /// Wird benötigt, weil eine Exception im(!) Thread diesen Thread beendet und eine Exception im Hauptthread nicht "angezeigt" werden kann
    ON E: Exception DO
    BEGIN
      Queue(
        PROCEDURE
        BEGIN
          MessageBox( Application.MainFormHandle, PChar( Exception.Classname + ' : ' + E.Message ), 'Thread-Error!', MB_OK OR MB_ICONERROR );
        END );
    END;
  END;
END;

END.

Ich würde mich freuen wenn dieses Mysterium aufgeklärt werden könnte.
Vielen Dank schon mal vorab!

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.

@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.