Ist die Verwendung von TTask so korrekt?

[a.def]

Wie der Titel schon erahnen lässt bezweifle ich die Richtigkeit meines Code-Stücks hier.
Ich möchte eine Arbeit starten und dabei den Hauptthread nicht einfrieren lassen.

Delphi-Quellcode:

        TTask.Run(
          procedure
         var
          i: Integer;
         begin
          i := 0;

          while i < 500 do
           begin
            inc(i);
            Sleep(10);
            Caption := IntToStr(i);
           end;
         end);

Das funktioniert einwandfrei. Aber sollte man das nicht eigentlich mit einem

Delphi-Quellcode:

          TThread.Synchronize(nil,
            procedure
           begin
           end);

Ummanteln? Wenn ich das mache, bleibt mein Hauptthread leider stehen bis die 5 Sekunden abgelaufen sind.

[DeddyH]

Sollte das Synchronize nicht einfach nur die Caption-Zuweisung umschließen?

[a.def]

Selbst das hängt die GUI auf. Ich sehe zwar wie sich die Caption ändert aber ich kann sonst nichts mehr machen.
Wenn ich Synchronize einfach weg lasse funktioniert alles. Aber darf man das?

[Luckie]

Ist ja irgendwie logisch. Die Schleife macht ja nichts anders als ein Steuerelement im Formular hochzuzählen. Wenn du das jetzt synchronisierst läuft das ganze quasi im Thread des Formulares.

[a.def]

Aber es heißt doch immer, dass man Zugriffe auf die VCL synchronisieren muss oder ist das hier nicht nötig?

[t.roller]

Verwenden von TTask aus der Parallel Programming Library

[stahli]

Mit Tasks habe ich keine Erfahrungen aber mit Threads schon.

Synchronisieren musst Du Zugriffe auf das Formular, um Zugriffsprobleme zu vermeiden.
Ohne Synchronisation kann es zwar klappen, aber Du kannst auch unvorhersehbare Probleme bekommen (von unauffälligen Datenfehlern bis Abstürzen).

Delphi-Quellcode:

  TThread.Synchronize(nil,
    procedure
      begin
        MyForm.Caption := IntToStr(i);
      end); 
  Sleep(1000);

Wenn Du Dein Sleep auf 1000 einstellst, solltest Du auch den gewünschten Effekt sehen.
Sonst ist die Pause m.E. zu kurz, um etwas zu bemerken und der Mainthread ist voll belastet.

[a.def]

Zitat:

Zitat von t.roller (Beitrag 1357699)

Verwenden von TTask aus der Parallel Programming Library

Abschnitt Eine weitere Funktionalität von TTask ist das Verhindern der Sperrung der Benutzeroberfläche, wenn Sie im Hintergrund etwas starten möchten. Im folgenden Beispiel wird gezeigt, wie Sie eine einzelne Aufgabe ausführen und starten
Danke! TTask benötigt also kein Synchronize.

P.S.:
ich glaube da ist ein Tippfehler in

Zitat:

WaitForAll informiert Sie über den Abschluss aller Aufgaben und WaitForAny über die erste Aufgabe, die abgeschossen wurde.

Ich glaube es sollte abge(l)schossen heißen.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1357701)

Danke! TTask benötigt also kein Synchronize.

Wo steht das?

TTask macht einen separaten Thread auf. Der Code, der an TTask übergeben wurde, läuft dann in diesem Thread. Das heißt aber nicht, daß Zugriffe auf die VCL nicht doch synchronisiert werden müssen - so wie in jedem anderen Thread auch.

Dein Beispiel ist irgendwie Nonsens und deswegen liefert es auch keine vernünftigen Ergebnisse. Wenn du alle 10 ms einen Zähler hochzählst und den dann in der Caption darstellst, dann musst(!) du dafür Synchronize oder Queue verwenden. Damit zwingst du den Hauptthread aber alle 10 ms diese Caption zu aktualisieren und das bremst natürlich. Solange also die Aufgabenstellung besagt, daß alle 10 ms die Caption aktualisiert werden muss, kann auch die Verwendung eines Threads den Hauptthread nicht wirklich entlasten.

