Warum schreibgeschützte und flüchtige Modifikatoren sich gegenseitig ausschließen?

Question

Ich habe eine Referenz-Typ-Variable, die readonly ist, weil die Referenz nie ändern, nur seine Eigenschaften. Als ich versuchte, den Modifikator volatile hinzuzufügen, warnte mich der kompilierte, dass es nicht beide Modifikatoren auf die gleiche Variable anwenden lassen würde. Aber ich denke, ich brauche es, um flüchtig zu sein, weil ich keine Cache-Probleme haben will, wenn ich seine Eigenschaften lese. Fehle ich etwas? Oder ist der Compiler falsch?

Aktualisierung Wie Martin in einem der folgenden Kommentare erklärte: Sowohl readonly als auch volatile Modifier gelten nur für die Referenz und nicht für die Eigenschaften des Objekts im Falle von Objekten vom Referenztyp. Das habe ich vermisst, also hat der Compiler Recht.

class C 
{ 
    readonly volatile string s; // error CS0678: 'C.s': a field cannot be both volatile and readonly 
} 

Answer 1

Weder die readonly noch volatile Modifikatoren sind penetrativ. Sie beziehen sich auf die Referenz selbst, nicht auf die Eigenschaften des Objekts.

Das Schlüsselwort readonly bestätigt und erzwingt, dass eine Variable nach der Initialisierung nicht geändert werden kann. Die Variable ist der kleine Teil des Speichers, in dem die Referenz gespeichert ist.

Das Schlüsselwort volatile teilt dem Compiler mit, dass der Inhalt einer Variablen möglicherweise von mehreren Threads geändert wird. Dies verhindert, dass der Compiler Optimierungen (z. B. das Lesen des Werts der Variablen in ein Register und die Verwendung dieses Werts über mehrere Anweisungen) verwendet, die Probleme beim gleichzeitigen Zugriff verursachen könnten. Dies betrifft wiederum nur den kleinen Teil des Speichers, in dem die Referenz gespeichert ist.

Auf diese Weise können Sie sehen, dass sie sich gegenseitig ausschließen. Wenn etwas nur gelesen wird (kann nur einmal geschrieben werden, bei der Initialisierung oder Konstruktion), dann kann es auch nicht flüchtig sein (kann jederzeit von mehreren Threads beschrieben werden).

---

Wie für Ihre Besorgnis über Caching-Probleme, IIRC gibt es ziemlich strenge Regeln über, wenn der Compiler das Ergebnis einer Eigenschaft Aufruf cachen kann. Denken Sie daran, dass es ein Methodenaufruf ist, und es ist eine ziemlich schwere Optimierung (vom Standpunkt des Compilers), seinen Wert zwischenzuspeichern und überspringen, es wieder aufzurufen. Ich denke nicht, dass es etwas ist, worüber du dich zu sehr kümmern musst.

Answer 2

Ein schreibgeschütztes Feld kann nur geschrieben werden, wenn das Objekt zuerst konstruiert wird. Daher wird auf der CPU kein Caching-Problem auftreten, da das Feld unveränderbar ist und sich nicht ändern kann.

Answer 3

Während die Referenz selbst Thread-sicher sein kann, sind ihre Eigenschaften möglicherweise nicht. Denken Sie darüber nach, was passieren würde, wenn zwei Threads gleichzeitig versuchen würden, eine innerhalb Ihres Referenzobjekts zu durchlaufen.