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?

Wenn ein anderer Thread TapDataReceiverQueue.AddToQueue aufruft musst Du natürlich im Thread
das:

markieren

Delphi-Quellcode:

        try
          if Assigned(FQueue.Items[0]) then
          try
            QueueItem := TapDataReceiverQueueItem(FQueue.Items[0]);
            TapDataReceiver.Create(false, QueueItem.ClientData, QueueItem.Target, QueueItem.Priority);
          finally
            DeleteFromQueue(0);
          end;

absichern. Allerdings ACHTUNG bei Deinem eigenartigen Konstrukt. Da DeleteFromQueue() eine Prozedur von TapDataReceiverQueue ist UND Du dort schon die CriticalSection benutzt darfst Du diese nicht noch mal absichern. Ansonsten kann ein DEADLOCK entstehen. Also besser alle Methoden in TapDataReceiverQueue integrieren und mit Criticalsection absichern. Dann nie direkt auf die Liste gehen. So kannn nichts passieren.

Ergänzung: Das TapDataReceiverQueue.Count natürlich auch.

Zitat von taveuni:

Allerdings ACHTUNG bei Deinem eigenartigen Konstrukt. Da DeleteFromQueue() eine Prozedur von TapDataReceiverQueue ist UND Du dort schon die CriticalSection benutzt darfst Du diese nicht noch mal absichern. Ansonsten kann ein DEADLOCK entstehen. Also besser alle Methoden in TapDataReceiverQueue integrieren und mit Criticalsection absichern. Dann nie direkt auf die Liste gehen. So kannn nichts passieren.

Das habe ich jetzt nicht ganz verstanden. DeleteFromQueue() wird nur aus dem vom Thread selbst aufgerufen. Public sind nur AddToQueue() und Count() . In beiden sind die Zugriffe auf die TObjectList geschützt (für Count nachträglich). Andere Methoden gibt es nicht. Was ist gemeint mit "alle Methoden in TapDataReceiverQueue integrieren und mit Criticalsection absichern"?

markieren

Delphi-Quellcode:

        try
          if Assigned(FQueue.Items[0]) then // --> hier ist ein direkter Zugriff auf die "interne" Liste ohne Absicherung
          try
            QueueItem := TapDataReceiverQueueItem(FQueue.Items[0]); // hier ebenfalls
            TapDataReceiver.Create(false, QueueItem.ClientData, QueueItem.Target, QueueItem.Priority); // was ist eigentlich das hier?
          finally
            DeleteFromQueue(0); // hier ist der Zugriff über eine Methode der Klasse mit Absicherung
          end;

Das bedeutet Du mischst Zugriffe auf die Lokale Liste der Klasse (ohne Absicherung) mit Methoden der Klasse (inkl. Absicherung).
Meiner Meinung nach solltest Du die Klasse TapDataReceiverQueue so bauen dass Du aus dem Thread alles mit Klassenmethoden machen kannst (besser MUSST). Zum Beispiel eine Methode Pop um die Objekte zu holen. In der Klasse sicherst Du alles mit der CriticalSection ab. Somit muss sich kein Aufrufer der Methoden um etwas kümmern. Egal aus welchem Thread. Dafür würde sich übrigens die Generische TQueue ev. besser eignen als die TObjectlist.

Hmm..

Also:

Generell MUSS jeder Zugriff von verschiedenen Threads auf Variablen gekapselt werden.

Dabei ist es egal ob auf die Variable von externen Threads oder vom eigenen Thread darauf zugegriffen wird.
Es sind alle konkurierende Threads.

Somit müssen 'Add' 'Count' 'Delete' 'Extract' 'READ' und alle eventuell weiteren Zugriffe auf deine Liste gekapselt werden!

Heißt kapseln, dass CriticalSection Enter und Leave bzw TThread.Queue() reicht?