Библиотека атомарных операций для STM32 Опции

[ArtDenis]

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

Сообщение отредактировал ArtDenis - Jun 18 2015, 16:32

[ViKo]

Если бы эксклюзивные операции отслеживали только сами себя, толку от них было бы никакого. Так можно и обычным флагом обойтись, когда захотел - установил, когда надо - проверил... Смысл именно в том, что мониторится любое обращение к памяти (надо думать, запись). Типа, триггера. LDREX разрешает работу триггера, любая запись в память устанавливает его в 1, CLREX сбрасывает его. STREX проверяет триггер, и если он установлен, не пишет в память, и выдает 1 в регистр. И запрещает мониторинг (триггер).

[jcxz]

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

А зачем Вам мониторить все обращения? Ведь нужны только те обращения, которые могут использоваться для доступа к переменным синхронизации.
Если Вам нужна чтение-модификация-запись переменной синхронизации, или неатомарное чтение (несколькиим командами) этой переменной, или запись (любая) в эту переменную,
то извольте все эти операции выполнять только инструкциями LDREX/STREX. Тогда всё будет нормально и ставить этот бит по каждому обращению к памяти совсем излишне
(но конечно возможно для упрощения реализации ядра CPU).
А просто чтение этой-же переменной синхронизации можно делать и вообще одной командой LDR (которая априори атомарна) пусть даже она и попадёт между LDREX и STREX
выполняющимися в другом потоке - это никак не повлияет на результат.

В Cortex-M4 операция STREX даст отбой даже если в прерывании запись была сделана командой STR и совсем в другую ячейку памяти.

Вполне возможно для упрощения реализации механизма в ядре сделали срабатывание не только на эксклюзивный доступ.

[AlexandrY]

Вполне возможно для упрощения реализации механизма в ядре сделали срабатывание не только на эксклюзивный доступ.

С LDREX/STREX все еще более запутанней.

Решил тут протестировать как там насчет работы из разных областей памяти.
Выяснилось, что LDREX/STREX правильно работает когда переменные находятся в RAM вблизи 0x1000_0000-0x3000_0000
То, что кэширование разное сверху и снизу границы 0x2000_0000 никак не влияет, барьеры памяти можно не ставить.
А вот если использовать память которая находится после границы 0x4000_0000 , то пара LDREX/STREX там никакого эффекта не дает, хотя и исключений не вызывает.
Т.е. можно спокойно испортить переменную, а STREX ничего не покажет.

Ну и как положительный момент можно отметить, что выполнение кода из RAM на работу LDREX/STREX тоже не влияет.

А с DMA вопрос еще темный.
Мутный момент также с областями внешней памяти.

[jcxz]

Т.е. можно спокойно испортить переменную, а STREX ничего не покажет.

Вы портили при помощи другой STREX или просто STR? Если второе - эксперимент некорректный.
И надо посмотреть как классифицируется память находящаяся по этим адресам. Возможна это область памяти периферии, возможно с этим связано, лень заглядывать в карту памяти в описании М-ядра. :-)