Метод Interlocked.Exchange(Double, Double) не гарантирует одинаковое значение переменной в разных потоках?

@titan4ik · 20.03.2024, 13:45. **Показов** 2566. **Ответов** 48

Студворк — интернет-сервис помощи студентам

Метод Interlocked.Exchange(Double, Double) обеспечивает атомарность операции присвоения нового значения переменной типа Double.
То есть, InterlockedExchange гарантирует, что изменение переменной и возврат ее исходного значения не будут прерваны другими потоками.
Но есть ли гарантия, что данная переменная будет после этого иметь одно и то же значение в разных потоках, в том числе, исполняемых на разных процессорах? Похоже, что нет.
Но если нет, то тогда для обеспечения одинакового значения переменной нужно применять lock?
И тогда, если блокировать код присвоения с помощью lock, то тогда Interlocked.Exchange уже нет смысла использовать?
Правилен ли вывод, что Interlocked.Exchange имеет смысл применять в том случае, когда не нужно, чтобы значение переменной во всех потоках было одинаковым (самым последним)?
А преимущество Interlocked.Exchange по сравнению с блокировкой lock в том, что Interlocked.Exchange не тормозит потоки?

@OwenGlendower · 20.03.2024, 14:53

Сообщение от titan4ik

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

По моему это гарантируется если все операция изменения идут через класс Interlocked. Иначе требуется volatile или ручные memory barriers.

Сообщение от titan4ik

Но если нет, то тогда для обеспечения одинакового значения переменной нужно применять lock?

С каких пор lock начал давать такие гарантии?

Сообщение от titan4ik

И тогда, если блокировать код присвоения с помощью lock, то тогда Interlocked.Exchange уже нет смысла использовать?

Да (но - смотрим выше).

Сообщение от titan4ik

Правилен ли вывод, что Interlocked.Exchange имеет смысл применять в том случае, когда не нужно, чтобы значение переменной во всех потоках было одинаковым (самым последним)?

Нет. Interlocked.Exchange имеет смысл применять когда требуется выполнить атомарную операцию с минимальными накладными расходами.

Сообщение от titan4ik

А преимущество Interlocked.Exchange по сравнению с блокировкой lock в том, что Interlocked.Exchange не тормозит потоки?

Скорее меньше тормозит чем не тормозит вообще. Такие операции по определению имеют цену. Вопрос только в размере.

@IamRain · 20.03.2024, 15:13

Сообщение от titan4ik

Правилен ли вывод, что Interlocked.Exchange имеет смысл применять в том случае, когда не нужно, чтобы значение переменной во всех потоках было одинаковым (самым последним)?

Нет. Если есть требование к реализации потокобезопасного lock-free кода, то одним из вариантов может быть как раз Interlocked.Exchange. В официальных доках по методу есть наглядный пример.

@titan4ik · 20.03.2024, 15:18 **[ТС]**

Сообщение от OwenGlendower

С каких пор lock начал давать такие гарантии?

И в самом деле. с чего это я так решил)
lock тоже просто защищает некий операцию с неким общим ресурсом от вмешательства других потоков.

Сообщение от OwenGlendower

Нет. Interlocked.Exchange имеет смысл применять когда требуется выполнить атомарную операцию с минимальными накладными расходами.

Это понятно. Я имел ввиду идею о том, что, обеспечивая атомарность, Interlocked.Exchange не обеспечивает идентичности значений переменной в разных потоках. Но Вы полагаете, что обеспечивает, если все изменения идут через методы Interlocked:

Сообщение от OwenGlendower

По моему это гарантируется если все операция изменения идут через класс Interlocked. Иначе требуется volatile или ручные memory barriers.

Надо мне погуглить ещё)
Не нашел пока исчерпывающего и однозначного достоверного источника по этому вопросу.

@IamRain · 20.03.2024, 15:23

Сообщение от titan4ik

Я имел ввиду идею о том, что, обеспечивая атомарность, Interlocked.Exchange не обеспечивает идентичности значений переменной в разных потоках.

Вы имели ввиду кэши каждого ядра процессора? Если я правильно понял, то тут работа ведется работа как раз именно с шареной памятью (ведь все Interlocked-методы работают с ключевым словом ref). К тому же, все Interlocked-методы являются в каком-то смысле super-volatile, то есть запрещаются всякого рода reordering-оптимизации в обе стороны у всех методов этого класса.

@titan4ik · 20.03.2024, 15:26 **[ТС]**

Сообщение от IamRain

