Thread.MemoryBarrier () и другие возможности ограничения памяти в DNX Core 5.0

Насколько я понимаю эти уловки, возможность создания полного барьера памяти с полным забором более важна в DNX, чем в стандартной платформе .Net: - DNX может работать на IA64, у которого модель памяти более слабая, чем x86 / x64 . - Microsoft CLR использует более сильную модель памяти, чем определено в спецификации ECMA.

Цитата из ответа Зачем мне нужен барьер памяти?

Вам будет очень трудно воспроизвести эту ошибку. Фактически, я бы даже сказал, что вы никогда не сможете воспроизвести его с помощью .NET Framework. Причина в том, что реализация Microsoft использует сильную модель памяти для записи. Это означает, что записи обрабатываются так, как если бы они были нестабильными. У изменчивой записи есть семантика освобождения блокировки, что означает, что все предыдущие записи должны быть зафиксированы до текущей записи.

Однако спецификация ECMA имеет более слабую модель памяти. Таким образом, теоретически возможно, что Mono или даже будущая версия .NET Framework могут начать демонстрировать ошибочное поведение.

Однако ни MemoryBarrier, VolatileRead и VolatileWrite недоступны для класса Thread.

Мои вопросы:

  • Это окончательный выбор?
  • Какая наилучшая альтернатива (при условии, что моя текущая кодовая база использует MemoryBarrier) для реализации безблокировочного материала?

multithreading .net c# memory-barriers dnx
person Spi    schedule 31.10.2015    source источник
comment
Не уверен, что еще можно купить систему Itanium. Но я думаю, что у ARM слабая модель памяти, а ARM теперь, по крайней мере, поддерживаются .NET Micro.   -  person Chris O    schedule 07.11.2015

Ответы (1)


arrow_upward
4
arrow_downward

Фактически метод Thread.MemoryBarrier() был перемещен в Interlocked.MemoryBarrier().

Этот Interlocked метод доступен в .Net 4.5 (и 4.6) и в DNXCORE50: с этого момента определенно следует использовать его.

Обратите внимание, что VolatileRead\Write недоступны.

person Spi    schedule 31.10.2015