Threads sind nicht dazu da, viele Zugriffe auf die VCL auszuführen, sondern längere Sequenzen, die nicht mit der VCL rumhantieren, aus dem Hauptthread zu extrahieren, damit die Anwendung weiter auf Benutzereingaben reagieren kann. Das Extrahieren erfordert manchmal schon etwas mehr Überlegung, damit das Ganze auch threadsicher wird.

Stell dir einfach vor, du müsstest eine solche Code-Sequenz als separate Kommandozeilenanwendung schreiben, bei der du Readln und Writeln nur bei Programmanfang und -ende verwenden darfst. Alles dazwischen muss ohne Bildschirmausgaben und Tastatureingaben auskommen. Dieses dazwischen könnte man dann wohl in einen Thread oder auch eine TTask verlagern, um das in einer responsiven UI-Anwendung auszuführen. Daraus folgt dann implizit, daß man in Threads nur sehr sparsam mit Statusmeldungen arbeiten sollte, da diese zwangsweise irgendwie an die UI und somit an den Hauptthread übergeben (synchronisiert) werden müssen.

[t.roller]

Zitat:

Zitat von a.def (Beitrag 1357701)

Zitat:

Zitat von t.roller (Beitrag 1357699)

Verwenden von TTask aus der Parallel Programming Library

Abschnitt Eine weitere Funktionalität von TTask ist das Verhindern der Sperrung der Benutzeroberfläche, wenn Sie im Hintergrund etwas starten möchten. Im folgenden Beispiel wird gezeigt, wie Sie eine einzelne Aufgabe ausführen und starten

Beispiel:

Delphi-Quellcode:

// uses System.Threading,...
procedure TForm1.ButtonClick(Sender: TObject);
var
  lValue: Integer;
begin
    Label1.Caption := '--';
    CheckBox1.Checked:= TRUE;
    TTask.Run(procedure
      begin
          {Some calculation that takes time}
          Sleep(3000);
          lValue := Random(100);
          TThread.Synchronize(nil,
            procedure
            begin
                  CheckBox1.Checked:= FALSE;
                  Label1.Caption := lValue.ToString;
            end);
      end);
//-------------------------------------------------------------------
    Label2.Caption := '--';
    CheckBox2.Checked:= TRUE;
    TTask.Run(procedure
      begin
          {Some calculation that takes time}
          Sleep(6000);
          lValue := Random(100);
          TThread.Synchronize(nil,
            procedure
            begin
                  CheckBox2.Checked:= FALSE;
                  Label2.Caption := lValue.ToString;
            end);
      end);
//-------------------------------------------------------------------
    Label3.Caption := '--';
    CheckBox3.Checked:= TRUE;
    TTask.Run(procedure
      begin
          {Some calculation that takes time}
          Sleep(9000);
          lValue := Random(100);
          TThread.Synchronize(nil,
            procedure
            begin
                  CheckBox3.Checked:= FALSE;
                  Label3.Caption := lValue.ToString;
            end);
      end);
//-------------------------------------------------------------------
end;

[a.def]

Zitat:

Zitat von Uwe Raabe (Beitrag 1357702)

Zitat:

Zitat von a.def (Beitrag 1357701)

Danke! TTask benötigt also kein Synchronize.

Wo steht das?

Zitat:

Eine weitere Funktionalität von TTask ist das Verhindern der Sperrung der Benutzeroberfläche, wenn Sie im Hintergrund etwas starten möchten. Im folgenden Beispiel wird gezeigt, wie Sie eine einzelne Aufgabe ausführen und starten

Für mich bedeutet das, dass man es nicht benötigt. Selbst im offiziellen Emba-Beispiel wird kein Synchronize verwendet.

Mein Beispiel ist ja auch nonsense, keine Frage. Ist ja auch nur ein Beispiel zu einer dummen Frage.
Die eigentliche Arbeit meiner TTasks besteht aus ganz anderen Sachen und nicht so etwas Dummes wie "Caption alle 10ms verändern".

Zitat:

(von Emba)
Eine weitere Funktionalität von TTask ist das Verhindern der Sperrung der Benutzeroberfläche, wenn Sie im Hintergrund etwas starten möchten. Im folgenden Beispiel wird gezeigt, wie Sie eine einzelne Aufgabe ausführen und starten:
Delphi:

Delphi-Quellcode:

 
procedure TFormThreading.Button1Click(Sender: TObject);
var
 aTask: ITask;
begin
 aTask := TTask.Create (procedure ()
   begin
     sleep (3000); // 3 seconds
     ShowMessage ('Hello'); // <= kein Synchronize
   end);
 aTask.Start;
end;

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1357697)

Ist ja irgendwie logisch. Die Schleife macht ja nichts anders als ein Steuerelement im Formular hochzuzählen. Wenn du das jetzt synchronisierst läuft das ganze quasi im Thread des Formulares.

Hallo Luckie / Michael, wenn es um Threads in Delphi geht, wessen bzw. welches Skript ist dann auch heute noch wohl erste Anlaufstelle, die Referenz schlechthin? ;-)

Nach dieser Schleimeinheit eine ganz vorsichtige Anregung: Wäre nicht die Klasse "TTask" (ab welcher Delphiversion?) es wert, dort mit aufgenommen zu werden, so als Ergänzung? Immerhin sind jetzt schon sogar die Fiber enthalten.

[himitsu]

Zitat:

Zitat von Luckie (Beitrag 1357697)

Ist ja irgendwie logisch. Die Schleife macht ja nichts anders als ein Steuerelement im Formular hochzuzählen. Wenn du das jetzt synchronisierst läuft das ganze quasi im Thread des Formulares.

Jupp, Synchronisieren muß man mit der VCL/FMX.
Also Threads lohnen sich nur, wenn der enthaltene Code mehr im Thread macht, als in der GUI.

Man kann jetzt die Anzeige-Zugriffe verringern.
z.B. nur jeden 1000. Schleifendurchlauf in die GUI geben
oder die GUI per Timer/Event triggern, welche sich dann ab und an vom Thread den aktuellen Wert holt.

Die Parallel Computing Library (TTask und Co.) ist seit XE7 enthalten.
http://docwiki.embarcadero.com/RADSt...amming_Library

[HolgerX]

Hmm..

Zitat:

Zitat:

Verwenden von TTask aus der Parallel Programming Library

Abschnitt Eine weitere Funktionalität von TTask ist das Verhindern der Sperrung der Benutzeroberfläche, wenn Sie im Hintergrund etwas starten möchten.

Da steht nur das die Benutzeroberfläche NICHT gesperrt wird!
Somit läuft etwas im Hintergrund (Thread) ohne das der MainThread und somit die Benutzereingabe gesperrt wird.
Sprich, dass wenn Du z.B. auf einem Button.Click eine laaaaannngggeee Verarbeitung machts, dann ist die Oberfläche gesperrt. Selbst Aktualisierungen werden ohne ProzessMessages nicht mehr auf z.B. Edits angezeigt.

[t.roller]

Zitat:

Zitat von HolgerX (Beitrag 1357708)

Sprich, dass wenn Du z.B. auf einem Button.Click eine laaaaannngggeee Verarbeitung machts, dann ist die Oberfläche gesperrt. Selbst Aktualisierungen werden ohne ProzessMessages nicht mehr auf z.B. Edits angezeigt.

Das ist falsch.

Füge doch meinem Beispiel in #10
das hinzu:

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
begin
Button3.Tag:= Button3.Tag +1;
Label4.Caption:= INTTOSTR(Button3.Tag);
end;

Das bleibt bedienbar.

[Daniel]

Fettschrift hilft da auch nicht, um die eigene Position zu unterstreichen. Wirklich.
In Deinem Beispiel in Beitrag #10 wird die langlaufende Operation (im Beispiel das Sleep) ja in dem Thread ausgeführt. Die Synchronisation mit dem MainThread ist immer nur sehr kurz. Es ist klar, dass das bedienbar bleibt.
Setze das Sleep mal in das OnClick-Ereignis. Dann legt sich auch die GUI zur Ruhe nieder.