Если есть требование к реализации потокобезопасного lock-free кода, то одним из вариантов может быть как раз Interlocked.Exchange. В официальных доках по методу есть наглядный пример.

ОК.
Ну да. Пишут что "The following code example shows a thread-safe resource locking mechanism."
Это я, видать, не дочитал сразу

Сбивают с толка пространные рассуждения в интернете по этому поводу. Пишут так, что можно понять, что это не жёстко определено, а может быть и так и эдак в зависимости от внешнего окружения.

Добавлено через 1 минуту

Сообщение от IamRain

Вы имели ввиду кэши каждого ядра процессора?

Ну да, читал об этом.
ОК, я понял, что Interlocked-методы обеспечивают потокобезопасность без всяких оговорок. Спасибо!

@IamRain · 20.03.2024, 15:34

Сообщение от titan4ik

Сбивают с толка пространные рассуждения в интернете по этому поводу.

Еще сбивают с толку, что volatile-поля запрещается читать из кэша, я уже дважды слышал такое утверждение. Скорее всего оно верное, но смысл volatile-полей в запрете на reordering-оптимизацию, здравый смысл подсказывает что запрет на чтение из кэша - это предполагаемое поведение, и это предположение должно быть и ежу понятно. То есть акцент делается на совсем других вещах. Это как говорить, что значимые типы хранятся в стеке, а ссылочные - в куче. Немножко правда, но основное отличие - совершенно в другом.

@titan4ik · 20.03.2024, 15:40 **[ТС]**

Чтобы вбить последний гвоздь в...
Не будет глупостью такой код в котором некий кусок кода заблокирован с помощью lock, а внутри него некоторые отдельные операции защищены ещё и с помощью методов Interlocked?

@IamRain · 20.03.2024, 15:56

Сообщение от titan4ik

Не будет глупостью такой код

Скорее всего будет лишним, а глупостью - это кто как назовет.

Добавлено через 2 минуты
Лучше уж только Interlocked, без всяких lock-ов. Интуитивно кажется легче/быстрее. Если весь упор делать на perf, в моем понимании.

@titan4ik · 20.03.2024, 16:05 **[ТС]**

Сообщение от IamRain

Если весь упор делать на perf, в моем понимании.

perf - это что такое?

@IamRain · 20.03.2024, 16:12

Не по теме:

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

@titan4ik · 20.03.2024, 16:17 **[ТС]**

Не по теме:

ну да, буржуйские лучше, чем калька на русском

Добавлено через 2 минуты
Но как я понял, отличие Interlocked и всяких lock-ов не только в производительности. lock же не обеспечит того, чтобы во всех потоках переменная имела одно значение. Этот же вопрос главный был. Меня конкретно тип Double интересовал.

@Andrey-MSK · 20.03.2024, 16:21

Сообщение от titan4ik

lock же не обеспечит того, чтобы во всех потоках переменная имела одно значение.

Тут поможет DI. Пишете сервис, определяете как Singleton и храните в нём что нужно.

@IamRain · 20.03.2024, 16:26

Сообщение от titan4ik

ock же не обеспечит того, чтобы во всех потоках переменная имела одно значение. Этот же вопрос главный был.

Почему не обеспечит? - обеспечит. Просто это ванильный blocking-примитив из user-space, он быстрее всяких Mutex-ов и прочего, но он все же блокирующий. А блокирующий значит более медленный, и потенциально впустую расходующий потоки.
Если будет high contention (погнали по-полной!), то будут задержки со входом в критическую секцию и будет пустое расходование ресурсов, при spin-based примитивах будет уже быстрее, но будет много холостой работы процессора, и тут уже надо думать что использовать под конкретный сценарий.

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

@titan4ik · 20.03.2024, 16:30 **[ТС]**

Andrey-MSK, в рамках изначальной постановки вопроса (для Double, в частности) я понял, что можно и нужно использовать методы Interlocked.

Добавлено через 3 минуты

Сообщение от IamRain

Почему не обеспечит? - обеспечит.

у OwenGlendower, во втором сообщении в этой теме было высказывание, что не обеспечит, если я правильно это понял.

@IamRain · 20.03.2024, 16:44

Сообщение от titan4ik

у OwenGlendower, во втором сообщении в этой теме было высказывание, что не обеспечит, если я правильно это понял.

Это просто детали низкоуровневого кэша, у вас какие-то неправильные сомнения

- все примитивы синхронизации как раз были придуманы для того, чтобы обеспечить предсказуемое поведение чтения/записи шареных состояних в многопоточном окружении. Если следовать вашей логике, то раз у нас есть регистровый кэш, то ни один Semaphor/Mutex/Barrier/что-там еще/... нам не поможет, поэтому у нас лапки и это все бесполезно.

