используешь свои данные по назначению?
Не соглашусь. Вопрос был лишь в том, какие варианты кроме volatile и отключений прерываний возможны.
а волатиле тут не причем в твоем случае
Почему? Обычно если посмотреть на плохой код, он весь увешан volatile именно из-за этого
Порой без нее никак, ибо оно и константой может стать
нет из за этого, у тебя задача же обеспечения челостности данных на момент записи чтения
Интересные критерии определения плохого кода. А можно все критерии узнать, я бы записал и повесил бы на стену
Volatile разе это не позволяет гарантировать параллельно то, что данные полностью считаются, не а не изменившись на половину? Во всяком случае это везде так пишут
волотайл не поможет при изменении части бит в разных местах. ибо это уже гонка данных. Волотайл про то что переменная асинхронная по отношению к коду. тобишь она меняется где-то (где не важно) и компилятор каждый раз должен ее вычитывать из памяти (тобишь ему запрещено ее кэшировать или оптимизировать ее в работе) тобишь при двух записях будет две записи!. Тогда как у тебя банальная гонка - тут нужна либо критическая секция. либо атомик. для арма это эксклюзивный монитор смотри операции с LDREX и т.п, как выше сказали если нет атомиков то можно выкл/вкл прерывания
Ну чем не критерий писать везде volatile не давая многие куски кода оптимизировать?
это поможет разве что для целостности простых типов, дата рейсы волатилом не победишь, критические секции, мьютексы, атомики - вот туда копай
Я это и имел в виду, наверное, надо было мне точнее выразиться
Я об этом и говорил, меня интерисовало именно то, чтобы переменная целостно считалась и не важно на сколько актуально на момент исполнения
ну чтение будет одно ок. потом будет модификация + сохранения. и если между ними будет другое прерывание которое будет тоже менять эту переменную то мы получили тыкву.! если есть гонка данных то волотайл не поможет! Волотайл про другое!
Но у меня же переменная стандартного типа данных неразрывно будет считана и записана. Конкретно в этом кейсе не важно, изменит её потом другое прерывание в процессе исполнения кода или нет. Гонка данных, на сколько я понимаю, ситуация когда мы хотим работать с одним участком памяти одновременно. Волатайл же тупо говорит, что если мы используем какую-то переменную с этим модификатор ом, то мы просто её по новой берём, а не используем промежуточное значения. Если вы думаете, что я не понимаю, что я не понимаю, что переменная val в этом коде может в любой момент измениться, то я это понимаю. И понимаю, что volatile не позволит мне гарантировать равенство v и v3 int v = val; inv v3 = val;
Так у вас как я понял такой кейс, что в переменной что-то меняется побитно так?
Просто чтобы небыло такой ситуации когда int a = val; И при этом первая половина бит равна старому значению, а вторая новому значению.
если есть ассинхронная работа с переменной! то волотайл не поможет - он не может помочь при гонке данных. ситуация код: val |= CTRL_POWER_ON будет три операции mov из памяти or установка бита mov в память если после or произойдет прерывание и там будет банально val |= bla bla то после того как мы вернемся и сделаем mov в память. наши bla bla биты потеряны!
Очень хороший пример, спасибо, к счастью дважды менять пока мне не надо, но буду держать это в голове, про такую ситуацию я не думал. Мне просто читать не криво было нужно. А можно в догонку тогда такой вопрос. Если мне надо просто получать +- актуальное значение переменной, которая может измениться в прерывании, использую функцию типа int get() {return val;} Без volatile так же я могу вернуть ерунду?
https://pastebin.com/JVyTgLxw
ну в коде выше заменишь на свои функции запрета/разрешения прерываний. Соответвенно пишешь и читаешь из "общих" переменных через соответсвующие функции
О, спасибо, я что-то не подумал про то, чтобы подобную функцию накидать. Компактно получается
нет волотайл это штука. которая говорит компилятору что переменная меняется осинхронно по отношению к тому коду который видишь ты. Это либо в прерывании. либо это вообще часть железа и т.п это значит компилятор видя это дело понимает, что когда я читаю переменную я должен сделать чтение из памяти. когда записываю сделать запись. Все на этом все. прям все и точка. Теперь примеры зачем и где это нужно. 1. скажем есть переменная terminated есть код аля while(!terminated) {} скажем значение этой переменной меняется в прерывании кнопки. юзер нажал мы мол = 1. Так вот если переменная не волотильная, то компилятор видя код с while может сделать так: читаем переменную в регистр. проверяем ... и получается что мы всегда (вечно) будет проверять значение регистра который закешировал значение переменной. и даже когда нажали кнопку и реальная переменная давно уже == 1. мы в нашем коде с while как читали 0 из регистра так и читаем. если мы говорим что чувак переменная волотильная. то будь добр при обращении вычитай ее еще раз. и да каждый раз делай это... второй пример. аналогичный с таймером. есть некий cnt который ++ в прерывании таймера. и код который мол while(cnt < 1000) nop ситуация аналогичная счетчик уже убежал а мы об этом не знаем. ибо компилятор оптимизировал цикл... пример три: есть железный регистр CTRL_UART, в датошите написано установить скорость. а потом устновить битк поехали если мы напишем код типа: CTRL_UART |= (bdr57600); CTRL_UART |= UART_START; компилятор видя это думает ну этож можно оптимизировать как одну запись (НО это нарушает требование датошита) если мы скажем что это волотайл. компилятор такой ок две записи значит две записи без вопросов. PS. Волотайл это отключение вот таких вот оптимизаций для переменной не больше не меньше.
при работе с обычной переменной компилятор может убирать некоторые инструкции, несколько инструкций превратить в одну, т.к. ему кажется что в данном участке кода это допустимо. указам volalile ты принудительно сообщаешь, что все операции с этой переменной оптимизировать нельзя, как бы там ему не казалось, ведь компилятор не может знать что какая-то переменная может быть изменена в прерывании
volatile лишь гарантирует, что оптимизатор не выкинет доступ к переменной вообще.
Сохранил в мемориз. Мне как раз Джуна предстоит скоро натаскивать
Обсуждают сегодня