[Uwe Raabe]

Zitat:

Zitat von a.def;1357704[QUOTE

(von Emba)
Eine weitere Funktionalität von TTask ist das Verhindern der Sperrung der Benutzeroberfläche, wenn Sie im Hintergrund etwas starten möchten. Im folgenden Beispiel wird gezeigt, wie Sie eine einzelne Aufgabe ausführen und starten:
Delphi:

Delphi-Quellcode:

 
procedure TFormThreading.Button1Click(Sender: TObject);
var
 aTask: ITask;
begin
 aTask := TTask.Create (procedure ()
   begin
     sleep (3000); // 3 seconds
     ShowMessage ('Hello'); // <= kein Synchronize
   end);
 aTask.Start;
end;

Ich wage mal zu behaupten, daß das Beispiel dort schlichtweg falsch ist. In den Tiefen von

Delphi-Quellcode:

ShowMessage

wird irgendwann ein

Delphi-Quellcode:

Application.ModalStarted

und ein

Delphi-Quellcode:

Application.ModalEnded

aufgerufen. Darin ist das Verändern von

Delphi-Quellcode:

FModalLevel

schon mal nicht wirklich threadsicher. Weiterhin wird gegebenfalls ein

Delphi-Quellcode:

OnModalBegin

bzw.

Delphi-Quellcode:

OnModalEnd

aufgerufen (auch nicht auf thread-sichere Weise). Sind diese Events verlinkt, wird der dortige Code im Thread-Context aufgerufen, was der Event-Verlinker vermutlich gar nicht auf dem Schirm hat. Das obige Beispiel in einer hinreichend komplexen Anwendung führt zu sporadischen Fehlfunktionen, die nur sehr schwer zu analysieren sind.

Grundsätzlich würde ich mich nicht darauf verlassen, daß der Code in den Beispielen für den produktiven Einsatz geeignet ist. Auch TTask ist keine Magie, die plötzlich Thread-Programmierung zu einem Kinderspiel macht.

Um den Beispielcode kümmere ich mich noch. Wenn jemand in C++ fit ist, wäre ich für entsprechende Hinweise zu dem dort ebenfalls vorhandenen und potentiell ebenso falschen C++-Code dankbar.

[DeddyH]

Zitat:

Zitat von Uwe Raabe (Beitrag 1357721)

Grundsätzlich würde ich mich nicht darauf verlassen, daß der Code in den Beispielen für den produktiven Einsatz geeignet ist. Auch TTask ist keine Magie, die plötzlich Thread-Programmierung zu einem Kinderspiel macht.

Diese Worte sollte man sich in Stein meißeln :thumb:

[HolgerX]

Hmm..

Wer lesen kann ist im Vorteil!

Zitat:

Zitat von t.roller (Beitrag 1357710)

Zitat:

Zitat von HolgerX (Beitrag 1357708)

Sprich, dass wenn Du z.B. auf einem Button.Click eine laaaaannngggeee Verarbeitung machts, dann ist die Oberfläche gesperrt. Selbst Aktualisierungen werden ohne ProzessMessages nicht mehr auf z.B. Edits angezeigt.

Das ist falsch.

Füge doch meinem Beispiel in #10
das hinzu:

Delphi-Quellcode:

procedure TForm1.Button3Click(Sender: TObject);
begin
Button3.Tag:= Button3.Tag +1;
Label4.Caption:= INTTOSTR(Button3.Tag);
end;

Das bleibt bedienbar.

Ich schrieb:

Zitat:

Sprich, dass wenn Du z.B. auf einem Button.Click eine laaaaannngggeee Verarbeitung machts, dann ist die Oberfläche gesperrt. Selbst Aktualisierungen werden ohne ProzessMessages nicht mehr auf z.B. Edits angezeigt.

Platziere auf einer Form ein Memo und einen Button!
Packe dies ins Button Click rein:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
begin
  Memo1.Lines.Add('Begin');
  Sleep(10000);
  Memo1.Lines.Add('Finish');
end;

Und beobachte!!!!

Was passiert..

Button Click -> 10 Sekunden lang nichts und dann kommt direkt 'Begin' und 'Finish'.

Während der 10 Sekunden kannste auf der Form versuchen, was Du willst, es klappt nichts..

Wieso, weil der Button.Click im MainThread läuft und die Acktualisierung erst erfolgt, wenn die Procedure fertig ist!

Wenn Du nun in einem Separaten Threat ( TTask,TThreat..) das Sleep machst, dann kannste die Form weiter bedienen.

Jedoch kümmert sich weder TTask noch TThread um Sync..

Jeder Zugriff aus einem Separaten Thread mit gesynct werden! Sei es durch Synchronize(), Mutex, CriticalSection oder ähnliches. Selbst bei Verwendung von SendMessage würdest Du eine Sync-Routine verwenden, nur gekapselt durch Windows...

[a.def]

Sicherheitshalber (und auch weil es wohl korrekt ist), habe ich meine GUI-Zugriffe nun alle mit Synchronize abgesichert.
Zuvor habe ich noch das alte BeginThread verwendet und immer ohne Synchronize. Zum Glück ist nie was passiert.

[Luckie]

Zitat:

Zitat von Delphi-Laie (Beitrag 1357706)

Zitat:

Zitat von Luckie (Beitrag 1357697)

Ist ja irgendwie logisch. Die Schleife macht ja nichts anders als ein Steuerelement im Formular hochzuzählen. Wenn du das jetzt synchronisierst läuft das ganze quasi im Thread des Formulares.

Hallo Luckie / Michael, wenn es um Threads in Delphi geht, wessen bzw. welches Skript ist dann auch heute noch wohl erste Anlaufstelle, die Referenz schlechthin? ;-)