Насколько я понимаю, c Interlocked и volatile можно работать.
Вообще рекомендую почитать статейку, старую, но все же это база - C# Memory Model by Igor Istrovsky.

@titan4ik · 20.03.2024, 20:30 **[ТС]**

Сообщение от IamRain

Вообще рекомендую почитать статейку, старую, но все же это база - C# Memory Model by Igor Istrovsky.

Там ещё вторая часть есть - https://learn.microsoft.com/en... ice-part-2

@titan4ik · 21.03.2024, 13:48 **[ТС]**

Не по теме:

Прочитал первую и просмотрел вторую. Мда.
В современном мире, в котором всем управляют менеджеры, которые смотрят в монитор и отвечают вам что-то вроде: "А у меня в компьютере...", всё возможно. Любой, самый нелепый исход. Однажды можно проснуться и узнать, что "в компьютере написано", что вас уже нет. Или - что никогда не было. А как там системы предупреждения о ракетном нападении и автоматического ответа на него? Мда. Ж/Д стрелки и т.п.

В связи с многопоточностью и т.п. появилось конкретное соображение относительно прав собственности и их смены.
Сейчас отменены "Свидетельства о праве собственности". есть только записи в реестре (в компутере). Можно получить выписку из реестра (компутера). При сделках с недвижимостью требуют "свежую" выписку. Но какой бы свежей она ни была, это не гарантирует того, что после получения этой выписки, недвижимость уже была продана.
Предлагаю ввести блокирующую выписку!
То есть, перед сделкой продавец должен получить выписку, которая на определенный срок (например, на 10 дней) блокирует все сделки с этой недвижимостью за исключением продажи данному конкретному покупателю, о чем и будет указано в этой выписке.

@nicolas2008 · 27.03.2024, 02:08

Читал по диагонали, не знаю к чему таки пришли, но рассуждения что Interlocked отменяет необходимость использования volatile по моему скромному мнению неверно.
Для вызова самого Interlocked.Exchange volatile не нужен, потому как все Interlocked методы и так оборудованы необходимым механизмом обеспечивающим работу с наиболее актуальной версией значения переменной, если можно так выразиться)
Для других же мест где производится просто чтение переменной и где необходима гарантия получения наиболее актуального значения, нужен один из приемов который под капотом так или иначе использует Thread.MemoryBarrier().
А именно

1. Обозначение поля как volatile

C#
1
private volatile int HotVar;

Плюсы - никто не забудет использовать нужный прием.
Минусы - все попытки чтения будут включать вызов Thread.MemoryBarrier(), а это доп издержки которые не всегда нужны.

2. Оборачивание чтения в конструкцию lock

C#
1
2
3
4
5
int curVal;
lock(myLock) 
{
   curVal = HotVar;
}

Плюсы - метод рабочий.
Минусы - это как из пушки по воробьям. lock вызывает метод ядра, а это очень дорогая операция (тысячи тактов если не ошибаюсь)

3. Доступ через Volatile.Read

C#
1
var curVal = Volatile.Read(ref HotVar);

Плюсы - полный контроль над происходящим, понятно что происходит.
Минусы - нет.

4. Собственно вызов Thread.MemoryBarrier().

C#
1
2
Thread.MemoryBarrier();
var curVal = HotVar;

Плюсы - полный контроль над происходящим.
Минусы - может ввести в ступор большинство погромистов, повышен риск что непонятный код будет удален после короткого тестирования и подтверждения что "все и так работает нормально".

@titan4ik · 27.03.2024, 09:10 **[ТС]**

nicolas2008,
то есть, если расположить способы в таком порядке, что сначала лучшие, то так (?):
№3 - минусов нет
№1 - Минусы - все попытки чтения будут включать вызов Thread.MemoryBarrier(), а это доп издержки которые не всегда нужны.
№4 - Thread.MemoryBarrier(), а это доп издержки которые не всегда нужны и может ввести в ступор большинство погромистов, повышен риск что непонятный код будет удален после короткого тестирования и подтверждения что "все и так работает нормально".
№2 - Минусы - это как из пушки по воробьям. lock вызывает метод ядра, а это очень дорогая операция (тысячи тактов если не ошибаюсь)
---
Тогда лучший рецепт - Interlocked для изменения плюс Volatile.Read для чтения?

