Hallo zusammen,
ich beschäftige mich vermutlich mit mäßigem Erfolg mit Threads und habe dazu ein Beispiel hier aus dem Forum ausgewählt, dass unlängst hier diskutiert wurde.
https://www.delphipraxis.net/210313-...d-starten.html
Ich habe also das von #Sinspin gepostete Beispiel für mich zum Verständnis ausgewählt.
Da wird also ein Haupt-Thread erzeugt, in dem eine Schleife bis 100 zählt und diese dann an ein Counter.Label sendet.
Als weiterer Thread wird ein Activityindicator erzeugt. Beide Threads laufen parallel.
Nun wollte ich das Beispiel erweitern und einen weiteren Hintergrund-Thread hinzufügen und erhalte folgenden Effekt:
Der 2. Thread mit einem weiteren Activityindicator und einer Schleife, die bis 70 zählt wird sofort ausgeführt (zählt bis 70 und 2. Activityindicator wird angezeigt).
Ebenfalls parallel wird der 1. Activityindicator ausgeführt.
Erst wenn die 70-ger-Schleife (2.Thread) abgearbeitet wurde startet die Schleife bis 100 (Haupt-Thread) und beide Activityindicatoren werden parallel angezeigt.
Ist das so richtig?
Wie muß man ein Konstrukt mit einem Haupt-Thread und zwei weiteren Threads bauen? Ich bin da so völlig unbedarft und taste mich an die ominösen Threads erst heran.
Die hier oft diskutierten Beispiele sind mir oft zu kompliziert um nur das Wesen der Threads zu begreifen und natürlich auch deren Synchronisation.
Nun noch mein Erweiterungs-Konstruckt auf 2 Threads neben dem Haupt-Thread:

zusammenfalten · markieren

Delphi-Quellcode:

unit Unit1;

interface
uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Threading,
  System.Classes, Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls,
  Vcl.WinXCtrls, Vcl.ExtCtrls;

type
  TheThread = class(TThread)
  private
    procedure DoIt;
  public
    procedure Execute; override;
  end;

type
  TheThread2 = class(TThread)
  private
    procedure DoIt2;
  public
    procedure Execute; override;
  end;

type
  TForm1 = class(TForm)
  actvtyndctr1: TActivityIndicator;
  CounterLabel: TLabel;
  StartThreadBtn: TButton;
  btnclose: TButton;
    lblDoit2: TLabel;
    actvtyndctr2: TActivityIndicator;
    lblThread2: TLabel;
    lblThread1: TLabel;
    bvl1: TBevel;
    lblHauptThread: TLabel;
  procedure StartThreadBtnClick(Sender: TObject);
  procedure btncloseClick(Sender: TObject);
  private
    { Private-Deklarationen }

  public
    { Public-Deklarationen }

  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ TheTread1 }

procedure TheThread.DoIt;
begin
  Form1.actvtyndctr1.Animate := true;
end;

procedure TheThread.Execute;
begin
  Synchronize(DoIt);
end;

{ TheTread2 }

procedure TheThread2.DoIt2;
var i: int32;
begin
  Form1.actvtyndctr2.Animate:= True;

  for i := 0 to 70 do
  begin
      Form1.lblDoIt2.Caption := I.tostring;
      Application.ProcessMessages;
      Sleep(30);
    end;

end;

procedure TheThread2.execute;
begin
  inherited;
  Synchronize(DoIt2);
end;

procedure TForm1.btncloseClick(Sender: TObject);
begin
  Close;
end;

procedure TForm1.StartThreadBtnClick(Sender: TObject);
var
  Thread: TheThread;
  Thread2: TheThread2;
  I: integer;