Nach dieser Schleimeinheit eine ganz vorsichtige Anregung: Wäre nicht die Klasse "TTask" (ab welcher Delphiversion?) es wert, dort mit aufgenommen zu werden, so als Ergänzung? Immerhin sind jetzt schon sogar die Fiber enthalten.

Wennich eine Delphi Version hätte, die dies unterstützt. :?

[stahli]

Zitat:

Zitat von Luckie (Beitrag 1357760)

Zitat:

Zitat von Delphi-Laie (Beitrag 1357706)

Zitat:

Zitat von Luckie (Beitrag 1357697)

Ist ja irgendwie logisch. Die Schleife macht ja nichts anders als ein Steuerelement im Formular hochzuzählen. Wenn du das jetzt synchronisierst läuft das ganze quasi im Thread des Formulares.

Hallo Luckie / Michael, wenn es um Threads in Delphi geht, wessen bzw. welches Skript ist dann auch heute noch wohl erste Anlaufstelle, die Referenz schlechthin? ;-)

Nach dieser Schleimeinheit eine ganz vorsichtige Anregung: Wäre nicht die Klasse "TTask" (ab welcher Delphiversion?) es wert, dort mit aufgenommen zu werden, so als Ergänzung? Immerhin sind jetzt schon sogar die Fiber enthalten.

Wennich eine Delphi Version hätte, die dies unterstützt. :?

http://www.delphipraxis.net/1263046-post45.html
... könnten ja Tutorialschreiber mal drunter fallen ;-)

(...vor allem wenn man weiß (oder davon ausgehen kann), dass diese sich mit Delphi keine goldene Nase verdienen, sondern das eher aus Interesse unterstützen...)

[Uwe Raabe]

Zitat:

Zitat von stahli (Beitrag 1357762)

http://www.delphipraxis.net/1263046-post45.html
... könnten ja Tutorialschreiber mal drunter fallen ;-)

Meine Stimme hast du :thumb:

[Delphi-Laie]

Zitat:

Zitat von Luckie (Beitrag 1357760)

Wennich eine Delphi Version hätte, die dies unterstützt. :?

Och, 10.1 ist sogar kostenlos und wird das bestimmt "schon" beherrschen.

[a.def]

Zitat:

Zitat von Delphi-Laie (Beitrag 1357777)