Новые блоги и статьи Все статьи Все блоги /
PhpStorm 2025.3: WSL Terminal всегда стартует в ~ and_y87 14.12.2025 PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .	Как объединить две одинаковые БД Access с разными данными VikBal 11.12.2025 Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.	Новый ноутбук volvo 07.12.2025 Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro	Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .	Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .

@titan4ik Заблокирован

	Метод Interlocked.Exchange(Double, Double) не гарантирует одинаковое значение переменной в разных потоках? 20.03.2024, 13:45. Показов 2566. Ответов 48 Метки interlocked, interlocked.exchange, атомарность, потокобезопасность (Все метки) Метод Interlocked.Exchange(Double, Double) обеспечивает атомарность операции присвоения нового значения переменной типа Double. То есть, InterlockedExchange гарантирует, что изменение переменной и возврат ее исходного значения не будут прерваны другими потоками. Но есть ли гарантия, что данная переменная будет после этого иметь одно и то же значение в разных потоках, в том числе, исполняемых на разных процессорах? Похоже, что нет. Но если нет, то тогда для обеспечения одинакового значения переменной нужно применять lock? И тогда, если блокировать код присвоения с помощью lock, то тогда Interlocked.Exchange уже нет смысла использовать? Правилен ли вывод, что Interlocked.Exchange имеет смысл применять в том случае, когда не нужно, чтобы значение переменной во всех потоках было одинаковым (самым последним)? А преимущество Interlocked.Exchange по сравнению с блокировкой lock в том, что Interlocked.Exchange не тормозит потоки? 0

@titan4ik Заблокирован
	20.03.2024, 15:40 [ТС]
	Чтобы вбить последний гвоздь в... Не будет глупостью такой код в котором некий кусок кода заблокирован с помощью lock, а внутри него некоторые отдельные операции защищены ещё и с помощью методов Interlocked? 0

@IamRain
	20.03.2024, 16:12
	Не по теме: titan4ik, сокращение от performance. Когда много буржуйских буков читаешь, иногда русский эквивалент кажется менее точным и неподходящим, поэтому хочется англоязычную терминологию использовать. К тому же так сильно короче. Это как Solution и Решение. 0

@titan4ik Заблокирован
	20.03.2024, 16:17 [ТС]
	Не по теме: ну да, буржуйские лучше, чем калька на русском Добавлено через 2 минуты Но как я понял, отличие Interlocked и всяких lock-ов не только в производительности. lock же не обеспечит того, чтобы во всех потоках переменная имела одно значение. Этот же вопрос главный был. Меня конкретно тип Double интересовал. 0

@titan4ik Заблокирован
	21.03.2024, 13:48 [ТС]
	Не по теме: Прочитал первую и просмотрел вторую. Мда. В современном мире, в котором всем управляют менеджеры, которые смотрят в монитор и отвечают вам что-то вроде: "А у меня в компьютере...", всё возможно. Любой, самый нелепый исход. Однажды можно проснуться и узнать, что "в компьютере написано", что вас уже нет. Или - что никогда не было. А как там системы предупреждения о ракетном нападении и автоматического ответа на него? Мда. Ж/Д стрелки и т.п. В связи с многопоточностью и т.п. появилось конкретное соображение относительно прав собственности и их смены. Сейчас отменены "Свидетельства о праве собственности". есть только записи в реестре (в компутере). Можно получить выписку из реестра (компутера). При сделках с недвижимостью требуют "свежую" выписку. Но какой бы свежей она ни была, это не гарантирует того, что после получения этой выписки, недвижимость уже была продана. Предлагаю ввести блокирующую выписку! То есть, перед сделкой продавец должен получить выписку, которая на определенный срок (например, на 10 дней) блокирует все сделки с этой недвижимостью за исключением продажи данному конкретному покупателю, о чем и будет указано в этой выписке. 0

@titan4ik Заблокирован
	27.03.2024, 09:10 [ТС]
	nicolas2008, то есть, если расположить способы в таком порядке, что сначала лучшие, то так (?): №3 - минусов нет №1 - Минусы - все попытки чтения будут включать вызов Thread.MemoryBarrier(), а это доп издержки которые не всегда нужны. №4 - Thread.MemoryBarrier(), а это доп издержки которые не всегда нужны и может ввести в ступор большинство погромистов, повышен риск что непонятный код будет удален после короткого тестирования и подтверждения что "все и так работает нормально". №2 - Минусы - это как из пушки по воробьям. lock вызывает метод ядра, а это очень дорогая операция (тысячи тактов если не ошибаюсь) --- Тогда лучший рецепт - Interlocked для изменения плюс Volatile.Read для чтения? 0