begin
  try
    // Thread starten
    Thread := TheThread.Create(True);
    Thread.FreeOnTerminate := true;
    Thread.Start;

    Thread2:=TheThread2.Create(True);
    thread2.FreeOnTerminate:=True;
    thread2.Start;

    // Hauptthread Zählt bis 100 u. gibt Ergebnis aus
    for I := 0 to 100 do
    begin
      Form1.CounterLabel.Caption := I.tostring;
      Application.ProcessMessages;
      Sleep(50);
    end;
    Form1.actvtyndctr1.Animate := false;
    Form1.actvtyndctr2.Animate := false;
  except
    on E:Exception do
    begin
      Form1.actvtyndctr1.Animate := false;
      Form1.actvtyndctr2.Animate := false;
    end;
  end;
end;
end.

Anbei das Beispielprogramm

Zitat:

Erst wenn die 70-ger-Schleife (2.Thread) abgearbeitet wurde startet die Schleife bis 100 (Haupt-Thread) und beide Activityindicatoren werden parallel angezeigt.
Ist das so richtig?

Eigentlich sollte die Schleife bis 100 sofort loslegen wenn der 2. Thread gestartet wurde.
Wenn das so funktionieren soll, wie du oben beschreibst, dann braucht man ja keinen Thread und kann alles nacheinander abarbeiten.

Außerdem würde ich Form1.actvtyndctr2.Animate := false; nicht da stehen lassen wo es steht.
Das soll da aufgerufen werden, wo auch der Thread seine Arbeit erledigt hat. Also im Thread selber und nicht außerhalb.

Dein Beispiel ist nicht gut, ich würde das wegschmeißen und was Vernünftiges suchen.

Was dir anschließend noch nicht klar ist:
1. Im Execute macht man das,was zu tun ist.
Also for... Slepp usw.
2. Per synchronise erfolt der Zugriff auf die Vcl und hier kein Sleep!
3. Application.ProcessMessages sollte bzw. darf weder im Excecute noch in den per
Synchronise abgerufenen Methoden verwendet werden.
4. Eine Exception Behandlung muss im Execute erfolgen.

Ich bin grade an Tablett und kann daher kein Beispiel machen, wie es sinnvoll wäre.

Dazu ist ein klein wenig wichtig zu wissen, wie sich Windows verhält wenn man Threads startet.

Ein Thread der erzeugt wird wird, wenn man ihn Starten möchte, nicht sofort gestartet. Die Windows-API sagt dem Thread lediglich, dass er jetzt loslaufen kann, und der Windows-Scheduler kann ihn dann (muss ihn aber nicht sofort) beim nächsten mal wenn er arbeitet berücksichtigen und auf die CPU legen.

Das passiert frühestens(!) wenn der Haupt-Thread Deiner Anwendung yielded (das bedeutet: Rechenzeit abgibt). Warum das passiert (seine Zeitscheibe / Quantum ist abgelaufen, er blockiert wegen I/O, er gibt mit Sleep freiwillig Rechenzeit ab) ist dabei egal, aber der zweite Thread kommt eben frühestens das erste mal auf die CPU wenn der Hauptthread frei macht.

Auch danach kannst Du bei mehreren Threads nicht sicher sein, dass die wirklich Zeitgleich laufen. Es kann passieren, dass der Windows-Scheduler die Threads alle schön nacheinander ausführt.

Auch wichtig: Nur der UI-Thread kann das UI aktualisieren. Wenn der gerade nicht läuft wenn die anderen beiden Threads werkeln, bekommt das UI das nicht mit. Und da Du den im Prinzip mehr schlafen legst als das er Rechnet (Sleep-Aufrufe) kann der nicht viel machen.

