TTask.WaitForAll hängt

[Schokohase]

Zitat:

Zitat von haentschman (Beitrag 1443063)

Zitat:

Wird irgendwo von DirList ein TThread.Synchronize aufgerufen? Nein? Dann ist das die Ursache für den DeadLock.

...das Nein hat gefehlt. :zwinker:

Really, George?

Zitat:

Wird irgendwo von

Delphi-Quellcode:

DirList

ein

Delphi-Quellcode:

TThread.Synchronize

aufgerufen?

Ja wenn das zutrifft

Zitat:

Dann ist das die Ursache für den DeadLock.

Bei Nein gäbe es ja keine Ursache für den DeadLock (weil ja

Delphi-Quellcode:

TThread.Synchronize

NICHT aufgerufen wird).

Aber vielleicht habe ich ja auch von deutscher Sprache einfach keine Ahnung. Dann entschuldige ich mich auch hier für die Störung.

[haentschman]

Zitat:

Aber vielleicht habe ich ja auch von deutscher Sprache einfach keine Ahnung. Dann entschuldige ich mich auch hier für die Störung.

:gruebel: Was ist denn mit dir los?

[HolgerX]

Hmm....

Zitat:

Zitat von Smiley (Beitrag 1443030)

Hier die DirList Routine.
Wenn nur ein Task läuft, wo soll dann ein Deadlock eintreten ???
Das WaitForAll wird in dem Beispiel von Embarcadero verwendet und ich wollte es benutzen um nicht mit einem eigene Flag arbeiten zu müssen.

Kann ich dann mal ein Beispiel mit EndMessage sehen ?

Delphi-Quellcode:

// *****************************************************************************
procedure TForm1.DirList;
var
  // SearchResult
  MainVerz: TStringDynArray;
  SearchResult: TStringDynArray;
  FilterMaske: String;

  I: Integer;
begin

  StartFolder := '\\SCHLUPP\Praktikant\Delphi\Tutorial\';

  // Filter für *.pdf, *.docx,...
  FilterMaske := '*.*';

  // Grid.StartUpdate;
  GridInit;
  AktLine := 1;
  ListBox1.clear;

  // Uses IOUtils für GetDir..und System.Types für DynArray hinzufügen
  // Alle Hauptverzeichnisse einlesen und dann pro Verz. eine Suche ausführen in eigenem Thrad
  StartTime := Now();
  MainVerz := TDirectory.GetDirectories(StartFolder, TSearchOption.soTopDirectoryOnly, nil);
  Form1.ProgressBar1.Max := high(MainVerz);
  qV.Open;
  for j := 0 to High(MainVerz) do
    begin
      ListBox1.Items.Add(MainVerz[j]);
      try
        Begin
          // Einlesen der Dateien ab dem Verz[j]
          SearchResult := TDirectory.GetFiles(MainVerz[j], FilterMaske, TSearchOption.soAllDirectories);
          for I := 0 to High(SearchResult) do
            begin
              if SearchResult[I] <> '' then
                begin
                  // grid.Cells[1, AktLine] := ExtractFilename(SearchResult[I]);
                  // grid.Cells[2, AktLine] := ExtractFilePath(SearchResult[I]);
                  qV.append;
                  qV.FieldByName('Verzeichnis').AsString := ExtractFilePath(SearchResult[I]);
                  qV.FieldByName('Datei').AsString := ExtractFileName(SearchResult[I]);
                  qV.FieldByName('Kategorie').AsString := '';
                  qV.Post;
                  inc(AktLine);
                end;
            end;
          ListBox1.Items.Add('Task ' + IntToStr(j) + ' Zeit: ' + FormatDateTime('hh:nn:ss:zzz', Now - StartTime));
          StartTime := Now();
          ListBox1.Refresh;
        End;
      except
        // Catch the possible exceptions
        MessageDlg('Incorrect path or search mask', mtError, [mbOK], 0);
        Exit;
      end;
      Form1.ProgressBar1.Position := j;
    end;
  LTaskRun := false;
end;

Und da haben wir deinen DEADLOCK...

Es wird in DirList auf eine 'visuelle' Komponente zugegriffen, welche 'Messages' generiert und auf dessen Ausführung wartet!

Die Komponente ist die ListBox1 (sowie auch der ProgressBar1)!
(beim Clear und bei jedem Add werden Messages generiert, auf dessen Result die ListBox 'wartet' (per SendMessage))

Da dessen Messages im MainThread (Ersteller der ListBox) verarbeitet werden, dieser jedoch mit WaitForAll wartet und keine Messages bearbeiten kann, bleibt die App in einem Deadlock hängen!!!

