Zitat von uups:

Zitat von Zacherl:

Schau dir mal TThreadPool an. Der ist genau für solche Zwecke gedacht. Du kannst dort einen MaxThreadCount einstellen und Tasks queuen. Der Pool arbeitet dann alle Aufgaben ab, aber erstellt nie mehr gleichzeitige Threads als angegeben (ist btw. auch deutlich performanter, da Thread Creation zumindest unter Windows einen ziemlichen Overhead hat und der ThreadPool die Threads wiederverwendet).

Klingt toll. Wenn ich richtig recherchiert habe, ist der TThreadPool ein Teil der neuen Parallel Library, oder? Heisst das etwa, ich muss mich dann nur um die Erstellung eines neuen Tasks kümmern und den Rest der geschichte vergessen?

Exakt Du fütterst den Pool mit Tasks und der Rest sollte dann automatisch ablaufen.

Zitat von uups:

Es gibt ein s.g. vordefinierter DefaultPool. Von dem kann man die Zahl der Threads abrufen, die problemlos gleichzeitig laufen können. Gilt dieser Wert für das gesammte System oder nur für die aktuelle Anwendung? Ist es sinnvoll, einen eingenen ThreadPool zu erstellen?

Wenn ich das richtig in Erinnerung habe, skaliert der Default-Pool die maximale Anzahl an Threads anhand der CPU Spezifikation (Anzahl der Kerne) und der CPU Auslastung, also ist eher ein globaler Wert. Für deinen Anwendungsfall würde ich keinen seperaten Pool erstellen.

Zitat von Zacherl:

Exakt Du fütterst den Pool mit Tasks und der Rest sollte dann automatisch ablaufen.

Gibt es auch eine Möglichkeit, bestimmte Tasks zu priorisieren?

In meinem Fall hat die Verarbeitung der eingehenden Daten eine höhere Priorität, als andere zweitrangige Aufgaben, die sich eventuell erst während der Verarbeitung ergeben. Für diese zweitrangige Aufgaben existieren nähmlich auch Queue-Threads, die ihre Aufgaben mit einer niedriegeren Priorität abarbeiten.

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.

Man muss alle gleichzeitigen Zugriffe absichern, die nicht atomar sind, sobald ein Prozess ggf. etwas schreibt.
Übrigens: auch ein I := J oder ein Inc(I) ist - auf Prozessorebene - nicht atomar.

Wenn man gemeinsame Zugriffe nicht korrekt absichert, kann man von falschen Werten bis Programmabstürzen alles erhalten.

Zitat von uups:

Zitat von Zacherl:

Exakt Du fütterst den Pool mit Tasks und der Rest sollte dann automatisch ablaufen.

Gibt es auch eine Möglichkeit, bestimmte Tasks zu priorisieren?

Leider nicht Zumindest nicht, als ich das letzte Mal einen Blick drauf geworfen habe. Tatsächlich habe ich mir dann beholfen, indem ich zwei ThreadPools manuell erstellt habe, wobei Der mit den priorisierten Tasks 10 gleichzeitig abarbeiten durfte, während der andere Pool auf Zwei beschränkt war. Ist natürlich auch nicht wirklich ideal.

Zitat von Zacherl:

Leider nicht Zumindest nicht, als ich das letzte Mal einen Blick drauf geworfen habe.

Scheint sich bis jetzt auch nicht geändert zu haben.

Zitat von Zacherl:

Tatsächlich habe ich mir dann beholfen, indem ich zwei ThreadPools manuell erstellt habe, wobei Der mit den priorisierten Tasks 10 gleichzeitig abarbeiten durfte, während der andere Pool auf Zwei beschränkt war. Ist natürlich auch nicht wirklich ideal.

Genauso handle ich jetzt auch mit den unterschiedlichen Queues. Dabei habe ich aber noch die Möglichkeit, mit TThreadPriority die Priorität des jeweiligen Queue-Threads anzupassen. Es gibt aber oft geteilte Meinung, dass dies auch nicht die beste Lösung ist.

Es hat mich auch interessiert, wie ich einem TTask meine Parameter übergeben kann. Dabei bin ich auf diesen Post gestossen, verstehe aber nicht ganz, wieso im Beispiel von Sir Rufo die Parameter der Funktion mit const übergeben werden. Muss das allgemein so sein?

Zitat von uups:

Es hat mich auch interessiert, wie ich einem TTask meine Parameter übergeben kann. Dabei bin ich auf diesen Post gestossen, verstehe aber nicht ganz, wieso im Beispiel von Sir Rufo die Parameter der Funktion mit const übergeben werden. Muss das allgemein so sein?

Wenn ich mich irre steinigt mich aber ich habe irgendwo mal gelesen, dass das Übergeben von Objekten mit const in der Funktion selber dann nur ein Zeiger auf das Object ist und bei Variablen wird wohl eine Kopie der Variablen erstellt.

Wenn es wirklich eine Kopie ist, das mit dem Thread ja kein Problem mehr denn die ursprüngliche Variable wird nicht angefasst.