TThreadList leeren und alle Objekte freigeben?

[uups]

Zitat von stahli:

Du könntest auch mit mehreren Listen arbeiten und eine bestimmte Anzahl Einträge puffern.

Liste erstellen, bis 10.000 Einträge füllen und die Liste einer Abarbeitungsliste hinzufügen.
In einem anderen Thread könnten diese Puffer nach und nach verarbeitet und dann gelöscht werden.
So würde Dein Eingangsthread kaum blockiert werden.

Ein Ringpuffer wäre auch denkbar, wenn Du sicher bist, dass Du da in keinen Überlauf kommst.

Letztlich musst Du genauer untersuchen/erklären, welche zeitlichen Abläufe und Objektmengen Du genau hast...

Interessant, das muss ich jetzt probieren

[himitsu]

Leider wurde TThreadList schlampig programmiert, denn man kommt nicht ans TList.Notify ran ... sonst hätte man da eine "ordentliche" TObjektThreadList daraus machen können, welche auf OwnsObject=True eingestellt wird.

Es klingt ja fast danach, als wenn für dich eine Queue besser wäre, als eine Liste.


Leider ist Delphi da ebenfalls schlecht ausgestattet.
Es gibt eine TList, eine TObjectList und eine TThreadList, aber keine TObjectThreadList (und bei der kann kein Free ins Notify eingebaut werden)
Es gibt auch eine TList<T>, eine TObjectList<T>, eine TQueue<T>, eine TObjectQueue und eine TThreadedQueue<T>, aber auch hier fehlt die Möglichkeit der Speicherverwaltung/Objektfreigabe.

OK, man kann auch einfach Windows, Linux und OSX vergessen und verwendet Delphi nur noch für Android und iOS, denn mit ARC werden all diese Bugs umgangen.

[Rollo62]

Wäre da ein TThreadPool nicht angebrachter ?

Rollo

[himitsu]

Er hat wohl viele Daten-Objekte, die abgearbeitet werden sollen.

Ein ThreadPool verwaltet Threads, bzw. viele Arbeitsprozeduren, die in mehreren Threads laufen.

[Rollo62]

Ok, ich dachte er wollte die vielen Daten auch in vielen Threads bearbeiten ...

[romber]

Zitat von himitsu:

Es klingt ja fast danach, als wenn für dich eine Queue besser wäre, als eine Liste

Und wie soll das mit der Queue gehen? Ich stelle mir eine Queue als eine Verarbeitungswarteschlange vor, die nach dem first-in-first-out Prinzip abgearbeitet wird und nicht ganz dafür geignet, um die Daten dirt für eine längere Zeit abzulagern. Meine Liste repräsentiert eine CustomDataSource für DevExpress' QuantumGrid. Alle Objekte un der Liste werden im cxGrid visualisiert und bleiben in der Liste, bis diese vom Benutzer explizit geleert wird. Automatisch wird es nicht geleert.