¿Por qué sólo lectura y modificadores volátiles son mutuamente excluyentes?

Question

Tengo una variable de tipo de referencia que es readonly, porque la referencia nunca cambian, sólo sus propiedades. Cuando traté de añadir el modificador volatile a que el compilado me advirtió que no iba a dejar que ambos modificadores se aplican a la misma variable. Pero creo que lo necesito para ser volátil porque no quieren tener problemas de almacenamiento en caché al leer sus propiedades. Me estoy perdiendo algo? O es el mal compilador?

Actualizar Como Martin afirma en uno de los comentarios a continuación: Tanto de sólo lectura y modificadores volátiles aplicará únicamente a la referencia, y no a las propiedades del objeto, en el caso de objetos de tipo de referencia. Eso es lo que me estaba perdiendo, por lo que el compilador es correcto.

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

Answer 1

Ni el readonly ni volatile modificadores son penetración. Se aplican a la propia referencia, no las propiedades del objeto.

La palabra clave readonly afirma-y hace cumplir-que a variables no puede cambiar después de la inicialización. La variable es el pequeño trozo de memoria donde se almacena la referencia.

La palabra clave volatile le dice al compilador que el contenido de una variable pueden ser modificados por varios subprocesos. Esto evita que el compilador de usar optimizaciones (como leer el valor de la variable en un registro y el uso de ese valor durante varias instrucciones) que podrían causar problemas con el acceso concurrente. De nuevo, esto sólo afecta a la pequeña cantidad de memoria donde se almacena la referencia.

Se aplica esta manera, se puede ver que son de hecho mutuamente excluyentes. Si algo es de sólo lectura (sólo se puede grabar una vez, en la inicialización o la construcción), entonces no puede también ser volátiles (se puede escribir en cualquier momento por múltiples hilos).

---

En cuanto a su preocupación por los problemas de almacenamiento en caché, IIRC, hay reglas muy estrictas sobre cuando el compilador puede almacenar en caché el resultado de una llamada propiedad. Tenga en cuenta que es una llamada de método, y es una optimización bastante pesado (de stand-punto del compilador) para almacenar en caché su valor y omita llamar de nuevo. No creo que es algo que tiene que preocuparse por excesivamente mucho.

Answer 2

Un campo de sólo lectura sólo se puede escribir cuando el objeto se construye primero. Por lo tanto no habrá ningún problema de almacenamiento en caché de la CPU porque el campo es inmutable y no puede cambiar.

Answer 3

Si bien la propia referencia podría ser thread-safe, sus propiedades no. Pensar en lo que sucedería si dos hilos trataron de repetir de forma simultánea a través de una lista que figura en el objeto de referencia.