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

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

0

Сообщение от Igor3D Вместо этого напускают туману

На мой взгляд, тут дело не в том что, как Вы выразились, напускают туману, а в том что разбираются, по сути, два не совсем связанных случая.
Первый - это изменение какой-то переменной в разных потоках, с гарантией, что эта переменная видна во всех потоках в актуальном состоянии, и второй - это уже не про собственно переменную, а синхронизацию операций (например, работают три потока, и они должны гарантированно выводить A, B и C, и только в таком порядке). Это разные задачи, и решать их нужно немного по разному.
Тот пример, что был приведен на 2 странице данной темы, на мой взгляд, как раз относится ко второму случаю (хотя, если я его правильно понял, там просто используется т.н. холостой цикл, что не совсем верно). Если бы мне пришлось делать именно синхронизацию потоков, я бы выбрал или std::condition_variable (C++), или pthread_cond_t/pthread_barrier_t (C). Но я исхожу из задач практических, а как оно там внутри будет устроено, меня уже не так волнует.

0

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

Близко, но не совсем так.

Речь о семантике упорядочения памяти в данном контексте ведется не потому, что она влияет на некие посторонние абстрактные операции "выводить A, B и C", а именно о тех же самых операциях синхронизации потоков, когда у вас есть не один, а несколько таких "доморощенных" синхронизационных примитивов. То есть, например, у вас есть не одна, а три переменных - A, B и C - которые вы используете для целей синхронизации потоков через операции записи и чтения. Одни потоки записывают в эти переменные значения, скажем, 0 и 1, а другие проверяют содержимое этих переменных и на основе этого принимают решение ждать или работать дальше (0 - свободно, 1 - занято). И для того, чтобы избежать дедлоков, в ситуациях, когда потокам нужно поменять или проверить две или более таких переменных, они договорились делать это строго в заранее оговоренном относительном порядке A -> B -> C.

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

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

0

Очень умные все. Наверное TheCalligrapher научил. Плохо понимаю вообще.

0

TheCalligrapher, ну возможно, но я, как и сказал ранее, не стал бы мудрствовать лукаво, разбираясь в командах для различных архитектур (коих множество, и я в них как свинья в апельсинах), а просто использовал бы имеющиеся инструменты в С или С++, будучи уверенным, что это гарантированно работает и выполняет то и так, как я ожидаю.
Что касается гарантий упорядочивания памяти - насколько я помню, по умолчанию используется самая строгая, а это собственно даст максимальные гарантии. Ну а далее, когда все будет работать, там уже можно заниматься оптимизацией (если за это заплатят).

0

Сообщение от TheCalligrapher Меня веселит и поражает то, что ChatGPT постоянно с уверенным видом несет чушь

А что вы ему пишете, то он и пишет в ответ. Пишите проще.

0

0

Вот это мне подсказал ИИ в прошлой писанине.
Вызывать функцию рекурсивно уже с переименованным путём.
Строка 11 - 15.
Не обрабатывало сразу данные. Не заходило в переименованные папки.
Вы же ни кто не подскажете...

А писанина это моя...
И.И. - Инструмент... Пользоваться уметь надо...

0

Сообщение от Наталья8 Вы же ни кто не подскажете...

могу только покритиковать)) особенно, когда вместо С++ вижу "С++ в стиле С с использованием расширений Microsoft (Microsoft CRT)". Не знаю, как назвать это порно?

Этот код не кроссплатформенный, даже если он не использует Win32 API напрямую, а лишь CRT от майкрософт. К тому же, использование виндового разделителя пути L'\\' крякнет на других платформах.

А ведь можно было написать проще, на современном С++17 и кроссплатформенно:

типа вот такой псевдокод по мотивам примеров из cppreference

не тестировал, писал на заборе

Сообщение от Наталья8 А писанина это моя...

мог и не писать, это и так заметно

0

0

0

0

Сообщение от zayats80888 jcxz, я не собираюсь заниматься демагогией, я просто попросил озвучить контракты, как пользоваться вашей "синхронизацией". Столько текста и ноль полезной информации.

Тогда и не занимайтесь.
А насчёт "полезной инфы": Вся достаточная инфа была в моём примере. А если кто его не понял - я не виноват. Если вы его не поняли - пройдите мимо. Не ваше это значит, займитесь чем-то другим.

Сообщение от zayats80888 Этот порядок может быть очевиден всем, мне, вам, товарищу выше. Он даже может быть физически реален, никто не спорит. Только в связи с особенностями работы различных компиляторов и "аппаратных железяк", этот очевидный всем порядок бесполезен. ...

...и тря-ля-ля далее... кто бы ещё говорил о демагогии и троллинге.