Baue deine Procedure DirList so um, dass die Sammlung der Informationen (Dateinamen..) in einer eigenen 'nicht visuellen' Liste (z.B. TObjectList mit je einem eigenen Objekt je Dateinamen) gesammelt werden und erst nach dem Durchlauf und außerhalb des Tasks visualisiert wird..

[HolgerX]

Hmm..

Ach ja, und wenn Du es umbaust, dass verwende eventuell ein TThread, nicht TTask..
Ein TThread hat ein 'OnTerminate' Event, welches bereits mit dem MainThread synchronisiert aufgerufen wird.

Wenn diese (abgeleitete) TThread eine Property mit der Objektliste deiner Dateieinträge hat, kannst Du dann darauf zugreifen und deine ListBox füllen.

Der TThread hat auch ein WaitFor, welches Du dann aber nicht brauchst..

[Uwe Raabe]

Zitat:

Zitat von HolgerX (Beitrag 1443095)

Ach ja, und wenn Du es umbaust, dass verwende eventuell ein TThread, nicht TTask..
Ein TThread hat ein 'OnTerminate' Event, welches bereits mit dem MainThread synchronisiert aufgerufen wird.

Das ist aber eine recht rückschrittliche Empfehlung. Es ist überhaupt kein Problem, in einem Task eine beliebige Aktion im Mainthread auszuführen - nicht nur beim Beenden:

Delphi-Quellcode:

  TTask.Run(
    procedure
    begin
      DirList;
      TThread.Queue(nil, 
        procedure
        begin
          // tue was, nachdem DirList beendet wurde
        end;
    end);

Das löst aber natürlich nicht das Problem mit den Zugriffen auf VCL-Objekte innerhalb DirList. Da steckt vermutlich noch der größte Aufwand bevor das threadsicher wird.

[p80286]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443103)

Das löst aber natürlich nicht das Problem mit den Zugriffen auf VCL-Objekte innerhalb DirList. Da steckt vermutlich noch der größte Aufwand bevor das threadsicher wird.

Spricht etwas dagegen aus einer Task heraus an die GUI Messages zu senden? dann kann man auch die Geschwätzigkeit der Oberfläche erhalten.

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1443108)

Spricht etwas dagegen aus einer Task heraus an die GUI Messages zu senden? dann kann man auch die Geschwätzigkeit der Oberfläche erhalten.

Erstmal nicht. Ich würde das dann aber so implementieren, daß ein Queue anstatt eins Synchronize verwendet werden kann. Andernfalls bremst man die Task aus bzw. degradiert sie zu einer ineffizienten State-Machine.

Es sind aber ja nicht nur die GUI-Objekte ListBox1 und ProgressBar1 (diese Namen :stupid:), die aus dem Thread angesprochen werden. Neben des DataSet qV sind da auf den ersten Blick noch StartFolder, GridInit, AktLine und StartTime - das LTaskRun sollte mit dem Ansatz eigentlich obsolet sein.

Die ganze Routine ist sowas von thread-untauglich, daß ich gar nicht weiß, wo ich anfangen soll. Solange hier nicht ein tieferes Verständnis bezüglich Thread-Sicherheit von Code aufgebaut wird, würde ich von solchen Threading-Abenteuern absehen.

[p80286]

Wow, Du hast wirklich besser gelesen als ich (qv ist mir vollständig durch die Lappen gegangen).
Hättest Du denn eine Quelle für das notwendige Wissen?
(Auch ich würde mein zusammen gestoppeltes Wissen gerne abrunden)

Gruß
K-H

[Uwe Raabe]

Zitat:

Zitat von p80286 (Beitrag 1443120)

Hättest Du denn eine Quelle für das notwendige Wissen?

Nicht wirklich...

[dummzeuch]

Zitat:

Zitat von Uwe Raabe (Beitrag 1443103)

Zitat:

Zitat von HolgerX (Beitrag 1443095)

Ach ja, und wenn Du es umbaust, dass verwende eventuell ein TThread, nicht TTask..
Ein TThread hat ein 'OnTerminate' Event, welches bereits mit dem MainThread synchronisiert aufgerufen wird.

Das ist aber eine recht rückschrittliche Empfehlung. Es ist überhaupt kein Problem, in einem Task eine beliebige Aktion im Mainthread auszuführen - nicht nur beim Beenden:

Delphi-Quellcode:

  TTask.Run(
    procedure
    begin
      DirList;
      TThread.Queue(nil, 
        procedure
        begin
          // tue was, nachdem DirList beendet wurde
        end;
    end);

Auch nicht dann, wenn der Main Thread mit WaitForAll auf die Ausführung wartet?
(Ernst gemeinte Frage, ich weiß das wirklich nicht, ich habe TTask noch nie verwendet.)