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.

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?

Das const ist tatsächlich nicht zwingend erforderlich, sondern nur eine Performance-Optimierung (const und var werden intern [meistens] als Pointer umgesetzt, wie a.def korrekterweise angemerkt hat). Im Falle von String bewirkt es vor allem, dass die automatische Referenzzählung deaktiviert und grade KEINE lokale Kopie erzeugt wird.

Zitat von Zacherl:

Im Falle von String bewirkt es vor allem, dass die automatische Referenzzählung deaktiviert und grade KEINE lokale Kopie erzeugt wird.

Wird die Referenzzählung wirklich deaktiviert oder wird es der ARC nur mitgeteilt, dass die String-Variable noch woanders benötigt wird?

Zitat von uups:

Zitat von Zacherl:

Im Falle von String bewirkt es vor allem, dass die automatische Referenzzählung deaktiviert und grade KEINE lokale Kopie erzeugt wird.

Wird die Referenzzählung wirklich deaktiviert oder wird es der ARC nur mitgeteilt, dass die String-Variable noch woanders benötigt wird?

Ist eigentlich nur ein Interna. Konkret wird bei konstanten Strings der RefCount immer auf -1 gesetzt, um zu verhindern, dass der Speicher für den String ungewollt freigegeben wird. Die Online-Hilfe dokumentiert dieses Verhalten hier:

Zitat:

For string literals, the compiler generates a memory block with the same layout as a dynamically allocated string, but with a reference count of -1. String constants are treated the same way, the only difference from literals being that they are a pointer to a -1 reference counter block.
When a pointer to a string structure (source) is assigned to a string variable (destination), the reference counter dictates how this is done. Usually, the reference count is decreased for the destination and increased for the source, as both pointers, source and destination, will point to the same memory block after the assignment.
If the source reference count is -1 (string constant), a new structure is created with a reference count of 1. If the destination is not nil, the reference counter is decreased. If it reaches 0, the structure is deallocated from the memory. If the destination is nil, no additional actions are taken for it. The destination will then point to the new structure.

Im Grunde geht es bei const S: String weniger um den RefCounter ansich, sondern unnötige lokale Kopien und Speicheroperationen. Wenn man sich mal anschaut, wie eine leere Funktion mit String Parameter ohne const oder var aussieht:

markieren

Code:

00822538 55               push ebp
00822539 8BEC            mov ebp,esp
0082253B 51               push ecx
0082253C 8945FC          mov [ebp-$04],eax
0082253F 8B45FC          mov eax,[ebp-$04]
00822542 E82D79BEFF      call @UStrAddRef
00822547 33C0             xor eax,eax
00822549 55               push ebp
0082254A 686B258200       push $0082256b
0082254F 64FF30           push dword ptr fs:[eax]
00822552 648920           mov fs:[eax],esp
00822555 33C0             xor eax,eax
00822557 5A              pop edx
00822558 59               pop ecx
00822559 59               pop ecx
0082255A 648910           mov fs:[eax],edx
0082255D 6872258200       push $00822572
00822562 8D45FC          lea eax,[ebp-$04]
00822565 E82678BEFF      call @UStrClr
0082256A C3               ret
0082256B E9C86DBEFF      jmp @HandleFinally
00822570 EBF0             jmp $00822562
00822572 59               pop ecx
00822573 5D              pop ebp
00822574 C3               ret

Im Vergleich zu einer Funktion mit const bzw. var String-Parameter:

markieren

Code:

00822578 55               push ebp
00822579 8BEC            mov ebp,esp
0082257B 51               push ecx
0082257C 8945FC          mov [ebp-$04],eax
0082257F 59               pop ecx
00822580 5D              pop ebp
00822581 C3               ret

Hier sieht man ganz gut, dass man durch diese kleine Optimierung doch deutlich Overhead einspart.

Dass der Compiler so etwas nicht automatisch optimiert war mir immer schon ein Rätsel...

Zuerst möchte ich mich für die vielen hilfreichen Beiträge bedanken, habe wieder etwas dazu gelernt. Bevor ich nun die vielen nützlichen Vorschläge umsätze, möchte ich gerne zu meiner eigentlichen Frage zurückkehren: wäre mein geposteter Code so in Ordnung oder sollen die Zugriffe auf den Queue-Thread zusätzlich mit einer TCriticalSection abgesichert werden?