Сообщение от Recrut_rf почему вы считаете, что приведённый вами, в одном из первых сообщений данной темы, пример кода будет корректно и гарантированно работать. Ограничимся Windows (допустим 10 / 11) и x86 / x64.

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

0

SarJohnDoe, чтобы вставить прямую ссылку на конкретный пост, бери адрес отсюда:

1

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

_freea(Mask)
*(wcsrchr(new_full_Path, L'\\') + 1) = '\0';
wcscat(new_full_Path, new_name)
Конечно можно понять из контекста / названия / да хоть погуглить. Но когда с подобным не работал - советовать что-то сложно.

Лично мне гораздо проще и привычнее работать с std::string и его производными, с умными указателями и прочими современными вещами. А возвращаться в С++ 98/2003 чёт как то не охота....
На работе это не требуется - за него ещё и по голове настучат. Разве что на собесах....

1

Сообщение от Igor3D Вот пример из справочника где флажок done (тот же stopFlag) объявлен обычной переменной, без всяких атомиков, не говоря уже о volatile. И все работает.

Работает до тех пор, пока компилятор не использует максимальную оптимизацию и пока функции waits() и signal() находятся в одной единице компиляции (файле). Если разнести их в разные единицы, включить макс.оптимизацию и запретить "компиляцию единым файлом", то может перестать работать.
О чём говорил тут уже неоднократно.

Сообщение от Igor3D Эта = та о которой спрашивал по меньшей мере дважды

Говорил то что выше по-крайней мере трижды. Если вынуть голову из эээ.... песка, то можно даже суметь прочитать.

Сообщение от Igor3D Но и не подтверждает.

Какого вам ещё подтверждения надо? На гербовой бумаге с печатью?

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

Вобщем да - вижу тут собрались одни демагоги и тролли....

На сём ставлю точку. Далее переливайте из пустого в порожнее без меня.

0

Сообщение от jcxz Пишете, что знаете си...

С++ а не Си, на Си никогда вообще не писал. В С++ тоже не гуру программирования, что-то знаю, но до
TheCalligrapher, zayats80888, и прочих экспертов мне как до луны пешком.

И это не издёвка, сарказм, троллинг и прочее - это чистая правда. А опираюсь я вот на это
цитата из cppreference
Note that volatile variables are not suitable for communication between threads; they do not offer atomicity, synchronization, or memory ordering. A read from a volatile variable that is modified by another thread without synchronization or concurrent modification from two unsynchronized threads is undefined behavior due to a data race.
То есть - при использовании volatile для синхронизации получаем неопределённое поведение. А UB означает, что случиться может всё, что угодно - сегодня работает, завтра работает, а через 10 лет даст сбой.
А вы утверждаете что пример корректный.

Вот я и никак не могу понять - в стандарте одно, в реальности другое. Мож в жопу стандарт ? Его тоже люди сочиняют и могут ошибаться.

0

0

Сообщение от jcxz На сём ставлю точку. Далее переливайте из пустого в порожнее без меня.

ээээ нет - подождите!!!!

Я на полном серъёзе - СЕЙЧАС Я ПОСТАВЛЮ ТОЧКУ В СРАЧЕ В ДАННОЙ ТЕМЕ, потому как похоже докопался до истины.....
и это не тролллинг......

Добавлено через 11 минут
в коде происходят две разные вещи:
Автор кода хочет получить:
1. Компилятор действительно каждый раз обращается к state
+
2. Чтение/запись state неделимы и корректно видны другому исполнителю

volatile обеспечивает первую часть.

Вторая часть должна исходить из гарантий конкретной платформы.

Если автор говорит:

«Я предполагаю платформу, где чтение и запись int атомарны»

и его модель выполнения также гарантирует необходимую видимость между ядрами/исполнителями, тогда его алгоритм работает.


А стандартный C++ говорит другое:

Для переносимого C++ нужно выразить вторую часть явно:
std::atomic<int> state{0};

Тогда стандарт гарантирует необходимые свойства атомарного объекта.

Поэтому получается очень точная формулировка:

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

И ещё важное уточнение к твоей фразе «по стандарту C++ нет»: это не значит, что стандарт запрещает такой код или что он обязательно неправильно работает. Он просто не даёт тебе необходимых межпоточных гарантий для volatile int.


Именно поэтому автор может совершенно обоснованно сказать «этот алгоритм работает на x86/ARM/bare-metal», а стандартный C++ программист одновременно может сказать «volatile int недостаточно для portable C++ multithreading». Эти утверждения друг другу не противоречат.

Шах и мат господа теоретики и практики!!!

И да - это я нейронку терзал.

0

картинка для пояснения

Миниатюры

 

0

0