Unterschied TTread.Synchronize / TThread.Queue

[Rollo62]

Hallo jaenicke,

ja schon klar.

Aber ich denke es geht Harry hier um das schnelle Befüllen einer ListBox / ListView.

Wie wäre es wenn man die maximale Anzahl leerer Zeilen zuvor anlegt, und dann mit Parallel schnell füllt,
so das sich jeder Thread nur um seinen Teil der ListBox Einträge kümmern muss.

Dazu müsste dann gewartet werden, und die ListBox natürlich mit Begin- EndUpdate gekapselt werden,
aber das könnte doch das Befüllen beschleunigen, wenn das ListBox Design so etwas zulässt.

Mir ist auch nicht ganz wohl dabei selbst wenn das gehen würde, weil man ja immer in der nächsten Version eine
interne Änderung in der Listbox haben könnte die dann auf einmal Crasht.

Ich würde wohl versuchen so etwas wie eine virtuelle ListBox (als virtualTree) zu bauen, die nur den sichtbaren Teil jeweils nachlädt,
aber ich würde auch erstmal darüber nachdenken warum die StandardListbox das nicht auch kann.

Vielleicht geht es ja doch irgendwie ?

Rollo

[jaenicke]

Ich selbst habe dafür die nötigen Fenster rein über die API erstellt. Dann sind die nämlich threadsicher und ich kann von mehreren Threads aus problemlos über Events auf die GUI zugreifen ohne diese zu synchronisieren.
Allerdings ist das natürlich nicht gerade der Weg, den man in Delphi gehen möchte...

Wenn es um eine Listenanzeige geht, benutze ich dafür in der Tat die VirtualStringTree. Dann aktualisiere ich gesichert per TMonitor die Daten und löse einfach ein Neuzeichnen aus.

[Uwe Raabe]

Zitat von jaenicke:

Ich selbst habe dafür die nötigen Fenster rein über die API erstellt. Dann sind die nämlich threadsicher und ich kann von mehreren Threads aus problemlos über Events auf die GUI zugreifen ohne diese zu synchronisieren.
Allerdings ist das natürlich nicht gerade der Weg, den man in Delphi gehen möchte...

Insbesondere, wenn man das Ganze unter FMX aufzieht um verschiedene Zielplattformen anzusprechen.

[Harry Stahl]

Zitat von Rollo62:

Hallo jaenicke,

ja schon klar.

Aber ich denke es geht Harry hier um das schnelle Befüllen einer ListBox / ListView.
Rollo

Nö, das war nur ein Beispiel mit dem ich ein wenig "gespielt" hatte, um ein mögliches Update der GUI zu prüfen.

Aber ich habe jetzt verstanden, dass man TParallel-For (und auch TTask) im Prinzip in der Hauptsache verwendet, um Prozesse in der Summe schneller bearbeitet zu bekommen (indem eben mehrere Prozessor-Kerne benutzt werden, wenn sie denn zur Verfügung stehen).

Der bisherige "normale" zusätzliche Thread, der Hintergrundarbeit durchführt und hin und wieder mal die GUI aktualisiert scheint mir daher durchaus weiterhin seine Berechtigung zu haben. Oder?

[jaenicke]

Zitat von Harry Stahl:

Der bisherige "normale" zusätzliche Thread, der Hintergrundarbeit durchführt und hin und wieder mal die GUI aktualisiert scheint mir daher durchaus weiterhin seine Berechtigung zu haben. Oder?

Ja, sicher, TParallel ist nur ein kleines Hilfsmittel für kleine Aufgaben um die leichter in Threads zu packen, aber für umfangreichere Aufgaben lohnt sich eher eine Umsetzung mit eigenen Threads oder Tasks.

[Stevie]

Seit der PPL denken plötzlich alle, Multithreading und parallel programming sei nen Kindergeburtstag

TParallel.For ist blockend, d.h. alles, was zurück in diesen Thread synchronisieren will, sorgt für einen Deadlock.

Wenn du innerhalb der Tasks eines parallel for die GUI updaten willst, dann musst du die parallel for in einem eigenen Thread/Task starten.

Hier mal nen kleines Nonsense Beispiel:

Delphi-Quellcode:

  TTask.Run(
    procedure
    begin
      TParallel.&For(0, 1000,
        procedure (i: Integer)
        begin
          Sleep(50);
          TThread.Queue(nil,
            procedure
            begin
              Caption := IntToStr(i);
            end);
        end);
      TThread.Queue(nil,
        procedure
        begin
          ShowMessage('done');
        end);
    end);
  ShowMessage('started');

[Uwe Raabe]

Zitat von Stevie:

Seit der PPL denken plötzlich alle, Multithreading und parallel programming sei nen Kindergeburtstag

Aus den Slides meines Vortrags auf den Delphi-Tagen 2013:

Zitat von Danny Thorpe:

New programmers are drawn to multithreading like moths to flame, with similar results.

[Mavarik]

Zitat von jaenicke:

Ja, sicher, TParallel ist nur ein kleines Hilfsmittel für kleine Aufgaben um die leichter in Threads zu packen, aber für umfangreichere Aufgaben lohnt sich eher eine Umsetzung mit eigenen Threads oder Tasks.

Nö wieso das den?

Klar sollte man je nach Aufgabe wählen...

Ich habe "alle" Arten in meiner Software...

- Herkömmliche Thread's für schnelle Reaktionen... Die werden am Anfang des Programmstarts erzeugt und warten nur noch auf ein Event... Daher startet die Verarbeitung in wenigen Nano-Sekunden (Kein Overhead)

- TTask.Run... für das "schnelle mal zwischendurch" zum Beispiel "Save Button"... Der Datenbankzugriff kommt in die anonyme procedure - hier ist der Overhead egal. Ob die Datenbank einige ms später geschrieben wird oder nicht ist egal...

- TParallel... den Overhead für den Thread-Pool gönne ich mir nur dann, wenn ich NIX Synchronisieren muss und die einzelne Verarbeitung länger dauert. Außerdem habe ich die automatische Anpassung an die Kerne... Muss mir also nicht überlegen, wie viele Worker Threads ich erzeugen darf...

- (Idleworker) ist zwar kein Thread aber von System her gehört er für mich hier in die Liste... Nach dem Motto UI-Thread Queue - wenn Du Zeit dafür hast.

Und schon wird die Thread Anwendung zum Kindergeburtstag...

Mavarik

[Rollo62]

Hallo Mavarik,

ja das Macht Sinn.

TParallel hatte ich mir noch nicht so tief angeschaut, hatte wohl eine falsche Vorstellung davon.
Ansonsten benutze ich TTask.Run schon recht häufig, für Parallel war noch keine echte Not.

Weil das so simple und schnell mit der anonymen Prozedur vonstatten geht ist das eine echte Beschleunigung, statt erst eigene Threads zu programmieren.
Das ist mein Favorit

Mit TIdleWorker habe ich mich auch seit kurzem beschäftigt, damit kann man auch die Aufgaben schön entkoppeln.

Es macht halt alles Sinn, man sollte nur wissen was geht und was nicht, daran hapert es meistens.

Rollo

[jaenicke]

Zitat von Rollo62:

Weil das so simple und schnell mit der anonymen Prozedur vonstatten geht ist das eine echte Beschleunigung, statt erst eigene Threads zu programmieren.

TThread.CreateAnonymousThread gibt es allerdings auch noch.