¿Por qué los modificadores de lectura y volátiles son mutuamente excluyentes?

Question

Tengo una variable de tipo de referencia que es readonly, porque la referencia nunca cambia, solo sus propiedades. Cuando traté de agregar el modificador volatile, el compilado me advirtió que no permitiría que los dos modificadores se aplicaran a la misma variable. Pero creo que necesito que sea volátil porque no quiero tener problemas de almacenamiento en caché al leer sus propiedades. ¿Me estoy perdiendo algo? ¿O el compilador está equivocado?

Actualización Como dijo Martin en uno de los comentarios a continuación: Los modificadores de solo lectura y volátiles se aplican solo a la referencia, y no a las propiedades del objeto, en el caso de los objetos de tipo referencia. Eso es lo que me faltaba, entonces el compilador tiene razón.

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

Answer 1

Ni los modificadores readonly ni volatile son penetrantes. Se aplican a la referencia en sí, no a las propiedades del objeto.

La palabra clave readonly afirma y hace cumplir que una variable no se 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 puede cambiarse por varios hilos. Esto evita que el compilador use optimizaciones (como leer el valor de la variable en un registro y usar ese valor en varias instrucciones) que podrían causar problemas con el acceso concurrente. Nuevamente, esto solo afecta el pequeño trozo de memoria donde se almacena la referencia.

Aplicado de esta manera, puede ver que son realmente mutuamente excluyentes. Si algo es de solo lectura (solo se puede escribir una vez, en la inicialización o construcción), entonces tampoco puede ser volátil (se puede escribir en cualquier momento mediante varios subprocesos).

---

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 a método, y es una optimización bastante pesada (desde el punto de vista del compilador) almacenar en caché su valor y omitir llamar de nuevo. No creo que sea algo de lo que deba preocuparse demasiado.

Answer 2

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

Answer 3

Aunque la referencia en sí misma podría ser segura para subprocesos, sus propiedades podrían no ser así. Piense en lo que sucedería si dos subprocesos intentaran iterar simultáneamente a través de una lista que contiene dentro de su objeto de referencia.