Zugriffe auf Objekt aus mehreren Threads - wie richrig synchronisieren?

[Zacherl]

Zitat:

Zitat von uups (Beitrag 1359702)

Zitat:

Zitat von Zacherl (Beitrag 1359699)

Schau dir mal

Delphi-Quellcode:

TThreadPool

an. Der ist genau für solche Zwecke gedacht. Du kannst dort einen

Delphi-Quellcode:

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:

Zitat von uups (Beitrag 1359702)

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.

[uups]

Zitat:

Zitat von Zacherl (Beitrag 1359725)

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.

[Klaus01]

Zitat:

Zitat von uups (Beitrag 1359705)

Zitat:

Zitat von Klaus01 (Beitrag 1359697)

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

Delphi-Quellcode:

AddToQueue()

oder

Delphi-Quellcode:

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

A propos Zugriffe.

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

[Klaus01]

Zitat:

Zitat von a.def (Beitrag 1359736)

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

[uups]

Zitat:

Zitat von a.def (Beitrag 1359736)

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

Delphi-Quellcode:

TMultipleReadExclusiveWriteSynchronizer

nicht erklären können.

[stahli]

Man muss alle gleichzeitigen Zugriffe absichern, die nicht atomar sind, sobald ein Prozess ggf. etwas schreibt.
Übrigens: auch ein

Delphi-Quellcode:

I := J

oder ein

Delphi-Quellcode:

Inc(I)

ist - auf Prozessorebene - nicht atomar.

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

[Zacherl]

Zitat:

Zitat von uups (Beitrag 1359730)

Zitat:

Zitat von Zacherl (Beitrag 1359725)

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.

[uups]

Zitat:

Zitat von Zacherl (Beitrag 1359741)

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:

Zitat von Zacherl (Beitrag 1359741)

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

Delphi-Quellcode:

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

Delphi-Quellcode:

const

übergeben werden. Muss das allgemein so sein?

[a.def]

Zitat:

Zitat von uups (Beitrag 1359743)

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

Delphi-Quellcode:

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.