Unterschied TTread.Synchronize / TThread.Queue

[Harry Stahl]

Hallo,

ich habe gerade male eine Verständnisfrage zur Verwendung von TThread.Synchronize und TThread.Queue.

Beide proceduren verwendet man ja im Prinzip, um von einem Thread außerhalb des MainThreads auf Daten bzw. GUI-Elemente des Hauptthreads zuzugreifen.

Während ich bei der Verwendung der beiden Proceduren bislang in TTask keinen großen Unterschied bemerkt habe, frage ich mich gerade, warum in dem folgenden TParallel-For Beispiel der Aufruf mit Queue funktioniert, der mit Synchronize sich aber aufhängt:

Delphi-Quellcode:

procedure TForm14.Button1Click(Sender: TObject);
var
  L: Integer;
begin
  Listbox1.Clear;

  TParallel.For (1,10, procedure (i:Integer)
  begin
    //TThread.Synchronize(NIL,  //--> funktioniert nicht, Programm hängt
    TThread.Queue(NIL, // das geht
    procedure
    begin
      ListBox1.Items.Add( 'Nummer' + i.tostring);
    end);
  end);
end;

Mir ist durchaus bekannt, dass Synchronize eine "blocking" Methode ist, "Queue" aber nicht, dennoch hätte ich angenommen, dass die Abarbeitung grundsätzlich hier auch mit Synchronize funktionieren würde. Tut es aber nicht.

Hat jemand eine Erklärung dafür?

[jaenicke]

Du bleibst ja während der Ausführung der einzelnen Threads im Hauptthread im Aufruf von TParallel.For. Deshalb können die anderen Threads in dieser Zeit auch nicht mit dem Hauptthread synchronisieren, da der gleichzeitig auf die einzelnen Schleifenthreads wartet.

Das ist ein klassischer Deadlock.

[Harry Stahl]

Verstehe ich das richtig, dass TParallel.for dann so eine Art Mischung zwischen Ablauf im Hauptthread und eigener Thread ist?

Im Gegensatz zu TTask, was ja wirklich ein eigener Thread ist, daher kann man dort beides (also Queue oder Synchronize) verwenden?

[Uwe Raabe]

Du kannst das in deinem Beispiel sehen, wenn du nach dem TParallel.For einfach noch eine Zeile

Delphi-Quellcode:

  ListBox1.Items.Add('Ende');

einfügst.

[Sir Rufo]

Das

Delphi-Quellcode:

TParallel.&For()

ist wie ein

Delphi-Quellcode:

LTask := Task.Run( ... );
LTask.Wait();

Und dort würde auch ein Synchronize einen Deadlock erzeugen.

[Harry Stahl]

Zitat:

Zitat von Sir Rufo (Beitrag 1309179)

Das

Delphi-Quellcode:

TParallel.&For()

ist wie ein

Delphi-Quellcode:

LTask := Task.Run( ... );
LTask.Wait();

Und dort würde auch ein Synchronize einen Deadlock erzeugen.

Aber nur wegen des LTask.Wait.

Zitat:

Zitat von Uwe Raabe (Beitrag 1309178)

Du kannst das in deinem Beispiel sehen, wenn du nach dem TParallel.For einfach noch eine Zeile

Delphi-Quellcode:

  ListBox1.Items.Add('Ende');

einfügst.

Das wird dann als erstes in die Liste eingefügt und erst später die Einträge aus dem Parallel.Loop. Daraus kann ich dann folgern, dass ich die ganze Zeit noch im Mainthread war, oder?

Aber grundsätzlich Danke, ich glaube, ich komme der Sache vom Verständnis her näher.

[jaenicke]

Zitat:

Zitat von Harry Stahl (Beitrag 1309189)

Zitat:

Zitat von Uwe Raabe (Beitrag 1309178)

Du kannst das in deinem Beispiel sehen, wenn du nach dem TParallel.For einfach noch eine Zeile

Delphi-Quellcode:

  ListBox1.Items.Add('Ende');

einfügst.

Das wird dann als erstes in die Liste eingefügt und erst später die Einträge aus dem Parallel.Loop. Daraus kann ich dann folgern, dass ich die ganze Zeit noch im Mainthread war, oder?

Wenn du Queue benutzt, werden die Threadinhalte tatsächlich erst hinterher ausgeführt. Das liegt aber nicht daran, dass die Schleifeninhalte hinterher ausgeführt werden, sondern an der Auskoppelung durch Queue.

Das kannst du sehr gut an diesem Beispiel sehen:

Delphi-Quellcode:

  MessageBox(0, 'Vorher', 'Test', 0);
  TParallel.For (1,2, procedure (i:Integer)
  begin
    MessageBox(0, PChar(i.ToString), 'Test', 0);
  end);
  MessageBox(0, 'Nachher', 'Test', 0);

Du wirst sehen, dass die Messagebox "Nachher" erst angezeigt wird, wenn die beiden anderen bestätigt sind. Das kannst du aber ja auch einfach mit einem Haltepunkt sehen.

[Sir Rufo]

Da in

Delphi-Quellcode:

TParallel.&For

eben genau dieses

Delphi-Quellcode:

Wait

gemacht wird, muss/kann man es damit vergleichen.

[Rollo62]

Aber in TParallel laufen doch im besten Fall mehrere Threads parallel ab (hoffentlich).
Und das TaskWait kommt für alle am Ende, oder nicht ?

Wie sollte man das den jetzt aufbauen damit es threadsafe wird, geht das überhaupt ?

Die Strings z.B. in TDictionary o.ä zwischenspeichern, und dann nach der TParallel Schleife in die
Listbox übertragen ?
Oder die gute alte TStringList ?
Dann würden zwar die Berechnungen parallel laufen, aber die Übertragung in die Listbox wieder im Hauptthread.

Dann wäre doch das TParallel in solchen Fällen nicht besonders sinnvoll, nur da wo es keine
Inputs zu Komponenten im Hauptthread geben muss.

Oder gibt es eine Konstellation wie man das auch mit TListBox parallel hinbekommt ?

Rollo

[jaenicke]

Zitat:

Zitat von Rollo62 (Beitrag 1309314)

Dann wäre doch das TParallel in solchen Fällen nicht besonders sinnvoll, nur da wo es keine
Inputs zu Komponenten im Hauptthread geben muss.

TParallel ist nur für die Daten- und Logikteile der Anwendung gedacht, nicht für die GUI, ja. Ehrlich gesagt habe ich es da aber auch nie vermisst, da im Hauptthread ohnehin keine längeren Operationen laufen sollten. Und der Teil, der TParallel benutzt, ist ja per Definition eine solche längere Operation, sonst bräuchte man ja keine Threads.

Es sollte also in dem Fall einfach ein Thread für die ursprüngliche Verarbeitung gestartet werden und schon ist das Problem gelöst.