Требуется ли защита памяти (.net x86 или x64) при разыменовании полей?

Question

В коде, как показано ниже, если Proc1 и Proc2 выполняются одновременно на разных процессорах, возможно ли, чтобы ThingVal2 получил значение, отличное от 5 (например, ноль)?

 
Class SimpleThing 
    Public X As Integer 
    Sub New(ByVal value As Integer) 
     X = value 
    End Sub 
End Class 
Class ConcurrencyTest 
    Dim Thing1 As New SimpleThing(5) 
    Dim Thing2 As New SimpleThing(0) 
    Dim ThingRef As SimpleThing = Thing1 
    Dim ThingVal1, ThingVal2 As Integer 
    Sub Proc1() 
     Thing2.X = 5 
     Threading.Thread.MemoryBarrier() 
     ThingRef = Thing2 
    End Sub 
    Sub Proc2() 
     ThingVal1 = Thing2.X 
     ThingVal2 = ThingRef.X 
    End Sub 
End Class 

Я знаю, что в слабой модели как IA64, существует реальная возможность того, что Proc2 может видеть, как ThingRef поменяв, но не видеть поле Х Thing2, как, сделав это. Существует ли такой риск для приложения .Net, работающего на x86 или x64? Если Proc1 создал новый экземпляр SimpleThing, установите его поле X равным 5, а затем установите ThingRef, чтобы указать на него, этого было бы достаточно, чтобы избежать опасности, или было бы возможно, что новая вещь может быть выделена в строке кэша, которая был разделен с чем-то другим, к которому обратился поток Proc2?

Общая парадигма с многопоточным кодом состоит в том, чтобы построить неизменяемый объект и установить изменяемую ссылку, чтобы указать на него (возможно, с помощью Interlocked.CompareExchange). Всегда ли безопасно под x86/x64 читать неизменный тип без учета потоковой передачи или может вызвать проблемы? Если последний, что является предпочтительным способом в vb.net, чтобы гарантировать надежное поведение?

Кроме того, есть ли способ указать, что код должен выполняться таким образом, чтобы такие проблемы не могли возникнуть (например, ограничение выполнения одного ядра на чем-то вроде IA64, который иначе не мог бы гарантировать правильную работу)?

Answer 1

ОК, вы задали много вопросов. Я постараюсь ответить на то, что знаю.

-1. Пример вашего кода:

CLR с 2.0 заказал магазины. Это означает, что ваш ThingVal всегда будет 5 на x86/x64. Наверняка. Я не пробовал его на реальном IA64, но он должен работать также и на IA64, потому что CLR должна обеспечивать упорядоченные записи на всех платформах и должна быть достаточной для вашего простого примера.

-2. ad IA64 vs x86/x64:

x86/x64 имеет другую семантику памяти, и на IA64 такого риска не существует. Единственная возможная проблема заключается в том, что вы на самом деле используете язык более высокого уровня, и если он использует оптимизирующий компилятор (например, C++), вы ничего не можете предсказать, не зная точно, как компилятор делает свою оптимизацию. Недокументировано: VB не выполняет никаких глобальных оптимизаций и т. Д., Поэтому ваш код должен быть безопасным.

-3. ad immutable:

Если вы действительно просто прочитали его, и это действительно неизменно, это безопасно.

-4. ad single core:

Вы можете установить сродство нити. Это стандартное свойство каждого потока и определяет, на каких процессорах может работать поток. (Настройка близости нити .net напрямую изменяет близость в операционной системе.) Но это заставляет вашу программу работать медленно.

Также вы можете переключиться на C# и использовать volatile ключевое слово. Это поможет вам легче жить, так как он вносит какие-либо изменения в изменчивую переменную, которую сразу видят все процессоры, и в свою очередь решит все возможные проблемы, которые вы здесь представили. К сожалению, VB не предоставляет это ключевое слово.