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

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

0

titan4ik, Interlocked для атомарных операций, которые иначе выполнялись бы как последовательность, а так то да, я бы использовал Volatile.Read

1

Сообщение от titan4ik №2 - Минусы - это как из пушки по воробьям.

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

Сообщение от titan4ik №3 - минусов нет

А барьеры памяти магическим образом исчезают чтоль? titan4ik, вы читали тут старую статью выше от Игоря Островского? К посту от nicolas2008 есть много вопросов.

0

IamRain,
Лучше бы Вы ссылались на сообщение от nicolas2008, я ведь просто скопировал его утверждения. Сам я ничего не утверждаю.

Сообщение от IamRain К посту от nicolas2008 есть много вопросов.

Это лучше с nicolas2008, обсудить. А мне было бы полезно посмотреть это обсуждение.

0

Сообщение от IamRain Не надо мешать блокирующие примитивы синхронизации и инструменты языка для атомарных операций.

А кто мешает?
Метод указан для общего развития. При вызове Monitor.Enter неявно создается MemoryBarrier.

Сообщение от IamRain А барьеры памяти магическим образом исчезают чтоль?

Барьер памяти как раз создается, как и в остальных трех методах.

Сообщение от IamRain К посту от nicolas2008 есть много вопросов.

К вашему комментарию много вопросов. В чем проблема с методом 3.

0

Сообщение от nicolas2008 Барьер памяти как раз создается, как и в остальных трех методах.

Я пытаюсь практическое зерно сформулирвать:
Если во всех трех этих (№№ 1, 3 и 4) методах создается идентичный барьер памяти, то по этой своей сути они равнозначны.
И у них общий минус общий - "все попытки чтения будут включать вызов Thread.MemoryBarrier(), а это доп издержки которые не всегда нужны."
А отличия лежат в другой плоскости. Насколько они значимы эти отличия?
Проблемы психологического характера ("может ввести в ступор большинство погромистов, повышен риск что непонятный код будет удален после короткого тестирования и подтверждения что "все и так работает нормально") понятны и меня мало волнуют.
А у метода №2 с lock - самые большие издержки.
То есть, пока, кажется так, что можно любой из методов №№ 1, 3 и 4 применять с равным успехом. И что все они лучше по издержкам метода №2 примерно в равной степени.

0

titan4ik, есть ещё такой способ чтения:

1

Как раз сегодня увидел плакат с такой надписью:

.NET разработчики: чего мы хотим? Меньше альтернатив!

2

Сообщение от nicolas2008 А кто мешает?

Имелось ввиду, что оригинальный вопрос был про Interlocked класс и все, что с ним связано - атомарные операции и запрет на reordering optimization (то, что умеет volatile).
Уточняю: зачем здесь в списке сравнения lock? Почему бы сюда коней не добавить - не рассказать про Mutex-ы и Semaphore-ы еще?

0

IamRain, мешанина если и есть, то у меня в голове А это нашло отражение и в тексте вопроса (там и lock фигурирует). Так что lock помянуть в ответах было уместно и правильно.

Добавлено через 1 минуту
Правильный вопрос должен был бы звучать так - Как сделать так, чтобы всё было просто, хорошо и за это ничего не было)

0

Сообщение от titan4ik Если во всех трех этих (№№ 1, 3 и 4) методах создается идентичный барьер памяти, то по этой своей сути они равнозначны.

volatile - это запрет на reordering, работающий при чтении и при записи по-разному, насколько я понимаю.
А Volatile.Read - это, очевидно, только на чтение. То есть через класс Volatile можно более гибко работать с меньшим оверхедом по перфомансу.
Ну это все очень нишевое применение - тот, кому понадобится, сам найдет наиболее подходящий способ.

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

Сообщение от titan4ik Так что lock помянуть в ответах было уместно и правильно.

Ну ок.

1

Сообщение от IamRain Почему бы сюда коней не добавить - не рассказать про Mutex-ы и Semaphore-ы еще?

Можно рассказать почему нет Но это все из разряда kernel lock, по сути тот же метод 2

0