Zitat:

Zitat von Luckie (Beitrag 1357760)

Wennich eine Delphi Version hätte, die dies unterstützt. :?

Och, 10.1 ist sogar kostenlos und wird das bestimmt "schon" beherrschen.

Wollte ich eigentlich auch schreiben. Aber in 10.1 Starter fehlt leider der Debugger. Vielleicht auch Threading.

[Uwe Raabe]

Zitat:

Zitat von a.def (Beitrag 1357778)

Aber in 10.1 Starter fehlt leider der Debugger. Vielleicht auch Threading.

Nee, ist dabei.

[Mavarik]

Zitat:

Zitat von himitsu (Beitrag 1357707)

Also Threads lohnen sich nur, wenn der enthaltene Code mehr im Thread macht, als in der GUI.

Im "Normalfall" würde ich Dir nicht widersprechen.

Aber es stimmt für die mobilen Plattformen und FMX nicht.

Beispiel:

Delphi-Quellcode:

procedure TForm202.Button1Click(Sender: TObject);
begin
  Sleep(1000);
  Caption := '42';
end;

procedure TForm202.Button2Click(Sender: TObject);
begin
  TTask.Run(Procedure 
    begin
      TThread.Queue(NIL,Procedure
        begin
          Sleep(1000);
          Caption := '42';
        end;
    end;      
end;

hat nicht das gleiche verhalten!

Besser wäre natürlich: 8-)

Delphi-Quellcode:

Uses
  Delphiprofi.FDK.Idleworker;

procedure TForm202.Button3Click(Sender: TObject);
begin
  TIdleworker.Default.Execute(
    Procedure
      begin
        Sleep(1000);
        Caption := '42';
      end,true);
end;

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1357782)

Delphi-Quellcode:

procedure TForm202.Button2Click(Sender: TObject);
begin
  TTask.Run(Procedure 
    begin
      TThread.Query(NIL,Procedure
        begin
          Sleep(1000);
          Caption := '42';
        end;
    end;      
end;

Das ergibt aber überhaupt keinen Sinn. Zunächst ist mir

Delphi-Quellcode:

TThread.Query

völlig unbekannt. Sollte es sich dabei um

Delphi-Quellcode:

TThread.Queue

handeln, verlagerst du das

Delphi-Quellcode:

Sleep

ja wieder in den Hauptthread.

Ich hätte jetzt eher diesen Ansatz gewählt:

Delphi-Quellcode:

procedure TForm202.Button2Click(Sender: TObject);
begin
  TTask.Run(
    Procedure 
    begin
      Sleep(1000);
      TThread.Query(NIL,
        Procedure
        begin
          Caption := '42';
        end;
    end;      
end;

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1357786)

Das ergibt aber überhaupt keinen Sinn. Zunächst ist mir

Delphi-Quellcode:

TThread.Query

völlig unbekannt. Sollte es sich dabei um

Delphi-Quellcode:

TThread.Queue

handeln, verlagerst du das

Delphi-Quellcode:

Sleep

ja wieder in den Hauptthread.

Klar, sorry Schreibfehler...

Der Sinn ist ganz einfach.

Bei einem Button Klick oder anderen User-Aktionen, starten diese im UI-Thread einen Timer der die Änderungen auf dem Bildschirm (Mouseover/Buttondown/ButtonUp usw.) anzeigt.

Über den TTask.Run starte ich meine Aktionen verzögert. Der Queue Befehl sorgt dafür, dass ich dem UI_Thread die Ausführung überlasse.

Wie gesagt der bessere Weg hierfür ist der OnIdleEvent!

Zitat:

Zitat von Uwe Raabe (Beitrag 1357786)

Ich hätte jetzt eher diesen Ansatz gewählt:

Delphi-Quellcode:

procedure TForm202.Button2Click(Sender: TObject);
begin
  TTask.Run(
    Procedure 
    begin
      Sleep(1000);
      TThread.Query(NIL,
        Procedure
        begin
          Caption := '42';
        end;
    end;      
end;

Logisch!!

Mavarik :roll: