TTask & Synchronize Verständnisproblem

[weisswe]

Hallo!

Habe ein Verständnisproblem bei TTask.
Wollte nur Variablen der "Hauptprocedur" an den Task beim Start übergeben.
Jedoch bekomme ich nicht die richtigen Werte (meist -> 1,2,3,4,6,6).
Ich verstehe ja, das die Tasks unabhängig/zeitversetzt gestartet werden - nur wie bekomme ich Variablen "synchronisiert" beim Start des Tasks in den Task.
Hoffe habe mich irgendwie verständlich ausgedrückt. :?

Delphi-Quellcode:

   SetLength(tasks, anz);
   for i := 0 to anz - 1 do
   begin
      fn := Files[i].Filename;
      s := fn + ' wird heruntergeladen...';
      line := Memo1.Lines.Add(s);
      Files[i].Zeilennummer := line;
      tasks[i] := TTask.Create (
         procedure ()
         var j: Integer;
             tfn, ss: String;
         begin
            TInterlocked.Exchange(j, i);  // !!?? zu spät?
            TThread.Synchronize(nil,
            procedure
            begin
               tfn := fn;  // !!?? zu spät?
            end);
            ok := DownloadFile(tfn);    // Herunterladen - zeitintensiv
            TThread.Synchronize(nil,
            procedure
            begin
               ss := tfn + ' wurde heruntergeladen.';
               Memo1.Lines.Add(IntToStr(j) + ' - ' + ss);
            end);
         end);
      tasks[i].Start;
   end;

[Uwe Raabe]

Innerhalb der anonymen Methode wird immer der gerade aktuelle Wert der Variablen i und fn verwendet. Da dieser zur Ausführung in der Task schon ein anderer sein kann als zur Erzeugung der Task, kommt es zu diesem Verhalten. Du kannst aber die anonyme Methode auch über eine Funktion erzeugen lassen, der du den i- und fn-Parameter mitgibst. Dabei erhalten die Parameter ihre Werte aus dem Hauptthread und stehen der Task exklusiv zur Verfügung (Code ungetestet).

Delphi-Quellcode:

function CreateMyTask(I: Integer; fn: string; HandleResult: TProc<string>): TProc;
begin
  result :=
    procedure ()
    var
      ok: Boolean;
    begin
      ok := DownloadFile(fn); // Herunterladen - zeitintensiv
      TThread.Synchronize(nil,
        procedure
        var
          ss: String;
        begin
          if ok then begin
            ss := fn + ' wurde heruntergeladen.';
          end
          else begin
            ss := fn + ' wurde nicht heruntergeladen.';
          end;
          HandleResult(IntToStr(i) + ' - ' + ss);
        end);
    end;
end;

...

   SetLength(tasks, anz);
   for i := 0 to anz - 1 do
   begin
      fn := Files[i].Filename;
      s := fn + ' wird heruntergeladen...';
      line := Memo1.Lines.Add(s);
      Files[i].Zeilennummer := line;
      tasks[i] := TTask.Create(CreateMyTask(i, fn,
        procedure (Arg: string)
        begin
          Memo1.Lines.Add(Arg);
        end));
      tasks[i].Start;
   end;

[Der schöne Günther]

Und spätestens hier sollte man anhand der Lesbarkeit sehen dass es besser wäre das Herunterladen und das Anzeigen in der Oberfläche zu trennen. Auf Dauer bleibt es bestimmt nicht bei einem einfachen

Delphi-Quellcode:

Memo1.Lines.Add(..)

... :warn:

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1368241)

Und spätestens hier sollte man anhand der Lesbarkeit sehen dass es besser wäre das Herunterladen und das Anzeigen in der Oberfläche zu trennen. Auf Dauer bleibt es bestimmt nicht bei einem einfachen

Delphi-Quellcode:

Memo1.Lines.Add(..)

... :warn:

:thumb: Vielleicht dann besser gleich so?

Dazu kommt noch, daß das Synchronize eh die letzte Aktion der Task ist und somit auch durch ein Queue ersetzt werden kann.

Delphi-Quellcode:

function CreateMyTask(I: Integer; fn: string; HandleResult: TProc<Integer, string, Boolean>): TProc;
begin
  result :=
    procedure ()
    var
      ok: Boolean;
    begin
      ok := DownloadFile(fn); // Herunterladen - zeitintensiv
      TThread.Queue(nil,
        procedure
        begin
          HandleResult(i, fn, ok);
        end);
    end;
end;

function CreateResultHandler(Target: TStrings): TProc<Integer, string, Boolean>;
begin
  Result :=
    procedure (Idx: Integer; FileName: string; OK: Boolean)
    var
      ss: string;
    begin
      if OK then begin
        ss := FileName + ' wurde heruntergeladen.';
      end
      else begin
        ss := FileName + ' wurde nicht heruntergeladen.';
      end;
      Target.Add(ss);
    end;
end;

...

SetLength(tasks, anz);
for i := 0 to anz - 1 do
begin
  fn := Files[i].Filename;
  s := fn + ' wird heruntergeladen...';
  line := Memo1.Lines.Add(s);
  Files[i].Zeilennummer := line;
  tasks[i] := TTask.Create(CreateMyTask(i, fn, CreateResultHandler(Memo1.Lines)));
  tasks[i].Start;
end;

[Mavarik]

Oder eher nicht...

Ok, der ThreadPool managed nur so viele gleichzeitige Thread wie es für die CPU - Core Anzahl sinnvoll ist, aber ist das auch sinnvoll für einen download?

i.d.R. nicht...

Hier würde ich die Anzahl begrenzen.
Das geht nicht über den Threadpool.

Mavarik

[Zacherl]

Zitat:

Zitat von Mavarik (Beitrag 1368255)

aber ist das auch sinnvoll für einen download?

Threads die primär IO-Operationen ausführen sind tatsächlich immer recht kritisch zu sehen. Zumindest ist deren Verhalten im Hinblick auf Performance deutlich abweichend zu CPU-lastigen Threads. Muss man denke ich individuell betrachten.

Zitat:

Zitat von Mavarik (Beitrag 1368255)

Hier würde ich die Anzahl begrenzen.
Das geht nicht über den Threadpool.

Doch doch, man kann die maximale Threadanzahl einstellen, oder sich sogar einen custom ThreadPool erzeugen, der dann dediziert nur für eine spezielle Art von Tasks verwendet werden kann :)

[Mavarik]

Zitat:

Zitat von Zacherl (Beitrag 1368282)

Doch doch, man kann die maximale Threadanzahl einstellen, oder sich sogar einen custom ThreadPool erzeugen, der dann dediziert nur für eine spezielle Art von Tasks verwendet werden kann :)

Ja, aber Achtung:

Zitat:

Zitat von System.Threading.pas

Delphi-Quellcode:

function TThreadPool.SetMaxWorkerThreads(Value: Integer): Boolean;
begin
  Result := Value >= TThread.ProcessorCount;
  if Result then
    TInterlocked.Exchange(FMaxLimitWorkerThreadCount, Value);
end;

Mavarik

[Zacherl]

Zitat:

Zitat von Mavarik (Beitrag 1368298)

Ja, aber Achtung:

Zitat:

Zitat von System.Threading.pas

Delphi-Quellcode:

function TThreadPool.SetMaxWorkerThreads(Value: Integer): Boolean;
begin
  Result := Value >= TThread.ProcessorCount;
  if Result then
    TInterlocked.Exchange(FMaxLimitWorkerThreadCount, Value);
end;

Das ist ja echt eine blöde Limitierung :?

[jaenicke]

Warum sollte man denn das Maximum geringer setzen wollen als die Anzahl der CPU Kerne?

Wenn man weiß, dass eine Aktion z.B. die Festplatte sehr stark beansprucht, ist ein Threadpool eher nicht geeignet, weil man dann ja gar nicht viele Tasks parallel möchte.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1368339)

Warum sollte man denn das Maximum geringer setzen wollen als die Anzahl der CPU Kerne?

Weil man das System nicht komplett auslasten will?

[jaenicke]

Dafür gibt es ja Prioritäten für Threads und Prozesse. Es macht doch keinen Sinn dann z.B. drei Kerne voll auszulasten und den vierten leer laufen zu lassen nur für den Fall, dass er benötigt wird...

[Uwe Raabe]

Gerade die Downloads sind ja in der Regel nicht sonderlich prozessorintensiv. Solange das Warten auf den Empfang des nächsten Datenpakets bzw. dessen Schreiben auf Platte nicht mit einem Busy-Wait implementiert ist, regelt sich das eigentlich ganz von selber.

Andererseits geht auch hier nichts über reale Messungen.

[Mavarik]

Zitat:

Zitat von jaenicke (Beitrag 1368339)

Warum sollte man denn das Maximum geringer setzen wollen als die Anzahl der CPU Kerne?

Eben... Es gab mal eine Theorie, dass auf einem mobilen Gerät weniger Strom verbraucht wird, wenn man nicht alle Kerne benutzt, aber ich denke das stimmt nicht.

Aber für einen Download gelten andere Regeln, z.B. wenn der Server nur 1x die IP zu lässt.

Je nach Server und Bandbreite sind ca. 4 Thread optimal (bei großen Dateien) bei Tausenden kleinen sind mehr Thread besser...

Für den Download und die Verarbeitung der Daten empfehle ich sowas sie meine Parallel-Multithreading-Pipeline.

Wie man es implementiert ist fast egal - man kann auch einfach "nur" eine Anzahl von Workerthreads per Hand erzeugen und so die Daten verarbeiten.

Mavarik

[Uwe Raabe]

Zitat:

Zitat von Mavarik (Beitrag 1368373)

Aber für einen Download gelten andere Regeln, z.B. wenn der Server nur 1x die IP zu lässt.

Wer sagt denn, daß die Downloads alle von demselben Server kommen? Aber selbst wenn, dann warten die anderen Download-Threads auf den freiwerdenden Socket und benötigen dabei vermutlich auch keine CPU-Zeit. Dafür skaliert das System automatisch sobald mehrere gleichzeitige Downloads möglich sind. Ich sehe immer noch keinen Vorteil darin, die Anzahl der Threads zu begrenzen.

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1368376)

Wer sagt denn, daß die Downloads alle von demselben Server kommen?

Es war ja nur ein Beispiel.

Zitat:

Zitat von Uwe Raabe (Beitrag 1368376)

Aber selbst wenn, dann warten die anderen Download-Threads auf den freiwerdenden Socket und benötigen dabei vermutlich auch keine CPU-Zeit.

Das "glaube" ich nicht... Server die so eine Begrenzung haben liefert i.d.R. eine Fehlerseite. Bedeutet alle Threads die nachträglich gestartet werden laufen in leere und der download wird unproduktiv.

Aber vielleicht sollte man diese Theorien mal gegen ein Testsystem laufen lassen... :stupid:

Mavarik

[Uwe Raabe]

Ich stelle gerade fest, daß wir uns ziemlich weit vom ursprünglichen Thema entfernt haben :oops:

[Mavarik]

Zitat:

Zitat von Uwe Raabe (Beitrag 1368383)

Ich stelle gerade fest, daß wir uns ziemlich weit vom ursprünglichen Thema entfernt haben :oops:

8-) Stimmt... Die Frage war ja auch eigentlich mit #2 beantwortet...