caxapa.ru :: Не было повода, а тут призадумался. Это чего, в Cortex M3 (и не только) если меняешь переменную в прерывании и вне его, надо прерывание запрещать? Т.е. атомарные операции (типа inc/dec memory) кроме bitband не возможны :(, манипуляции с памятью

Chum_A (14.01.2011 13:09, просмотров: 13120)

Не было повода, а тут призадумался. Это чего, в Cortex M3 (и не только) если меняешь переменную в прерывании и вне его, надо прерывание запрещать? Т.е. атомарные операции (типа inc/dec memory) кроме bitband не возможны :(, манипуляции с памятью только через регистры.

Ответить

- Не обязательно запрещать. Возьмите по ссылке книгу и прочитайте главу "10.6 Using exclusive access for semaphores". - vmp(14.01.2011 14:12, ссылка)
  - А при запрете прерываний для обеспечения атомарного доступа, получается, некоторые прерывания (во время этого самого доступа) можно упустить? - madfox(10.02.2011 15:37, )
    - Нет. Как только запрет на прерывания будет снят, сработают обработчики отложенных прерываний. - SciFi(10.02.2011 15:46)
      - Спасибо.А грамотнее выключать конкретное прерывание в регистрах управления контроллером прерываний (например, поле CLRENA в регистрах NVIC, cortex m3) или можно целиком отключаться прерывания? например __disable_irq(); (всё тот же cortex). - madfox(10.02.2011 16:21, )
        
        Спасибо за ответы\советы! - madfox(10.02.2011 17:16, )
        
        Зависит от задачи: SciFi(431 знак., 10.02.2011 16:56)
        
        грамотнее так строить алгоритм, чтобы прерывания вообще не запрещать - koyodza(10.02.2011 16:37)
  - Тут вот что, если работает вытесняющая ОС она рано или поздно переключит контекст, и да, встанем до разблокировки переменной. А если без ОС, то в прерывании встанем навсегда, разблокировать некому. "Или нет?" (с) - Chum_A(14.01.2011 14:27)
    - Без ОС - почему встанем? - Vladimir Ljaschko(14.01.2011 17:18)
      - Ну, заблокировал я доступ к переменной в main-е (к примеру), а тут прерывание. В прерывании смотрю - заблокировано, т.е. надо стоять до разблокировки, а кто разблокирует, если я не вышел из прерывания. Или я чего не догоняю? - Chum_A_(14.01.2011 18:27, )
        
        Зачем ждать в прерывании-то? О_о В прерывании ожидать чего-либо вообще несколько криминально. Функция, обслуживающая прерывание, должна выполняться как можно быстрее. В main-е нельзя блокировать переменную, изменяемую в прерывании. Именно по rezident(342 знак., 14.01.2011 18:56)
        
        Я вроде как не призывал ничего ждать в прерывании? Ещё раз, вопрос был такой: для MCCS-51 переменную volatile data u8 var я могу и в перерывании и вне него и во вложенном прерывании написать ++var/--var "без последствий", а вот для Chum_A_(79 знак., 14.01.2011 19:34, )
        
        это подходит только для inc/dec, и только байтовой переменной. С переменной большей разрядности, или с другими действиями над ней (напр +10 или -20) Ваш вариант не будет работать даже на MCS-51 - koyodza(10.02.2011 16:33)
        
        +1000 Цитирую себя: "...для MCS-51....data u8 var....++var/--var..." - Chum_A(10.02.2011 17:08)
        
        volatile не гарантирует атомарности, она выключает оптимизацию при доступе к переменной. Так что и в примере с MCS-51 прерывания в основном цикле придется запрещать. - il-2(31.01.2011 08:41)
        
        В данном случае volatile не (совсем) причём, причём заклинание data, к которому для ++var\--var сгенерятся команды inc var или dec var, а они атомарные. - Chum_A_(31.01.2011 10:04, )
        
        Это не кошерно. Гарантии никто не даёт: генерируемый код может измениться в новой версии компилятора и при иных изменениях. Но для любительской поделки прокатит. - SciFi(31.01.2011 10:11)
        
        Гарантию даёт система команд MCS-51 :) - Chum_A_(31.01.2011 10:15, )
        
        Случись что, к ней и будете посылать претензии :-) - SciFi(31.01.2011 10:23)
        
        Или я чего то не догоняю :))) Dir(123 знак., 14.01.2011 18:46)
        
        А вообще говоря, запрет прерывания для того и делается, чтобы атомарную операцию до конца довести. Возьми, например, простейшую операцию Dir(225 знак., 14.01.2011 18:52)
        
        в смысле неатомарную? - Argon(14.01.2011 19:19)
        
        В том смысле, чтобы какое то действие атомарным (неразрывным) сделать. Понятно же, что если, например, инкрементировать 0x00FF, то без запрета прерывания в main можно получить в прерывании 0x0000 вместо 0x0100 - Dir(14.01.2011 19:25)
        
        вот он! недостаток армов! :) даже такой примитив в кучу команд! для "некоторых других" ядер это действие атомарное. - Mahagam(14.01.2011 19:14)
        
        Да ладно, возьмем не short, а, например, long int. Все равно атомарности для всех операций не напасешься. - Dir(14.01.2011 19:18)
        
        На самом то деле проблема преувеличена. Действительно опасных ситуаций, которые вызывает неатомарность не так то и много. У меня в проектах - до десятка мест. - Vladimir Ljaschko(14.01.2011 20:54)
        
        Я тоже стараюсь запретом прерываний не злоупотреблять. Удается. Иногда вплоть до полного отсутствия этих запретов в некоторых проектах. Dir(297 знак., 14.01.2011 21:14 - 21:17)
        
        +100 :)! Как-то так: "Бросить курить легко, я и сам бросал много раз" (с) М.Твен - Chum_A_(14.01.2011 21:10, )
        
        :-) - Vit(14.01.2011 19:16, ссылка)
        
        Вначале с запретом прерываний разберемся. Перед неатомарной операцией запретил прерывание, после операции - разрешил. Прерывание произойдет на, допустим, 0, мкс позже. Какие проблемы? - Vladimir Ljaschko(14.01.2011 18:34)
        
        Нет проблем, хочу понять насколько правильно я понимаю систему команд :). - Chum_A_(14.01.2011 19:41, )
- чудес не бывает, ага. - Vladimir Ljaschko(14.01.2011 13:24)

ARM, RISC-V контроллеры