Спецификация ECMA CLI определяет слабую модель памяти. Это позволяет изменить порядок выполнения команд (что полезно для производительности). Но написание низкоуровневого кода для такой модели очень сложно.
И самое главное - архитектуры процессоров X86 / AMD64 имеют более строгую (сильную) модель памяти. В результате Microsoft реализовала более сильную модель памяти в своей реализации CLR, чем описано в спецификации.
Изменилась ли модель памяти в .NET Core? Потенциально эта платформа может работать на архитектурах с более слабой моделью памяти, чем X86 / AMD64.
Кроме того, .NET Core включает в себя Mono и другие. И, насколько мне известно, модель памяти Mono слабее, соответствует ECMA.
В этой статье Представляем .NET 5 написано:
Расширьте возможности .NET, взяв лучшее из .NET Core, .NET Framework, Xamarin и Mono.
Поэтому я думаю, что если не сейчас, то в будущем эти временные рамки объединятся в одно целое.
Ниже в статье написано:
Мы находимся в процессе замены CoreCLR и Mono друг на друга. Мы сделаем так же просто, как переключатель сборки, чтобы выбирать между различными вариантами выполнения.
Если я правильно понимаю, будет два (или более) времени выполнения. И, вероятно, у каждого будет своя модель памяти.
О чем мы говорим: модель памяти .
Ответы:
Модель памяти зависит от времени выполнения, поэтому ваш вопрос на самом деле «есть ли различия в моделях памяти CLR, CoreCLR и MonoRuntime».
Немного изучив вопрос, на него очень трудно ответить. Существует спецификация ECMA , что вы упомянули, что дает вам самые минимальные гарантии , что все реализации должны обеспечить. В блоге Джо Даффи для CLR 2.0 очень хорошее и краткое описание . Кроме того, для .NET Framework есть статья из двух частей, в которой рассказывается о модели CLR, вероятно, более подробно, чем полезно знать. Там даже бумаги написано на этом.
Для MonoRuntime я нашел этот документ, который говорит об атомарности и фактически описывает, как Mono реализует это, хотя уровень детализации довольно низок.
Найти детали CoreCLR еще сложнее. Есть несколько ключевых точек выделены в этом Dotnet / CoreCLR GitHub нити и обсуждение летучего чтения / записи в этом один .
Самый простой способ ответить на этот вопрос - да, он изменился, основываясь на вышеупомянутых ресурсах.
Тем не менее, есть второй способ ответить на ваш вопрос, а именно просто опровергнуть его предпосылку - кажется, предполагается, что модель памяти изменилась в том смысле, что некоторые умные люди сели, переписали спецификацию ECMA CLI, превратили ее в CoreCLR спецификация модели памяти, и это новая модель памяти. Это не относится к делу. Упомянутые умные люди сели и в течение многих месяцев дорабатывали конструкцию, чтобы она была надежной, быстрой, разумно простой в реализации и не нарушала минимальных гарантий спецификации. Ссылаясь на связанный блог Джо Даффи:
Неформальная спецификация ECMA, к сожалению, так же формальна, как и сейчас. Нет формального описания изменений между спецификацией ECMA и реализацией CLR, равно как нет формального описания изменений между CLR и CoreCLR. И, что более важно, специфичные для реализации различия между CLI ECMA и CLR / CoreCLR заключаются только в том, что они специфичны для реализации, и на них нельзя полагаться . Единственным 100% надежным источником реализации модели памяти .NET Core является исходный код. И это, очевидно, меняется с каждым коммитом, каждым выпуском, и нет никакой гарантии, что команда не выбросит весь джиттер в окно и не перепишет его для .NET 5, чтобы он был точно таким же, как спецификации ECMA (как бы это ни было невероятно ).
источник