Имеет ли смысл создавать volatile переменную

У меня есть функция Вызов написал в таком виде:Имеет ли смысл такая конструкция или лучше воспользоваться обычной переменной double?

0

Сообщение от Recrut_rf картинка для пояснения

Нет. Просто "ordering" - это ничего не значащий термин. Полное отсутствие ordering - это тоже один из видов ordering в С и С++. А именно: memory_order_relaxed - это атомарность самой модификации, но никаких гарантий ordering.

Ещё раз: для того, чтобы синхронизация на основе тупой записи/проверки volatile переменных работала, нужен не просто "ordering", а total ordering, то есть все операции записи-чтения должны выполняться с memory_order_seq_cst. Ни одна платформа вам такого "из коробки" не гарантирует.

"Из коробки" на некоторых платформах вы получаете только acquire/release семантику. Это хороший и весьма сильный ordering. На его основе можно построить корректные синхронизационных примитивы. Но это будет совсем не тупое "записал/проверил переменную".

1

TheCalligrapher, спасибо, понял.

В общем - если подытожить. Что, в общем то вы уже давным давно сделали

имеем два подхода в программировании:
1 - условно железячный.
Много лет изучаем кунгфу чтобы перейти реку прямо по воде, а не потонуть на полпути
Досконально изучаем архитектуру платформ и все её тонкости и используем эти знания в программировании. Принимая на веру, что оно работает именно так и что во всём досконально разобрались. Язык здесь чисто как средство перенести систему команд процессора на более высокий уровень. А стандарт вторичен. Поэтому на его гарантии плевать, главное в коде "отобразить" систему команд.

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

Какому пути следовать - пусть каждый решает сам.

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

0

Сообщение от SarJohnDoe В другой теме (именно по этому вопросу) мной приводился прямо полный код

А я прокомментирую. Это писал искусственный интеллект.
И ответственности ни кто не несёт. И в закорючках redex, я ни чего не понимаю.
Это называется гавном бросаться.
Надеюсь это вам не составило труда.
Вообще искуственный интеллект в логике не силён и лажает сильно...
========
WinApi для винды, волшебная вещь.
И оно не пишеться новое, не меняеться (deprecated), каждый год.
Насколько волшебное?
Извиняюсь... То что мы здесь делаем называеться публиковать.
Я совсем не уверен, что надо всё публиковать.
Не ломаю программы. Пишу обёртки.

Добавлено через 25 минут
Royal_X,
Ты тоже тролль ещё тот... Мне такую хрень все пишут всё время.
И ни чего конструктивного.
И я тоже тролль. Потому что ни хрена мне не надо.
Так, делать не чего...

0

Recrut_rf,
Мне не хочеться вас обижать,

А что это за функция?

0

Сообщение от Наталья8 Мне не хочеться вас обижать

да я не из обидчивых

описание функций можно вот тут смотреть cppreference.com

тут и С и С++ и лишней "воды нет", а ещё есть примеры.

ну и да - я хреново знаю сишную часть стандартной либы С++. Очень редко приходится пользоваться.

Сообщение от Наталья8 WinApi для винды, волшебная вещь.

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

0

Сообщение от Recrut_rf Лично я сходу не смогу - надо почитать описания, какую функцию лучше вызвать и почему.

Так с ходу никто и не пишет (уж Наталья8 точно), все равно все так или иначе смотрят документацию. Наведение курсора в IDE не поможет понять смысл всех параметров функции.
Допустим, для самой банальной функции имеем:
Очевидно, что даже тут без документации не понять, как правильно ввести аргументы. В документации есть здоровенная страница про эту функцию.
Ну разве что можно обойтись без документации, когда одну и ту же функцию или кусок кода ты используешь часто и знаешь уже наизусть или просто есть готовый кусок. В таких случаях, конечно, работа идет быстрее. Например, у меня уже есть целая коллекция разнообразных кусков кода для всяких задач на WinAPI и я их просто переиспользую.

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

Сообщение от Recrut_rf тут и С и С++ и лишней "воды нет", а ещё есть примеры

мне кажется, Наталья8 знает про сайт https://en.cppreference.com. Это просто такой популярный ресурс, что любой программист С++/С (даже хоббист) должен знать про него. Есть еще альтернативный сайт https://cplusplus.com/reference/.

0

