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

Сообщение отредактировал _Pasha - Oct 5 2015, 13:38

Да вроде понятно всЁ. Ну я например работаю непосредственно с глобальными и вроде все работает (блокирую прерывание непосредственно перед сравнением двух глобальных переменных).
С копированием получается наглядней в том смысле что имеем только 2 места где нужно ставить блокировку прерывания, и к локальной переменной можно обращаться сколько угодно раз. Я правильно понимаю идею?


Проверил- и действительно: добавил спецификатор памяти в объявление указателя и всё лишнее в коде исчезло. Вот оно как оказывается, Михалыч (с) Спасибо за информацию, Сергей!


Понял идею, но это ведь можно провернуть не только с указателем, но и с любой переменной?
Добавлено: попробовал Вашу функцию, вроде работает, только выдает предупреждение

Не только в сравнении дело.
Я не понимаю что значит "заменить на глобальные". Если просто тупо подменить в моих функциях все использования локальных на соответствующие им глобальные - работать не будет.

Загадка ...

В предположении, что read() не вызывается и rpos не модифицируется в прерывании:

Не будет работать??

Преимущество - не надо городить критические секции.

Ну я как бы тоже "из головы" писал, не с реального примера. У меня не случались неатомарные чтения по указателю. Мог и что-то упустить.

Да нет все ок, разобрался
Заменил

на

и ашИпка ушла

И что такого страшного в критических секциях????

Вариант с так называемым "nonatomic" по-русски называется костыль. Если есть проблемы с атомарным доступом к индексам кольцевого буфера - нужно задуматься о разделении доступа к самому буферу через флаг с атомарным доступом. Вы слабо описали задачу, т.к. совершенно непонятно где именно мешает атомарность.

Задумался... получил замену атомарной работы с указателями на замену работы с атомарным флагом и добавление самого флага
На самом деле атомарная работа с флагами может быть еще более гнусной вещью. У заметного количества контроллеров работа с модификацией памяти категорически не атомарная .
И при попытке изменить флаг, который меняется и в прерывании наступает &*%&^*%

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

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

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

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

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

Читать и сравнивать целиком 2-байтовый указатель - неоптимально. Можно прочитать старший байт, затем младший, затем снова старший, и если он не изменился, значит, 2-байтовое число верное.