Ist die Verwendung von TTask so korrekt?

[a.def]

Zitat von Uwe Raabe:

Zitat von a.def:

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

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

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 von HolgerX:

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 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 ShowMessage wird irgendwann ein Application.ModalStarted und ein Application.ModalEnded aufgerufen. Darin ist das Verändern von FModalLevel schon mal nicht wirklich threadsicher. Weiterhin wird gegebenfalls ein OnModalBegin bzw. 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 von Uwe Raabe:

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

[HolgerX]

Hmm..

Wer lesen kann ist im Vorteil!

Zitat von t.roller:

Zitat von HolgerX:

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.