Здравствуйте, Максим, Вы писали:
М>Все зависит от того, где находится эта самая переменная
Так я и хочу с помощью volatile обеспечить ее нахождение в памяти, с возможностью буферизации на регистрах лишь на разумное время — например, в рамках вычисления выражения, в которое она входит. Это возможно, или с нынешней модой на абстракции уже и это не гарантируется?
М>когда будут сброшены процессорные кеши
За это отвечает код, изменяющий переменную.
М>итд.
А какие еще ситуации могут быть? Реальные, а не на гипотетическом железе будущего.
Нет, выставляя значение переменной вы просто меняете "локальную" копию этой переменной. Больше никаких гарантий нет (на системах где есть больше одного ядра). Чтобы эти изменения "прилетели" в другие потоки, нужны специальные процессорные инструкции которые будут добавлены компиляторм только в случае явного использования синхронизационных механизмов (volatile не входит в их число)
Здравствуйте, Максим, Вы писали:
М>выставляя значение переменной вы просто меняете "локальную" копию этой переменной.
Вы действительно принимаете меня за идиота, или придуряетесь?
М>Чтобы эти изменения "прилетели" в другие потоки, нужны специальные процессорные инструкции которые будут добавлены компиляторм только в случае явного использования синхронизационных механизмов
Фраза "за это отвечает код" подразумевает, что код использует необходимые механизмы, явно или неявно.
ЕМ>Фраза "за это отвечает код" подразумевает, что код использует необходимые механизмы, явно или неявно.
Я никак не могу понять, что конкретно вы делаете для этого? Если это volatile, то это не синхронизация от слова совсем. Можете показать примерный код?
Здравствуйте, Максим, Вы писали:
М>что конкретно вы делаете для этого?
На платформах x86/x64 — ничего не делаю, ибо не требуется. Переносить код на другие платформы пока не планирую. Если встанет такой вопрос — сделаю то, что требуется там.
Напомню, вопрос возник потому, что компилятор предупреждает не о недостаточности volatile для синхронизации, а о "нетривиальности" автоматически генерируемого конструктора класса, содержащего volatile-переменную.
М>Можете показать примерный код?
Здравствуйте, Евгений Музыченко, Вы писали:
М>>зачем понадобились volatile-переменные?
ЕМ>Для реализации некоторых легковесных методов синхронизации. Например, там, где циклически выполняется группа операций, и этот цикл нужно останавливать по внешнему сигналу. Использовать там средства ОС избыточно — по уши хватит и volatile-переменных.
OMG! Полярный песец!
Volatile не является барьером. Не атомарно. И из него никаких толком алгоритмов не построить, даже
алгоритм Петерсона требует чтоб число записывалось за один раз, атомарно.
И самое поганое, запись в volatile-переменные не упорядочена по сравнению с другими обращениями
к памяти. Компилятор может тебе сделать запись в volatile... Знаешь как? Вынести из цикла все такие записи
куда-нибудь в конец функции и выполнив там их оптом. Так оптимальней (реальная история, встретился на MIPS
на GCC 6-й версии). Нужен компиляторный барьер (роль которого впрочем выполнит любой вызов, даже inline
функции). И нужна инструкция синхронизации кешей, чего не явным образом никак не получить.
Все современные вычислительные машины, библиотеки, программы... используют для построения примитивов
синхронизации атомарные инструкции, как правило совмещённые с "аппаратными" барьерами памяти, включающими
в себя не только физическую запись регистров в память компилятором, но и выполнение специальной инструкции,
синхронизирующей кеши у процессоров (без чего, собственно, всё бесполезно! так как другой процессор
иначе эту volatile переменную не увидит).
Ты пользуешься тем, что на x86 архитектуре всё сделано, чтоб подложить соломки индусским программистам,
чтоб оно хоть как-то работало даже если и не должно. ARM или MIPS таких ошибок не простит. Особенно
современный 64-битный ARMv8, ARMv9.
Надо не морочить мозг, если речь про C++, то есть std::atomic. Если голый C -- в GCC есть два набора
builtin функций для того же. Если Windows -- спец. функции в Win32 API.
М>>>зачем понадобились volatile-переменные?
ЕМ>>Для реализации некоторых легковесных методов синхронизации. Например, там, где циклически выполняется группа операций, и этот цикл нужно останавливать по внешнему сигналу. Использовать там средства ОС избыточно — по уши хватит и volatile-переменных.
fk0> OMG! Полярный песец!
fk0> Volatile не является барьером. Не атомарно. И из него никаких толком алгоритмов не построить, даже fk0>алгоритм Петерсона требует чтоб число записывалось за один раз, атомарно.
fk0> И самое поганое, запись в volatile-переменные не упорядочена по сравнению с другими обращениями fk0>к памяти.
Здравствуйте, Евгений Музыченко, Вы писали:
М>>зачем понадобились volatile-переменные?
ЕМ>Для реализации некоторых легковесных методов синхронизации. Например, там, где циклически выполняется группа операций, и этот цикл нужно останавливать по внешнему сигналу. Использовать там средства ОС избыточно — по уши хватит и volatile-переменных.
И этот человек что-то тут про говнокод современных программистов рассуждает!
ЕМ>Напомню, вопрос возник потому, что компилятор предупреждает не о недостаточности volatile для синхронизации, а о "нетривиальности" автоматически генерируемого конструктора класса, содержащего volatile-переменную.
ЕМ>>Фраза "за это отвечает код" подразумевает, что код использует необходимые механизмы, явно или неявно. М>Я никак не могу понять, что конкретно вы делаете для этого? Если это volatile, то это не синхронизация от слова совсем.
https://docs.microsoft.com/en-us/cpp/cpp/volatile-cpp?view=msvc-170#end-of-iso-conformant: > When the /volatile:ms compiler option is used—by default when architectures other than ARM are targeted—the compiler generates extra code to maintain ordering among references to volatile objects in addition to maintaining ordering to references to other global objects. > … > This enables volatile objects to be used for memory locks and releases in multithreaded applications.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Максим, Вы писали:
М>>Мне кажется, Евгений, что так делать не стоит, volatile не гарантирует синхронизацию общих данных.
ЕМ>volatile должно гарантировать отсутствие буферизации, добавляемой компилятором. Если я, в свою очередь, гарантирую запись изменений в память параллельным потоком, то что может помешать считыванию измененных значений?
Volatile достаточно бессмысленная вещь, т.к. не гарантирует ПОРЯДКА ОПЕРАЦИЙ.
Это основная проблема. В рамках функции компилятор всё может переупорядочить.
Кроме того, для чего выставлены явные барьеры конечно.
Кроме того, даже если в компиляторе ты сделал -O0, или написал руками на ассемблере, и оно
всё получилось в нужном тебе порядке, сам процессор не гарантирует, что другие процессоры
(ядра) увидят данные в том порядке, как они у тебя записаны в память. Потому, что без
каких-то инструкций со стороны программы процессор данные вначале закеширует у себя,
а потом, когда-нибудь, начнёт медленно и печально записывать в общую память/кеш
в неизвестно каком порядке. Кроме систем с write through, но сейчас таких вроде не
остаётся уже (ибо медленно).
М>>Лучше использовать гарантированно lock-free на любых платформах std::atomic_flag ЕМ>Мне пока не актуальны платформы, отличные от x86/x64, даже ARM под большим вопросом. Ну и не люблю я библиотечных конструкций в ядерном коде — они то реализованы "с особенностями", то тянут за собой лишний код из CRT, то не реализованы вообще.
Чушь какая. Они РЕАЛИЗОВАНЫ и работают -- это ключевое. Как не важно, тем более, что на
современных процессорах именно что через спец. инструкции процессора и инлайнятся прямо
по месту, без вызова каких-то функций, и тем более без походов в ядро (что наблюдалось на
старых армах).
ЕМ>Эти рассуждения годятся для программирования на C++ в стиле каких-нибудь Python или JS, где программа имеет дело с абстрактной виртуальной средой.
Я вообще не понимаю, как чего-то может добиться человек не обладающий абстрактным мышлением.
Наличие абстракции не препятствует её применения к частному случаю. И если что-то верно для абстракции, то верно
и для частного случая реализации данной абстракции, что очень удобно. А наоборот -- не работает.
Я уже вижу типичные макароны фортран-говнокода. Тьфу, тошно.
Здравствуйте, Максим, Вы писали:
ЕМ>>Фраза "за это отвечает код" подразумевает, что код использует необходимые механизмы, явно или неявно. М>Я никак не могу понять, что конкретно вы делаете для этого? Если это volatile, то это не синхронизация от слова совсем. Можете показать примерный код?
Ничего он не делает. У него чудом оно работает на х86.
Здравствуйте, Евгений Музыченко, Вы писали:
SaZ>>Можно явно указать стандарт в параметрах сборки. ЕМ>Я б с радостью, но VC++ не умеет ниже C++14.
Ну вот, программисты тоже устаревают безнадёжно...
ЕМ>Мне пока более всего интересно, в чем может заключаться фактическая нетривиальность конструктора и/или оператора присваивания, которые мог бы сгенерить компилятор по новому стандарту. Вы об этом что-нибудь знаете?
Тем, что volatile переменная должна записаться сколько положено раз, а не
быть просто присвоена оконечным результатом расчитанным чуть ли не в compile time.
С учётом ряда оптимизаций выполняемых компилятором для "нормальных" классов и функций
это выполнить сложно. RVO/NRVO (copy elision) оптимизации в частности невозможны.
Ситуация усугубляется тем, что компилятор после C++17 обязан делать copy elision.
fk0> Ничего он не делает. У него чудом оно работает на х86.
Тут дело не только в х86, но и в компиляторе от майкрософт. По ссылке от сигмы видно, что они интерпретируют volatile как условный atomic с Acquire/Release semantics, что приводит к неявной синхронизации
When the /volatile:ms compiler option is used—by default when architectures other than ARM are targeted—the compiler generates extra code to maintain ordering among references to volatile objects in addition to maintaining ordering to references to other global objects
Здравствуйте, fk0, Вы писали:
fk0>Volatile не является барьером. Не атомарно.
Мне это (внезапно) известно.
fk0>на x86 архитектуре всё сделано, чтоб подложить соломки индусским программистам
На x86 это было сделано в конце 80-х, задолго до появления феномена "индусского кода". И сделано в первую очередь для того, чтобы не ломать совместимость с уже существующим двоичным кодом.
