Когда запись / чтение влияет на основную память?

Volatile и Interlocked уже упоминались, вы просили примитивы, одно дополнение к списку - использовать Thread.MemoryBarrier() перед записью или чтением. Это гарантирует отсутствие переупорядочения операций чтения и записи в память.

Это делает "вручную" то, что lock, Interlocked и volatile могут делать автоматически большую часть времени. Вы можете использовать это как полную замену любому другому методу, но это, пожалуй, самый сложный путь, и поэтому MSDN говорит:

«Трудно создавать правильные многопоточные программы с использованием MemoryBarrier. Для большинства целей оператор блокировки C #, оператор SyncLock Visual Basic и методы класса Monitor предоставляют более простые и менее подверженные ошибкам способы синхронизации обращений к памяти. . Мы рекомендуем использовать их вместо MemoryBarrier. "

Как использовать MemoryBarrier

Прекрасным примером являются реализации VolatileRead и VolatileWrite, которые внутри используют MemoryBarrier. Основное практическое правило, которому нужно следовать: когда вы читаете переменную, устанавливайте барьер памяти после чтения. Когда вы записываете значение, барьер памяти должен стоять до записи.

Если вы сомневаетесь, что это менее эффективно, чем lock, примите во внимание, что блокировка - это не что иное, как «полное ограждение», поскольку она устанавливает барьер памяти до и после блока кода (игнорируя на мгновение Monitor). Этот принцип хорошо объяснен в этой отличной исчерпывающей статье о потоках, блокировках, энергозависимости и барьерах памяти от Альбахари.

От отражателя:

public static void VolatileWrite(ref byte address, byte value)
{
    MemoryBarrier();
    address = value;
}

public static byte VolatileRead(ref byte address)
{
    byte num = address;
    MemoryBarrier();
    return num;
}

Если вы хотите, чтобы он был написан быстро и по порядку, пометьте его как _ 1_ или (с большей болью) используйте _ 2_ / _3 _ (вариант не очень привлекательный, и его легко пропустить, что делает его бесполезным).

volatile int m_foo;

В противном случае у вас практически нет никаких гарантий (как только вы говорите в нескольких потоках).

Вы также можете посмотреть на блокировку (Monitor) или Interlocked, что даст тот же эффект до тех пор, пока тот же подход используется для любого доступа (т. е. все _ 7_ или все Interlocked и т. д.).

Пока вы не используете синхронизацию, у вас нет гарантии, что поток, работающий на одном процессоре, увидит изменения, сделанные другим потоком, выполняющимся на другом процессоре. Это потому, что значение может быть кэшировано в кешах ЦП или в регистре ЦП.

Поэтому вам нужно либо пометить переменную как изменчивую. Это создаст реальность «Произойдет до» между чтением и записью.

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

Если у вас есть несколько процессов или несколько потоков, и синхронизация является проблемой, вы должны делать это явно, есть много способов сделать это в зависимости от варианта использования.

Для однопоточной программы не беспокойтесь, компилятор сделает то, что должен, а чтение будет иметь доступ к тому, что было написано.