Насколько я понимаю эти трюки, возможность полноценного полного барьера памяти больше важна для DNX, чем в стандартной инфраструктуре .Net: - DNX может работать на IA64 с более слабой моделью памяти, чем x86/x64. - Microsoft CLR использует более сильную модель памяти, чем спецификация ECMA.Возможности Thread.MemoryBarrier() и других возможностей памяти в DNX Core 5.0
Цитирование из ответа Why do I need a memory barrier?
Вы собираетесь иметь очень трудное время воспроизведения этой ошибки. Фактически, я бы сказал, что вы никогда не сможете воспроизвести его с помощью .NET Framework. Причина в том, что в реализации Microsoft используется сильная модель памяти для записи. Это означает, что записи обрабатываются так, как будто они нестабильны. У volatile write есть семантика блокировки-освобождения, что означает, что все предыдущие записи должны быть зафиксированы до текущей записи.
Однако спецификация ECMA имеет более слабую модель памяти. Поэтому теоретически возможно, что Mono или даже будущая версия .NET Framework могут начать демонстрировать поведение с ошибкой.
Однако ни MemoryBarrier, VolatileRead и VolatileWrite доступны на Thread класса.
Мои вопросы:
- Является ли это окончательный выбор?
- Что является лучшей альтернативой (при условии, что моя текущая база кода использует
MemoryBarrier), чтобы реализовать блокировку?
Не уверен, что все еще можно купить систему Itanium. Но я думаю, что у ARM есть слабая модель памяти, и ARM теперь поддерживаются .NET Micro по крайней мере. –