1) Посмотрел сейчас описание класса Volatile на русском языке. Трудно понять. Видимо машинный перевод.
Но главное понял - если в одном потоке произошла запись в переменную с помощью метода Volatile.Write(), то это не гарантирует, что при чтении в другом потоке с помощью метода Volatile.Read(), даже в последующем по времени (!) относительно Volatile.Write(), будет прочитано уже измененное значение переменной. Не гарантирует.
То есть, методы чтения и записи класса Volatile гарантируют только отсутствие перестановки операций.
Если Volatile.Write(), то операции, которые идут до него, не могу быть перемещены после него.
Если Volatile.Read(), то операции, которые идут после него, не могу быть перемещены до него.
2) Если используется модификатор переменной volatile, то он запрещает перемещать операции через операцию с этой переменной в обе стороны - предшествующие и последующие операции такими и останутся. Но volatile тоже не гарантирует, что во втором потоке будет прочитано значение уже измененное в первом.
3) А если нужны гарантии того, чтобы во всех потоках переменная имела одинаковое значение, то нужно либо очень изощрённо напрягать мосх, либо обходиться методами Interlocked, либо использовать блокировку lock, либо что-то вроде потокобезопасных коллекций.
Нужно ещё и это посмотреть;

упрощенные механизмы синхронизации, например SpinLock, SpinWait, SemaphoreSlim и CountdownEvent, которые впервые введены в .NET Framework 4. Эти типы синхронизации обычно используют цикличную работу для коротких промежутков перед помещением потока в фактическое состояние ожидания.

P.S.
Интересно, потокобезопасные коллекции есть, а потокобезопасных переменных хотя бы базовых классов (int, double и т.п.) нет.

0

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

Добавлено через 2 минуты
Можете еще про когерентность кеша процессора почитать (согласованность данных для разных ядер). В интернетах пишут что в современных процессорах кеш общий и/или всегда согласован.

1

Сообщение от nicolas2008 В интернетах пишут что в современных процессорах кеш общий и/или всегда согласован.

В итоге получается, что работа многопоточной программы существенно зависит от реализации "вычислительной системы". Надеюсь, что у меня есть (или будет) современный процессор

Сообщение от nicolas2008 а где это такое написано что "не гарантирует"?

Even though the volatile write to y on thread 1 occurred before the volatile read of y on thread 2, thread 2 may still see y2 == 0. The volatile write to y does not guarantee that a following volatile read of y on a different processor will see the updated value.

https://learn.microsoft.com/en... ew=net-8.0
Возможно, я не так понял.
Там есть ещё примечание.

Volatile reads and writes ensure that a value is read or written to memory and not cached (for example, in a processor register). Thus, you can use these operations to synchronize access to a field that can be updated by another thread or by hardware.

Но по сути своей "примечание" должно дополнять текст, а не исправлять его.
Возможно, я не так понял. Буду рад, если это так. Тогда проще жить!

1

Сообщение от titan4ik Но главное понял - если в одном потоке произошла запись в переменную с помощью метода Volatile.Write(), то это не гарантирует, что при чтении в другом потоке с помощью метода Volatile.Read(),

Это такая эфемерная характеристика "время" для мультипотока, да ещё на разных процессорах (ядрах).

Очень приблизительно:
1) Есть некий флаг в Москве и его дубли в регионах;
2) Когда в регионе флаг подымается/опускается - посылается письмо в Москву произвести там тоже действие;
3) Когда надо в регионе определить состояние флага - то посылается письмо в Москву и там отвечают.

Добавлено через 4 минуты
Решили поднять Флаг на Камчатке и послали письмо в Москву. Письмо идёт в Москву неделю.
А через два дня в Рязани решили проверить состояние флага. Письмо идёт в Москву за день. И там отвечают что флаг опущен, хотя на Камчатке его уже подняли и они считаю, что по всей стране уже подняли.

Добавлено через 9 минут
Локирование же это такой процесс:
1) Прежде чем узнать/изменить состояние флага - посылается письмо-запрос в Москву;
2) В Москве очередь писем с запросами. Берут первое из очереди и по нему отвечают "Начинайте действовать". Все остальные запросы отстаются ждать в очереди;
3) В регионе получили разрешение. После этого посылают в Москву письмо сообщить или изменить состояние;
4) Когда для региона станет неважен Флаг, посылают письмо об этом;
5) Когда получили от региона письмо о завершении работы с флагом - берут следующий запрос из очереди.

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

1

Сообщение от Элд Хасп Это такая эфемерная характеристика "время" для мультипотока, да ещё на разных процессорах (ядрах).

Но это плохо. Потому и есть необходимость синхронизации данных путём специальных программных уловок.
Собственно, в материалах по параллельному программированию всегда по 10 раз пишут одно и то же - старайтесь, чтобы обрабатываемые параллельные процессы не использовали общих данных. Чтобы изначально уйти от источника проблем.

0

