C# - ¿Realmente se necesita "volátil" como palabra clave?

Question

A medida que leo más y más profundamente en el significado de la palabra clave volatile, sigo diciéndome a mí mismo "esto es camino a implementación, esto no debería ser parte de un lenguaje de programación de alto nivel".
Quiero decir, el hecho de que las CPU almacenen en caché los datos debería ser interesante para el compilador JIT, no para el programador C#.

Una alternativa considerable podría ser un atributo (por ejemplo, VolatileAttribute).

¿Qué opinas?

Answer 1

IIIRC, en C++ volátil se refería principalmente a E/S mapeadas en memoria en lugar de caché. Si lees el mismo puerto dos veces, obtienes respuestas diferentes. Aún así, estoy de acuerdo con su evaluación de que esto se expresa más claramente en C# como un atributo.

Por otro lado, la mayoría de los usos reales de volátiles en C# pueden entenderse mejor como bloqueo de roscas de todos modos, por lo que la elección de volátiles puede ser un poco desafortunado.

Editar: Sólo para añadir: dos enlaces para mostrar que en C/C++ `volátil es explicitlynot para multihilo.

Answer 2

Usar un atributo sería aceptable, si hubiera sido al revés, es decir, el compilador supondría que todos los valores variables son volátiles, a menos que se marque explícitamente con un atributo que indique que es seguro. Eso sería increíblemente disuasivo para el rendimiento.

Por lo tanto, se supone que, dado que cambiar el valor de una variable fuera de la vista del compilador es una aberración, el compilador asumiría que no está ocurriendo.

Sin embargo, que podría suceder en un programa por lo que el lenguaje en sí debe tener una manera de mostrar eso.

Además, parece confundido acerca de "detalles de implementación". El término se refiere a cosas que hace el compilador a sus espaldas. Este no es el caso aquí. Su código está modificando un valor fuera de la vista del compilador. Como está en su código, siempre será cierto. Por lo tanto, el idioma debe poder indicar eso.

Answer 3

Creo que tiene un seguimiento lateral. Todo el material técnico sobre el almacenamiento en caché, etc., es parte de un intento de explicarlo en términos de bajo nivel. La descripción funcional de volátil sería "Podría ser compartido". Dado que por defecto nada se puede compartir entre hilos, esto no es del todo extraño. Y creo que es lo suficientemente fundamental como para garantizar una palabra clave sobre un atributo, pero supongo que fue en gran medida influenciado por decisiones históricas (C++)

Una forma de reemplazar/optimizar es con llamadas VolatileRead() y VolatileWrite(). Pero eso es aún más 'implementación'.

Answer 4

Bueno, ciertamente estoy de acuerdo, es bastante horrible que tal detalle de implementación esté expuesto. Sin embargo, es exactamente el mismo tipo de detalle expuesto por la palabra clave . Todavía estamos muy lejos de que el generador de errores se elimine por completo de nuestro código.

Los chicos del hardware tienen mucho trabajo por hacer. La palabra clave volátil importa una gran cantidad de núcleos de CPU con un modelo de memoria débil.El mercado no ha sido amable con ellos, el Alpha y el Itanium no lo han hecho bien. No estoy muy seguro de por qué, pero sospecho que la dificultad de escribir código de hebra sólida para estos núcleos tiene mucho que ver con eso. Hacerlo mal es toda una pesadilla para depurar. La verbosidad en la documentación de MSDN Library para volátiles se aplica a este tipo de procesadores, de lo contrario es bastante inapropiado para núcleos x86/x64 y hace que suene que la palabra clave está haciendo mucho más de lo que realmente hace. Volátil simplemente evita que los valores variables se almacenen en registros de CPU en esos núcleos.

Desafortunadamente, volátil todavía importa en los núcleos x86 en muy circunstancias selectas. Todavía no he encontrado ninguna evidencia de que importe en núcleos x64. Por lo que puedo decir, y respaldado por el código fuente en SSCLI20, la instrucción Opcodes.Volatile es una opción no operativa para el jitter x64, sin cambiar ni el estado del compilador ni emitir ningún código de máquina. Eso se dirige de la manera correcta.

El consejo genérico es que donde quiera que esté considerando la volatilidad, usar el candado o una de las clases de sincronización debería ser su primera consideración. Evitar que intenten optimizar su código es una micro-optimización, derrotada por la cantidad de sueño que perderá cuando su programa muestre problemas de carrera de subprocesos.

Answer 5

volatile en C# emite las barreras correctas, o vallas, que le importarían al programador que realiza el trabajo de múltiples hilos. Tenga en cuenta que el compilador, el tiempo de ejecución y el procesador pueden reordenar lecturas/escrituras hasta cierto punto (cada una tiene sus propias reglas). Aunque CLR 2.0 tiene un modelo de memoria más sólido que lo que especifica CLI ECMA, el modelo de memoria CLR aún no es el modelo de memoria más estricto, por lo que necesita volatile en C#.

Como atributo, no creo que pueda usar atributos dentro de un cuerpo de método, por lo que la palabra clave es necesaria.