Чтение int, которое обновляется Interlocked в других потоках

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

int localNumberOfUpdates = Interlocked.CompareExchange(ref numberOfUpdates, 0, 0);

Дам вам именно то, что вы ищете. Как говорили другие, заблокированные операции атомарны. Таким образом, Interlocked.CompareExchange всегда будет возвращать самое последнее значение. Я все время использую это для доступа к простым общим данным, таким как счетчики.

Я не так хорошо знаком с Thread.VolatileRead, но подозреваю, что он также вернет самое последнее значение. Я бы придерживался взаимосвязанных методов, хотя бы ради последовательности.

Дополнительная информация:

Я бы рекомендовал взглянуть на ответ Джона Скита, чтобы узнать, почему вы можете уклоняться от Thread.VolatileRead (): Реализация Thread.VolatileRead

Эрик Липперт обсуждает волатильность и гарантии, предоставляемые моделью памяти C #, в своем блоге на http://blogs.msdn.com/b/ericlippert/archive/2011/06/16/atomicity-volatility-and-неизменяемость-разные-часть-три.aspx. Прямо из уст лошадей: «Я не пытаюсь писать какой-либо код с низким уровнем блокировки, за исключением самых тривиальных применений операций Interlocked. Я оставляю использование слова« volatile »для настоящих экспертов».

И я согласен с точкой зрения Ганса о том, что значение всегда будет устаревшим, по крайней мере, на несколько нс, но если у вас есть случай использования, в котором это неприемлемо, оно, вероятно, не очень хорошо подходит для языка со сборкой мусора, такого как C # или нереального - время ОС. У Джо Даффи есть хорошая статья о своевременности взаимосвязанных методов здесь: http://joeduffyblog.com/2008/06/13/volatile-reads-and-writes-and-timeliness/

Thread.VolatileRead(numberOfUpdates) это то, что вы хотите. numberOfUpdates - это Int32, поэтому по умолчанию у вас уже есть атомарность, а Thread.VolatileRead гарантирует, что волатильность будет решена.

Если numberOfUpdates определен как volatile int numberOfUpdates;, вам не нужно этого делать, поскольку все его чтения уже будут временными.

Кажется, есть путаница в отношении того, что Interlocked.CompareExchange более уместно. Рассмотрим следующие два отрывка из документации.

Из документации Thread.VolatileRead:

Считывает значение поля. Это значение является последним, записанным любым процессором компьютера, независимо от количества процессоров или состояния кеш-памяти процессора.

Из документации Interlocked.CompareExchange:

Сравнивает два 32-битных целых числа со знаком на равенство и, если они равны, заменяет одно из значений.

С точки зрения заявленного поведения этих методов, Thread.VolatileRead явно более уместен. Вы не хотите сравнивать numberOfUpdates с другим значением и не хотите заменять его значение. Вы хотите прочитать его значение.

В своем комментарии Лассе подытожил: возможно, вам лучше использовать простую блокировку. Когда другой код хочет обновить numberOfUpdates, он делает что-то вроде следующего.

lock (state)
{
    state.numberOfUpdates++;
}

Когда вы хотите это прочитать, вы делаете что-то вроде следующего.

int value;
lock (state)
{
    value = state.numberOfUpdates;
}

Это обеспечит ваши требования атомарности и изменчивости, не углубляясь в более неясные, относительно низкоуровневые примитивы многопоточности.

Будут ли работать оба (в смысле предоставления самого последнего возможного значения независимо от оптимизации, переупорядочения, кеширования и т. Д.)?

Нет, полученное вами значение всегда является устаревшим. Насколько устаревшим может быть значение, совершенно непредсказуемо. В подавляющем большинстве случаев он будет устаревшим на несколько наносекунд, плюс-минус, в зависимости от того, как быстро вы отреагируете на значение. Но разумной верхней границы нет:

• ваш поток может потерять процессор, когда он переключает другой поток на ядро. Типичные задержки составляют около 45 мсек без твердой верхней границы. Это не означает, что другой поток в вашем процессе также отключается, он может продолжать работать и изменять значение.
• как и любой код пользовательского режима, ваш код также подвержен ошибкам страниц. Возникает, когда процессору требуется оперативная память для другого процесса. На сильно загруженной машине, которая может и будет выгружать активный код. Как иногда бывает, например, с кодом драйвера мыши, когда курсор мыши остается замороженным.
• управляемые потоки подвержены почти случайным паузам при сборке мусора. Обычно это меньшая проблема, поскольку вполне вероятно, что другой поток, изменяющий значение, также будет приостановлен.

Что бы вы ни делали с ценностью, необходимо это учитывать. Излишне говорить, что, возможно, это очень и очень сложно. Практических примеров найти сложно. .NET Framework - это очень большой кусок закаленного в боях кода. Вы можете увидеть перекрестную ссылку на использование VolatileRead в Справочном источнике. Количество просмотров: 0.

Что ж, любое значение, которое вы прочитаете, всегда будет несколько устаревшим, как сказал Ганс Пассан. Вы можете контролировать только гарантию того, что другие общие значения согласуются с тем, которое вы только что прочитали, используя ограждения памяти в середине кода, считывая несколько общих значений без блокировок (т. Е. Находятся в той же степени "черствость")

Ограничения также могут препятствовать некоторым оптимизациям компилятора и переупорядочиванию, таким образом предотвращая неожиданное поведение в режиме выпуска на разных платформах.

Thread.VolatileRead вызовет создание полного забора памяти, так что никакие операции чтения или записи не могут быть переупорядочены вокруг вашего чтения int (в методе, который его читает). Очевидно, что если вы читаете только одно общее значение (и вы не читаете что-то еще, а порядок и последовательность их обоих важны), тогда это может показаться ненужным ...

Но я думаю, что он вам понадобится в любом случае, чтобы избежать некоторых оптимизаций компилятора или процессора, чтобы вы не получили более «устаревший», чем необходимо.

Макет Interlocked.CompareExchange будет делать то же самое, что и Thread.VolatileRead (полный забор и поведение, препятствующее оптимизации).

В структуре, используемой CancellationTokenSource http://referencesource.microsoft.com/#mscorlib/system/threading/CancellationTokenSource.cs#64.

//m_state uses the pattern "volatile int32 reads, with cmpxch writes" which is safe for updates and cannot suffer torn reads. 
private volatile int m_state;

public bool IsCancellationRequested
{
    get { return m_state >= NOTIFYING; } 
}

// ....
if (Interlocked.CompareExchange(ref m_state, NOTIFYING, NOT_CANCELED) == NOT_CANCELED) {
}
// ....

Ключевое слово volatile создает эффект «наполовину». (то есть: он блокирует операции чтения / записи от перемещения до чтения в него и блокирует операции чтения / записи от перемещения после записи в него).