| |
|
  |
 Библиотека атомарных операций для STM32 |
|
|
|
|
 Jun 22 2015, 04:01
|
Частый гость
Группа: Участник
Сообщений: 142
Регистрация: 10-11-12
Пользователь №: 74 318
|
Ковыряю std::atomic. Оказывается они работают для STM32 под GCC. Вот какой код генерируются при их использовании: Код ; std::atomic<unsigned> lalala;
; unsigned to_test = 20;
; ........
; lalala = 10;
8000a8a: f3bf 8f5f dmb sy
8000a8e: 4a0d ldr r2, [pc, #52]; (8000ac4 <main+0x3c>)
8000a90: 210a movs r1, #10
8000a92: 6011 str r1, [r2, #0]
8000a94: f3bf 8f5f dmb sy
; lalala.compare_exchange_strong(to_test, 10);
8000a98: 4b0b ldr r3, [pc, #44]; (8000ac8 <main+0x40>)
8000a9a: 681c ldr r4, [r3, #0]
8000a9c: f3bf 8f5f dmb sy
8000aa0: e852 0f00 ldrex r0, [r2]
8000aa4: 42a0 cmp r0, r4
8000aa6: d104 bne.n 8000ab2 <main+0x2a>
8000aa8: e842 1e00 strex lr, r1, [r2]
8000aac: f1be 0f00 cmp.w lr, #0
8000ab0: d1f6 bne.n 8000aa0 <main+0x18>
8000ab2: f3bf 8f5f dmb sy
8000ab6: bf18 it ne
8000ab8: 6018 strne r0, [r3, #0] В ассемблере армов разбираюсь плохо. Насколько всё хорошо/плохо в данном случае?
--------------------
|
|
|
|
|
|
|
|
Jun 22 2015, 13:53
|
Частый гость
Группа: Участник
Сообщений: 142
Регистрация: 10-11-12
Пользователь №: 74 318
|
Цитата(AlexandrY @ Jun 22 2015, 18:26)  Тему можно закрывать. Эксклюзивный монитор у Cortex-M4 всю память считает как одно целое. Значит атомная операция будет длится до тех пор пока все не перестанут пользоваться памятью. Т.е. возможно вечно !  А можно для тех кто в танке объяснить что это означает? И как обстоят дела у M3?
--------------------
|
|
|
|
|
|
|
|
Jun 22 2015, 18:40
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(ArtDenis @ Jun 22 2015, 18:53) А можно для тех кто в танке объяснить что это означает? И как обстоят дела у M3? Это означает, что любая запись в память в промежутке между LDREX и STREX приведёт к неудаче STREX и повтору попытки. Другими словами, если между LDREX и STREX возникнет прерывание, то попытку атомарного доступа почти наверняка придётся повторить, даже если обработчик прерывания не обращался к защищаемой переменной. Это происходит потому, что монитор отслеживает не обращение к конкретному адресу, а обращение к памяти вообще. Насчёт "возможно вечно" - это конечно гипербола, хотя при наличии, скажем, DMA, который непрерывно пишет в буфер в ОЗУ, проскочить будет довольно трудно. Надо, кстати, попробовать... ЗЫ. У M3 дела обстоят точно так же.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Jun 23 2015, 02:44
|
Гуру
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713
|
Цитата(AlexandrY @ Jun 22 2015, 19:26) Значит атомная операция будет длится до тех пор пока все не перестанут пользоваться памятью. Т.е. возможно вечно ! Расстояние между LDREX и STREX в моих функциях всего несколько тактов. С какой частотой у Вас в системе должны идти прерывания чтобы обеспечивалось 100% попадание между LDREX и STREX эксклюзивного доступа другого процесса? Цитата(AHTOXA @ Jun 23 2015, 00:40) Это означает, что любая запись в память в промежутке между LDREX и STREX приведёт к неудаче STREX и повтору попытки. Даташит на эту тему не читал, но с выскокой вероятностью могу предположить, что скорей всего не любая, а только эксклюзивная (LDREX/STREX). Цитата(AHTOXA @ Jun 23 2015, 00:40) Насчёт "возможно вечно" - это конечно гипербола, хотя при наличии, скажем, DMA, который непрерывно пишет в буфер в ОЗУ, проскочить будет довольно трудно. Ещё раз оговорюсь, что даташит не читал, но логика подсказывает, что DMA никак не будет влиять на LDREX/STREX, так как скорей всего не является эксклюзивным доступом (не нужно это для DMA).
|
|
|
|
|
|
|
|
Jun 23 2015, 05:01
|
фанат дивана
Группа: Свой
Сообщений: 3 387
Регистрация: 9-08-07
Из: Уфа
Пользователь №: 29 684
|
Цитата(jcxz @ Jun 23 2015, 07:44) Даташит на эту тему не читал, но с выскокой вероятностью могу предположить, что скорей всего не любая, а только эксклюзивная (LDREX/STREX). Да, так логичнее, но, когда я проводил эксперименты с LDREX/STREX, то, вроде бы, любое прерывание приводило к сбою STREX, вне зависимости от того, что было в обработчике этого прерывания. Хотя, я не углублялся, возможно, что-то было не так в условиях моего эксперимента. Посмотрим, что получится у ArtDenis.
--------------------
Если бы я знал, что такое электричество...
|
|
|
|
|
|
|
|
Jun 23 2015, 05:55
|
Универсальный солдатик
Группа: Модераторы
Сообщений: 8 634
Регистрация: 1-11-05
Из: Минск
Пользователь №: 10 362
|
Если бы эксклюзивные операции отслеживали только сами себя, толку от них было бы никакого. Так можно и обычным флагом обойтись, когда захотел - установил, когда надо - проверил... Смысл именно в том, что мониторится любое обращение к памяти (надо думать, запись). Типа, триггера. LDREX разрешает работу триггера, любая запись в память устанавливает его в 1, CLREX сбрасывает его. STREX проверяет триггер, и если он установлен, не пишет в память, и выдает 1 в регистр. И запрещает мониторинг (триггер).
|
|
|
|
|
|
|
|
Jun 23 2015, 06:45
|
Ally
Группа: Модераторы
Сообщений: 6 232
Регистрация: 19-01-05
Пользователь №: 2 050
|
Цитата(ViKo @ Jun 23 2015, 08:55) Если бы эксклюзивные операции отслеживали только сами себя, толку от них было бы никакого. Так можно и обычным флагом обойтись, когда захотел - установил, когда надо - проверил... Смысл именно в том, что мониторится любое обращение к памяти (надо думать, запись). Типа, триггера. LDREX разрешает работу триггера, любая запись в память устанавливает его в 1, CLREX сбрасывает его. STREX проверяет триггер, и если он установлен, не пишет в память, и выдает 1 в регистр. И запрещает мониторинг (триггер). Да, это проверенно. В Cortex-M4 операция STREX даст отбой даже если в прерывании запись была сделана командой STR и совсем в другую ячейку памяти.
|
|
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