Noch ein Wort zu den Quantums: Eine Zeitscheibe auf der CPU sind bei Windows aktuell vermutlich irgendwas zwischen 20 und 60 Millisekunden ( siehe auch: https://medium.com/@dikrek/processor...x-fb5ab02828e2 ). Nehmen wir mal Beispielhaft 30 an. Wenn der Thread jetzt z.B. nur eine Millisekunde rechnet und Du dann Sleep aufrufst, verwirfst Du den kompletten Rest Deiner Zeitscheibe. Das bedeutet der Scheduler nimmt den von der CPU runter und er kommt frühestens nach 29 Millisekunden wieder dran. Auch wenn Du nur 5ms Schlafen willst.

Will heissen: Mit Deinen extrem kurzen Cyclen (einfache Schleifen) und aus CPU-Sicht extrem vielen und langen Wartezeiten ärgerst Du gerade mehr den Windows-Scheduler als rauszufinden was wirklich passiert

Zitat von Phoenix:

Wenn der Thread jetzt z.B. nur eine Millisekunde rechnet und Du dann Sleep aufrufst, verwirfst Du den kompletten Rest Deiner Zeitscheibe. Das bedeutet der Scheduler nimmt den von der CPU runter und er kommt frühestens nach 29 Millisekunden wieder dran. Auch wenn Du nur 5ms Schlafen willst.

Auf aktuellen Multikernprozessoren stimmt das höchstens dann, wenn alle Kerne komplett ausgelastet sind und die Threads um Prozessorzeit konkurrieren. Ansonsten, wenn du einen Thread 5 ms schlafen legst, dann ist er nach 5-6 ms wieder wach und arbeitet weiter.

Zitat von BerndS:

4. Eine Exception Behandlung muss im Execute erfolgen.

Oh, auch hier vielleicht wichtig als Hintergrundinfo: Ein "Feature" von Windows ist es, bei einer unbehandelten(!) Exception in einem Sub-Thread immer gleich den kompletten Prozess zu terminieren. Und zwar sofort. Throw -> alle Fenster weg. Du kannst in dem Moment nicht mehr reagieren. Noch nichtmal loggen. Deswegen ist es sauwichtig das jeder von Dir erzeugte Thread entweder ganz sicher keine Exception werfen kann oder idealerweise die komplette Ausführung in einer try/catch - Anweisung läuft. Sonst: Plopp

Zitat von Phoenix:

Oh, auch hier vielleicht wichtig als Hintergrundinfo: Ein "Feature" von Windows ist es, bei einer unbehandelten(!) Exception in einem Sub-Thread immer gleich den kompletten Prozess zu terminieren. Und zwar sofort. Throw -> alle Fenster weg. Du kannst in dem Moment nicht mehr reagieren. Noch nichtmal loggen. Deswegen ist es sauwichtig das jeder von Dir erzeugte Thread entweder ganz sicher keine Exception werfen kann oder idealerweise die komplette Ausführung in einer try/catch - Anweisung läuft. Sonst: Plopp

Wie gut, dass der Code in der RTL das schon übernimmt und jegliche Exception aus dem Thread Execute abfängt und an die Eigenschaft FatalException hängt, so dass das nicht passieren kann.

zunächst erst einmal Dank für die konstruktiven Hinweise.
Doch so richtig weitergekommen bin ich noch nicht.
Gibt es denn nicht ein wirklich einfaches Beispiel für Hauptprogramm und ggf. 2 Threads, die synchronisiert werden ohne viel Schnick und Schnack.
Leider habe ich bisher nur mit div. Problemen überfrachtete Beispiele gefunden, die mir als Anfänger in dieser Sache nicht so richtig weiter helfen.
Den vorliegenden Code habe ich dahingehend verändert, dass nun im 2. Thread keine Schleife (bis 70) mehr enthalten ist sondern nur noch ein Activityindicator
mit anderem Aussehen. Also im Hauptprogramm wird eine Schleife bis 100 hoch gezählt und in den beiden Threads laufen die jeweils verschiedenen Activityindicatoren.
Diese laufen erkennbar beide gleichzeitig und wohl auch synchronisiert. Ist das also als Beispiel für ein Hauptprogramm mit 2 Threads tauglich?
Kennt jemand ein gutes Beispiel für meine Vorstellungen?