¿Qué modelo de memoria se implementa en .NET Core?

La especificación ECMA CLI define un modelo de memoria débil. Esto permite reordenar el orden de ejecución del comando (que es útil para el rendimiento). Pero escribir código de bajo nivel para tal modelo es muy difícil.

Y lo más importante: las arquitecturas de procesador X86 / AMD64 tienen un modelo de memoria más estricto (fuerte). Como resultado, Microsoft implementó un modelo de memoria más fuerte en su implementación CLR que lo descrito en la especificación.

¿Ha cambiado el modelo de memoria en .NET Core? Potencialmente, este marco puede ejecutarse en arquitecturas con un modelo de memoria más débil que X86 / AMD64.

Además, .NET Core incorpora Mono y otros. Y hasta donde yo sé, el modelo de memoria Mono es más débil, corresponde a ECMA.

En este artículo Introducción a .NET 5 escrito:

Amplíe las capacidades de .NET tomando lo mejor de .NET Core, .NET Framework, Xamarin y Mono.

Así que creo que si no ahora, en el futuro estos tiempos de ejecución se fusionarán en un solo todo.
A continuación en el artículo está escrito:

Estamos en el proceso de hacer reemplazos directos CoreCLR y Mono entre sí. Lo haremos tan simple como un cambio de compilación para elegir entre las diferentes opciones de tiempo de ejecución.

Si entiendo correctamente, habrá dos (o más) tiempos de ejecución. Y probablemente todos tendrán su propio modelo de memoria.

De qué estamos hablando: Modelo de memoria .

El modelo de memoria es específico para el tiempo de ejecución, por lo que su pregunta es, de hecho, "¿hay alguna diferencia en los modelos de memoria de CLR, CoreCLR y MonoRuntime".

Después de investigar un poco, la pregunta es realmente difícil de responder. Existe la especificación ECMA que ha mencionado, que le brinda las mínimas garantías que todas las implementaciones deben proporcionar. Hay una descripción muy bonita y concisa en el blog de Joe Duffy para CLR 2.0. Luego, para .NET Framework, hay un artículo de dos partes que habla sobre el modelo CLR en probablemente más detalles de lo que es saludable saber. Incluso hay un documento escrito sobre eso.

Para MonoRuntime, he encontrado este documento que habla sobre atómica y en realidad describe la forma en que Mono implementa esto, aunque el nivel de detalle es bastante bajo.

Encontrar detalles de CoreCLR es aún más complicado. Hay algunos puntos clave resaltados en este hilo de GitHub dotnet / coreclr y una discusión sobre lecturas / escrituras volátiles en este .

La forma más sencilla de responder es: sí, ha cambiado, en función de los recursos anteriores.

Sin embargo, hay una segunda forma de responder a su pregunta y es simplemente negar su premisa: parece suponer que el modelo de memoria cambió en el sentido de que algunas personas inteligentes se sentaron, reescribieron la especificación ECMA CLI y la incorporaron al CoreCLR especificaciones del modelo de memoria y ese es el nuevo modelo de memoria. Ese no es el caso. Las personas inteligentes mencionadas se sentaron y, en el transcurso de muchos meses, refinaron el diseño para que fuera confiable, rápido, sensiblemente fácil de implementar y no violara las garantías mínimas de la especificación. Citando del blog vinculado de Joe Duffy:

Hemos construido nuestro modelo durante años de trabajo informal y diseño por ejemplo (...) esto puede cambiar de una implementación a la siguiente.

La especificación informal de ECMA es, desafortunadamente, tan formal como la que tenemos por ahora. No hay una descripción formal de los cambios entre la especificación ECMA y la implementación de CLR, ni tampoco hay una descripción formal de los cambios entre CLR y CoreCLR. Y, lo que es más importante, las diferencias específicas de implementación entre ECMA CLI y CLR / CoreCLR son solo eso, específicas de implementación, y no se debe confiar en ellas . La única fuente 100% confiable de cómo se implementa el modelo de memoria .NET Core es el código fuente. Y eso obviamente cambia con cada confirmación, cada lanzamiento, y no hay garantía de que el equipo no arroje todo el jitter por la ventana y lo reescriba para que .NET 5 sea exactamente igual a la especificación ECMA (aunque es muy poco probable que sea )