Zitat von a.def:

Ich habe ein ähnliches Szenario wie du und bin immer gut mit TThread.Queue() klar gekommen. Soweit ich weiß legt Queue alles im Stack ab und dann wird der Stack nach und nach abgearbeitet.

Das schon. Allerdings werden in meinem Fall mehrere Aufgaben gleichzeitig gestartet, bis die zuvor festgelegte (für jedes System individuell errechnete) Maximalzahl von gleichzeitig zu ausführenden Aufgaben erreicht ist. Im Fall mit TThread.Queue() wird der Stack sequentiell verarbeitet.

Ok daran habe ich nicht gedacht.
Demnach bringen mehrere Threads mit derselben Aufgabe rein gar nicht, wenn man mit Queue alles in den Stack legt.
Dann müssen wohl die Profis ran

Andererseits... du fügst doch nur Einträge in eine ObjectList hinzu.
Die eigentliche Arbeit findet doch woanders statt. Dann sollte Queue doch eigentlich doch kein Problem sein.

.. eventuell magst Du ja auch die TObjectList mit der TThreadList austauschen?

Grüße
Klaus

Zitat von Klaus01:

.. eventuell magst Du ja auch die TObjectList mit der TThreadList austauschen?

Könnte man machen, aber dabei erübrigt sich lediglich die TCriticalSection für den Zugriff auf TObjectList. Die eigentliche Frage bleibt aber: reicht allein die Absicherung der TObjectList oder muss ich auch noch den Zugriff auf den Thread mittels AddToQueue() oder Count() absichern?

Count ist doch nur lesend. Ich denke da muss man nix absichern.

Zitat von uups:

Zitat von Klaus01:

.. eventuell magst Du ja auch die TObjectList mit der TThreadList austauschen?

Könnte man machen, aber dabei erübrigt sich lediglich die TCriticalSection für den Zugriff auf TObjectList. Die eigentliche Frage bleibt aber: reicht allein die Absicherung der TObjectList oder muss ich auch noch den Zugriff auf den Thread mittels AddToQueue() oder Count() absichern?

Das eine CriticalSection im Object (in der ObjectListe) vorhanden ist, sorgt ja nicht dafür das sie threadsafe ist.
Das wird durch "enter" und "leave" sichergestellt.
Mit der ThreadList müsstest Du dich nicht mehr darum zu kümmern zugriffe auf die Liste abzusichern.
Das macht die Klasse dann automatisch.

Grüße
Klaus

A propos Zugriffe.

Muss man nur schreibende Zugriffe mit einer CriticalSection absichern oder auch lesende?

Zitat von a.def:

A propos Zugriffe.

Muss man nur schreibende Zugriffe mit einer CriticalSection absichern oder auch lesende?

ich würde auch lesende absichern.
Denn ich denke es wird krachen wenn ein Listenelemet gelesen wird und ein anderer Thread löscht im gleichen Zeitraum diese Element.

Grüße
Klaus

Zitat von a.def:

Muss man nur schreibende Zugriffe mit einer CriticalSection absichern oder auch lesende?

Ich würde spontan sagen, sowohl als auch. Anderfalls könnte ich mir die Existenz des sehr langsamen TMultipleReadExclusiveWriteSynchronizer nicht erklären können.

Zitat von a.def:

Die eigentliche Arbeit findet doch woanders statt...

So ist es. Der Thread startet für jede Aufgabe einen neuen Thread, der die eingentliche Verarbeitung der Daten übernimmt. Die Queue ist genau dafür da, um die Anzahl dieser Verarbeitungsthreads nicht zu überschreiten und damit das System zu überlasten.

Zitat von a.def:

.. Dann sollte Queue doch eigentlich doch kein Problem sein.

Doch, denn die Aufrufe der Verarbeitungsthreads landen dann immer noch im Stack.