wcsrchr - строковая функция для широких строк. UTF16. Есть аналог - strrchr для узких строк.
Она устанавливает указатель на найденный символ с права. Отправная буковка "r".
Без буковки "r" - wcschr поищет знак с лева.
Если туда, вместо знака вставить нультерминатор,
то строка на этом месте закончиться и можно туда - wcscat(), (конкатенация строк) привинтить что нибудь другое.
Могу посчитать символы, между указателями - wcslen()/ strlen().
Или модернизировать часть строки memcpy() например. Или strncpy().
Отправная буковка - "n" - number... Несколько знаков без нуль терминатора.

Вот эти указатели, устанавливаемые на знаки, можно подвергать арифметике.

Номерное сравнение двух знаков в стоке с константой "20"
wcsncmp(end_of + wcslen(end_of) - 4, L"20", 2) == 0)
wcsncmp(здесь вычисляемый указатель
На память помню всё...
А вы мне все пишете - std::filesystem.
Нахрена она мне впала? И Redex аналогично.

0

0

Сообщение от SarJohnDoe и второй - это уже не про собственно переменную, а синхронизацию операций (например, работают три потока, и они должны гарантированно выводить A, B и C, и только в таком порядке).

Сообщение от TheCalligrapher Без гарантий упорядочения памяти разные потоки могу "видеть" разные относительные порядки изменения значений в этих трех переменных. То, что один поток честно придерживался договоренности выставлять переменные в порядке A -> B -> C, совсем не гарантирует, что читающий поток "увидит" изменения этих переменных в том же порядке. Вышеупомянутая договоренность без гарантий упорядочения памяти просто не работает.

Я помню в книжке подобное "увидеть в том же порядке", но не понял и не стал прилагать усилия. Ни о каких трех потоках и A, B, C я не спрашивал. Что это за "увидеть"? Поток записал 1 в переменную что была 0. Другой поток прочитал. Если 1 - значит "увидел", иначе "не увидел". Других разумных вариантов я не вижу. А если так, то нужно ответить на мой вопрос типа "да, без синхронизации другой поток может прочитать старое значение хотя запись первым потоком состоялась". А не вилять с увидел/не увидел. "В том же порядке" из той же оперы. Понятно что любое чтение (включая атомарное) соответствует значению на какой-то момент времени который уже прошел (и значение в принципе может быть изменено). Поэтому речь может идти только о последнем значении до синхронизации. И наконец, все это актуально только для данных неатомарных или со слабой атомарностью. В общем, что там за "увидеть в том же порядке" - мутность великая

0

Сообщение от Igor3D Поток записал 1 в переменную что была 0. Другой поток прочитал. Если 1 - значит "увидел", иначе "не увидел". Других разумных вариантов я не вижу. А если так, то нужно ответить на мой вопрос типа "да, без синхронизации другой поток может прочитать старое значение хотя запись первым потоком состоялась".

Igor3D, если вы все еще про свой "флаг для остановки потока", то вам для этого не нужна синхронизация, вам нужна гарантия атомарности изменения и того, что это изменение будет увидено когда нибудь. Все. Для этого достаточно std::atomic + std::memory_order_relaxed.
Для большинства остальных практических задач конкурентного программирования нужна сихронизация, т.к. там важен порядок.

0

Наталья8, пасиб за ликбез

0

Сообщение от zayats80888 то вам для этого не нужна синхронизация, вам нужна гарантия атомарности изменения и того, что это изменение будет увидено когда нибудь. Все. Для этого достаточно std::atomic + std::memory_order_relaxed.

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

(где global_variable - обычная глобальная переменная, не volatile, не _Atomic).

Если переменная stop_flag является _Atomic, то в странслированном коде программы присваивание global_variable = 42 будет гарантировано выполняться до присваивания stop_flag = 1. Если же переменная stop_flag является просто volatile, то присваивание global_variable = 42 запросто может быть перенесено компилятором и выполнено после присваивания stop_flag = 1. Обратите внимание, что в данном случае речь идет совсем не о странных аппаратных переупорядочениях, контролируемых всякими memory_order_..., а о банальном чисто языковом порядке выполнения операций в рамках оптимизационного правила "as-if".

То есть поток, ожидающий команду прерваться через переменную stop_flag = 1 ее получит - для этого достаточно атомарности записи и чтения stop_flag. Однако вполне может оказаться, что этот завершающийся поток напоследок еще собирается сделать какие-то прощальные телодвижения в расчете на то, что global_variable равно 42. А это может оказаться не так.

Чтобы решить эту проблему в случае volatile stop_flag вам придется сделать global_variable тоже volatile. А это криво и косо, ибо тотально подавит все оптимизации для этой переменной. _Atomic переменные решают эту задачу по-другому: вводят понятие барьера, при пересечении которого все переменные, доступные другим потокам, могут "необъяснимо поменяться". Пока такой барьер не пересекается, работу с переменной можно оптимизировать обычным образом.

0

Сообщение от TheCalligrapher Однако вполне может оказаться, что этот завершающийся поток напоследок еще собирается сделать какие-то прощальные телодвижения в расчете на то, что global_variable равно 42.

Тогда это будет уже не "стоп флаг" (аля сигнал о получении сообщения и сообщение в одном флаконе), а совсем другая задача (флаг - только сигнал, сообщение отдельно). Разумеется, в этом случае нужна синхронизация.

Сообщение от TheCalligrapher Чтобы решить эту проблему в случае volatile stop_flag вам придется сделать global_variable тоже volatile.

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

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

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

Сообщение от TheCalligrapher _Atomic переменные решают эту задачу по-другому

Мне интересно, почему вы тут упоминаете именно _Atomic, неужели С-компилятор будет вести себя иначе, чем С++-компилятор c std::atomic в этом отношении (при прочих "равных", разумеется)?

0

Сообщение от TheCalligrapher вам придется сделать global_variable тоже volatile. А это криво и косо, ибо тотально подавит все оптимизации для этой переменной. _Atomic переменные решают эту задачу по-другому: вводят понятие барьера, при пересечении которого все переменные, доступные другим потокам, могут "необъяснимо поменяться". Пока такой барьер не пересекается, работу с переменной можно оптимизировать обычным образом.

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

0

Сообщение от Dushevny Какая-то извращенная логика...

В вашей претензии конечно есть логика, но я хочу сказать, что те самые оптимизации, которые вы вынесли в промежуточные вычисления, никак не будут затронуты, они в любом случае не могут "перепрыгнуть" факт записи их результатов (это не относится к программистам, которые не используют локальные объекты, а объявляют все переменные в глобальной области, им воообще никакие оптимизации не помогут). На а те же, что будут затронуты, возможно не так и критичны? Там, где вам кажется, что у вас есть выбор между двумя volatile и одной std::atomic с подходящей семантикой, я уверен, в большинстве случаев, выбор последней ничего не изменит, но при этом код будет корректный и для тех случаев, где такого выбора в принципе не стоит.

0

Сообщение от zayats80888 Тогда это будет уже не "стоп флаг" (аля сигнал о получении сообщения и сообщение в одном флаконе), а совсем другая задача (флаг - только сигнал, сообщение отдельно). Разумеется, в этом случае нужна синхронизация.

Такая ситуация по меньшей мере возможна, напр
Возможно что в результате оптимизаций компилятора и/или процессора прочитается flagStop = 1, но errorCode еще не будет записан (когда-то подобная проблема была с оператором new). Это ведет к ошибке. Вернемся к моему вопросу

Не гарантируется что данные записанные одним потоком будут корректно прочитаны другим

Можно поупираться, мол, да записи-то еще не было. Но лично я считаю этого достаточно, ответ: не гарантируется

Хорошо, а какие еще есть варианты неверного чтения кроме "писатель не успел все записать"?

Напр возможна ли ситуация когда установленный (неатомарный) stopFlag не прочтется никогда?

Да, ну и какие мнения насчет использования все-таки НЕ атомарного stopFlag? Есть ли в этом какой-то смысл, его обычно проверяют часто. Хотя синхронизация настолько легка/приятна что копаться дальше не хочется

0

Сообщение от Igor3D Такая ситуация по меньшей мере возможна, напр

Конечно, возможно все (хотя, на практике, обычно завершающийся поток сообщает об успешности или ошибках, а не наоборот).
Для описанного вами примера, достаточно писать в flagStop с семантикой memory_order_release, а читать с семантикой memory_order_acquire. Но зная ваше пристрастие к всяким теоретизированиям, там может появится третий поток и дополнительные состояния. В итоге, наш стоп флаг затеряется в монструозной lock-free структуре с hazard pointers и т.д. и т.п. Так что специально для вас, рекомендую использовать семантику по умолчанию.

Сообщение от Igor3D Да, ну и какие мнения насчет использования все-таки НЕ атомарного stopFlag?

Мнение только одно - UB.

0

Сообщение от Dushevny которую вменяемый программист присваивает только и именно там, где это нужно (а все промежуточные вычисления выполняет в обычной переменной, чтобы дать порезвиться оптимизатору)

Никто не утверждает, что "барьерное" поведение является идеальным. Я уже демонстрировал соответствующие оптимизационные проблемы в #44.

Если на минутку отвлечься от темы конкурентного упорядочения памяти, а рассматривать только компиляторные "деоптимизации", то различия между этими двумя вариантами сводятся к разнице в том, "что" и "когда" деоптимизируется:

volatile:
Что: деоптимизируются только volatile переменные
Когда: всегда - при любом доступе к такой пременной

_Atomic:
Что: все переменные, картина aliasing которых не ясна компилятору (т.е. для которых компилятор не может доказать, что они не поменяются конкурентно)
Когда: только при пересечении сответствующего барьера

Какой способ тут лучше? У каждого варианта есть свои преимущества и недостатки. (Опять же - закрывая глаза на другие критически важные свойства _Atomic, которых volatile просто не имеет. Как только мы открываем на них глаза, тогда - _Atomic без вариантов). Бороться с нежелательными деоптимизациями придется и там, и там. И способы борьбы одинаковые - забирать вычисления в отдельную переменную: не глобальную, не volatile, и алиасинг которой ясен компилятору, см. опять же #44.

Вы говорите, что сброс в память "всех" переменных - это якобы проблема. Не думаю. На самом деле этих несброшенных переменных в каждый момент - одна-две. И это при том, что сбрасывать переменные в память компилятор и так будет много и часто безо всяких барьеров. Достаточно просто вызвать функцию из другой ТС, определение которой компилятору не видно и семантика которой не ясна.

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

Сообщение от zayats80888 Мне интересно, почему вы тут упоминаете именно _Atomic, неужели С-компилятор будет вести себя иначе, чем С++-компилятор c std::atomic в этом отношении (при прочих "равных", разумеется)?

Мне просто хочется смотреть исключительно на голое поведение ядра языка, без малейшей примеси библиотечной функциональности. До сих пор речь во многом шла в первую очередь именно о встроенных, а не перегруженных операторах. По этой же причине я предпочитаю экспериментировать сначала с C, а не С++. А уже при возникновении подозрений на различия сравнивать с С++.

Да, мы уже рассматривали код, генерируемый для std::atomic, и видели, что там ничего лишнего не появляется. Но все равно для пущей чистоты экперимента с именно встроенными операторами я прицепился именно к _Atomic.

0

Сообщение от zayats80888 Конечно, возможно все (хотя, на практике, обычно завершающийся поток сообщает об успешности или ошибках, а не наоборот). Для описанного вами примера, достаточно писать в flagStop с семантикой memory_order_release, а читать с семантикой memory_order_acquire. Но зная ваше пристрастие к всяким теоретизированиям, там может появится третий поток и дополнительные состояния. В итоге, наш стоп флаг затеряется в монструозной lock-free структуре с hazard pointers и т.д. и т.п. Так что специально для вас, рекомендую использовать семантику по умолчанию.

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

Сообщение от Igor3D Хорошо, а какие еще есть варианты неверного чтения кроме "писатель не успел все записать"? Напр возможна ли ситуация когда установленный (неатомарный) stopFlag не прочтется никогда?

Или

Почему если я, как честный пионер, пишу/читаю строго под мутексом, то никаких атомиков и синхронизаций не требуется?

И вот еще любопытный момент

Каким образом запрещается оптимизация/перестановка команд процессором? Напр первая команда пишет в ячейку памяти 1, вторая - в ячейку 2, казалось бы, ячейка 1 должна быть записана раньше. Так и есть, напр на 100 итерациях. Но вот на 101-й процессор почему-то(?) сделал наоборот, ячейка 2 записалась раньше. А другой поток это прочитал/подхватил что повело к ошибке. Ну и как с этим борются? Или я все неверно понимаю?

0

Igor3D, я понимаю, что вы активно кодили еще во времена до С++11, когда многопоточность еще не была стандартизтрована и каждый выкручивался как мог.
Но с тех пор прошло много времени, компиляторы сильно изменились, железки стали в сотни раз сложнее и быстрее (на вашем смартфоне все те фокусы уже не прокатят).
А стандартный С++ позволяет вам писать априори корректный конкурентный код, а не эмпирически. Причем все те "приемчики", которыми вы жаждите поделиться, легко переписываются на стандартный с++ без какого-либо ущерба.
Ну нет никакого смысла копаться в сортах UB. (Разве что ради поддержки legacy, хотя, сейчас можно попросить ИИ все переписать).


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


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

0