Hallo,

ich habe eine TThreadList, der pro Sekunde bis zu 300 Items hinzugefügt werden. Dementsprechend hoch kann auch die Zahl der Items in der Liste sein, wenn diese länger nicht geleert wird. Die Liste zu leeren sollte an sich kein großes Problem sein. Aber wie gebe ich dabei die Objekte frei, die in von Liste verwaltet werden?

Darf ich bei einer sehr langen Liste, die geleert werden muss, die Objekte in einer Schleife innerhalb des geloockten Bereichts freigeben?

Ich meine, bei einer so großen Zahl der neuen Objekte, die hinzufügt werden müssen, sollte die Liste nicht so lange blockiert werden, oder? Anderseits, sehe ich keine andere Möglichkeit, dies zu vermeiden, da ich auf die Objekte in der Liste sowieso erst zugreifen kann, wenn diese blockiert ist.

Wie würdet Ihr vorgehen? Was wäredie schnellste und perfomanteste Methode, eine TThreadList zu leeren und alle Objekte freizugeben?

So etwa habe ich mir das vorgestellt:

zusammenfalten · markieren

Delphi-Quellcode:

procedure TImmObjects.Clear;
var
  List: TList;
  i: integer;
begin
  List := TImmList.LockList;
  try
    for i := 0 to List.Count - 1 do
    begin
      if Assigned(List.Item[i]) then
      TImmObject(List.Item[i]).Free;
    end;
    List.Clear;
  finally
    TImmList.UnlockList;
  end;
end;

In diesem Fall bleibt die Liste über eine längere Zeit blockiert. Ob das so in Ordnung ist?

Hallöle...

Im Prinzip kannst du das so machen. Ich würde aber die Schleife andersherum laufen lassen oder mit repeat until und Delete/Free bis List.Count = 0...

zusammenfalten · markieren

Delphi-Quellcode:

procedure TImmObjects.Clear;
var
  List: TList;
  i: integer;
begin
  List := TImmList.LockList;
  try
    for i := List.Count - 1 downto 0 do
    begin
      if Assigned(List.Item[i]) then
      TImmObject(List.Item[i]).Free;
    end;
    List.Clear;
  finally
    TImmList.UnlockList;
  end;
end;

...jeder wie er mag.

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...

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

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.

Wäre da ein TThreadPool nicht angebrachter ?

Rollo

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.

Vielen Dank für die schnelle Reaktion!

Die Schleife rückwärts laufen zu lassen ist eine gute Idee. Danke!

Zitat von uups:

Vielen Dank für die schnelle Reaktion!

Die Schleife rückwärts laufen zu lassen ist eine gute Idee. Danke!

Das hat aber "nur" etwas mit der Speicherverwaltung zu tun...

Der Vorschlag mit den 2 Listen ist sicherlich eine gute Idee...

Ich hätte das auch über getrennte ThreadedQueues gemacht...

Mavarik