Яка модель пам'яті реалізована в .NET Core?

Специфікація 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 висвітлено декілька ключових моментів, а також дискусія про нестабільне читання / запис у цій .

Найпростіший спосіб відповісти - так, він змінився, виходячи з вищезазначених ресурсів.

Однак є другий спосіб відповісти на ваше запитання, а це просто заперечувати його передумови - здається, припускають, що модель пам'яті змінилася в тому сенсі, що деякі розумні люди сіли, переписали специфікацію CLI ECMA, зробивши це в CoreCLR специфікація моделі пам'яті і ось ця нова модель пам'яті. Це не так. Згадані розумні люди сіли і впродовж багатьох місяців удосконалювали дизайн надійним, швидким, розумно простим у виконанні та не порушуючи мінімальні гарантії специфікації. Посилаючись на пов'язаний блог Джо Даффі:

Ми побудували нашу модель протягом багатьох років неформальної роботи та дизайну за прикладом (...). Це вдається змінитись від однієї реалізації до іншої.

Неофіційна специфікація ECMA, на жаль, настільки ж формальна, як і зараз. Не існує офіційного опису змін між специфікацією ECMA та впровадженням CLR, а також немає офіційного опису змін між CLR та CoreCLR. І, що ще важливіше, специфічні відмінності у впровадженні між CLI ECMA та CLR / CoreCLR є якраз такими - конкретні впровадження - і на них не слід покладатися . Єдиним 100% надійним джерелом того, як реалізована модель пам'яті .NET Core, є вихідний код. І це очевидно змінюється з кожним комітетом, кожним випуском, і немає гарантії, що команда не викине весь тремтіння у вікно і перепише його для .NET 5, щоб він був точно таким же, як і специфікація ECMA (однак це дивно малоймовірно, що це ).