Сообщение от titan4ik Потому и есть необходимость синхронизации данных путём специальных программных уловок.

Совершенно верно.
Всё зависит от условий конкретной задачи.
Так как, то что подразумевается под синхронизацией зависит от конкретного задания.
Точное совпадение по таймингам в разных потоках - это исключительно редкое условие. Оно больше свойственно каким-то реалтайм системам, чем обычной обычному DeskTop под Виндой.
Под Виндой для мультипотока почти всегда требуется обеспечение потокобезопасности при работе с данными.
Условно: считал значение X, произвёл какие-то вычисления, записал новое значение X. И здесь требуется гарантировать, что значение X не будет изменяться из другого потока на время этих действий.
Или считываешь коллекцию (в том числе байты Double) и нужно гарантировать, что в процессе считывания не никто не меняет эту коллекцию. Чтобы не получить, например для Double, первые байты от одного значения, а последние от другого.

Точная синхронизация по времени, если нужно, осуществима, но это всегда "дорого".

0

Сообщение от nicolas2008 а где это такое написано что "не гарантирует"?

nicolas2008, я так и не понял, каждый раз, когда я пытаюсь кратко резюмировать ответ на главный вопрос - каким способом можно обеспечить потокобезопасность данных, у кого-то появляется ремарка, мол, что-то не так я формулирую.
Моя последняя формулировка тоже не верна? Я потом привел ссылки.

0

Сообщение от titan4ik Моя последняя формулировка тоже не верна? Я потом привел ссылки.

Последовательно.

Сообщение от titan4ik Но главное понял - если в одном потоке произошла запись в переменную с помощью метода Volatile.Write(), то это не гарантирует, что при чтении в другом потоке с помощью метода Volatile.Read(), даже в последующем по времени (!) относительно Volatile.Write(), будет прочитано уже измененное значение переменной. Не гарантирует.

И да, и нет.
Главный вопрос "что считать последующем по времени"?
Если приход сообщений в какой-то узел (как я описывал выше в Москву) - то гарантирует.
Если отправку сообщений - то нет.

Volatile - это всего лишь отправка сообщений "в центр". Функции синхронизации времени между потоками его методы не имеют.

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

Да.

Сообщение от titan4ik 3) А если нужны гарантии того, чтобы во всех потоках переменная имела одинаковое значение, то нужно либо очень изощрённо напрягать мосх, либо обходиться методами Interlocked, либо использовать блокировку lock, либо что-то вроде потокобезопасных коллекций.

И да, и нет.

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

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

Мютекс, lock и т.п. - это уже действительно про синхронизацию.
Но все они дорогие.

1

Да, всё не просто.

Сообщение от Элд Хасп Volatile - это всего лишь отправка сообщений "в центр". Функции синхронизации времени между потоками его методы не имеют.

Если Volatile обеспечивает взаимодействие потоков через некий "центр", то это уже хорошо. В этом случае, если в "центре" изменилось значение переменной, то при чтении из любого потока оно должно быть прочитано правильно. Хотя ваш пример с флагами показывает, что не всегда так. Да. Понятно. В общем нужно знать как это всё работает на низком уровне. А на низком уровне всё определяется системой и ещё ниже особенностями устройства процессора.
Тут прямо пишут, что синхронизации нет:

Несмотря на то, что переменная запись в потоке 1 произошла до переменного чтения y в потоке 2, поток 2 по-прежнему y может видеть y2 == 0. Переменная запись в y не гарантирует, что при следующем переменном чтении y на другом процессоре будет отображаться обновленное значение.

https://learn.microsoft.com/ru... .0#remarks
Но ниже в примечании такой текст:

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

??? То есть, флаг по сути один - в центре. А из регионов (потоков) можно только посмотреть на флаг или дать команду на его смену.
??? и что в итоге???

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

Насколько я понимаю, interlockid может обеспечивать потокобезопасность.

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

https://learn.microsoft.com/en... stem-int32
(и даже ссылка у них работает не правильно! - попадаем на начало статьи )

В общем, похоже, что стране нужен герой, который в одном связном тексте кратко опишет все аспекты применения этих инструменты атомарности и синхронизации с учетом конкретного физического устройства процессоров. И всё это с учетом того что актуально на сегодняшний день. И в плане процессоров и в плане инструментов. Исторический аспект (не актуальные инструменты и старые процессоры и т.п.) лучше вынести в некое приложение.

Добавлено через 2 минуты
А так. Слишком много "Но". И слишком много противоречий в текстах и мнениях.

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

0