Chum_A (14.01.2011 14:27, просмотров: 87) ответил vmp на Не обязательно запрещать. Возьмите по ссылке книгу и прочитайте главу "10.6 Using exclusive access for semaphores".-
- Без ОС - почему встанем? - 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)
- Гарантию даёт система команд MCS-51 :) - Chum_A_(31.01.2011 10:15,
- Это не кошерно. Гарантии никто не даёт: генерируемый код может измениться в новой версии компилятора и при иных изменениях. Но для любительской поделки прокатит. - SciFi(31.01.2011 10:11)
- В данном случае volatile не (совсем) причём, причём заклинание data, к которому для ++var\--var сгенерятся команды inc var или dec var, а они атомарные. - Chum_A_(31.01.2011 10:04,
- это подходит только для inc/dec, и только байтовой переменной. С переменной большей разрядности, или с другими действиями над ней (напр +10 или -20) Ваш вариант не будет работать даже на MCS-51 - koyodza(10.02.2011 16:33)
- Я вроде как не призывал ничего ждать в прерывании? Ещё раз, вопрос был такой: для MCCS-51 переменную volatile data u8 var я могу и в перерывании и вне него и во вложенном прерывании написать ++var/--var "без последствий", а вот для Chum_A_(79 знак., 14.01.2011 19:34,
- Или я чего то не догоняю :))) Dir(123 знак., 14.01.2011 18:46)
- А вообще говоря, запрет прерывания для того и делается, чтобы атомарную операцию до конца довести. Возьми, например, простейшую операцию Dir(225 знак., 14.01.2011 18:52)
- в смысле неатомарную? - Argon(14.01.2011 19:19)
- вот он! недостаток армов! :) даже такой примитив в кучу команд! для "некоторых других" ядер это действие атомарное. - 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, )
- На самом то деле проблема преувеличена. Действительно опасных ситуаций, которые вызывает неатомарность не так то и много. У меня в проектах - до десятка мест. - Vladimir Ljaschko(14.01.2011 20:54)
- :-) - Vit(14.01.2011 19:16, ссылка)
- Да ладно, возьмем не short, а, например, long int. Все равно атомарности для всех операций не напасешься. - Dir(14.01.2011 19:18)
- А вообще говоря, запрет прерывания для того и делается, чтобы атомарную операцию до конца довести. Возьми, например, простейшую операцию Dir(225 знак., 14.01.2011 18:52)
- Вначале с запретом прерываний разберемся. Перед неатомарной операцией запретил прерывание, после операции - разрешил. Прерывание произойдет на, допустим, 0, мкс позже. Какие проблемы? - Vladimir Ljaschko(14.01.2011 18:34)
- Нет проблем, хочу понять насколько правильно я понимаю систему команд :). - Chum_A_(14.01.2011 19:41, )
- Нет проблем, хочу понять насколько правильно я понимаю систему команд :). - Chum_A_(14.01.2011 19:41,
- Зачем ждать в прерывании-то? О_о В прерывании ожидать чего-либо вообще несколько криминально. Функция, обслуживающая прерывание, должна выполняться как можно быстрее. В main-е нельзя блокировать переменную, изменяемую в прерывании. Именно по rezident(342 знак., 14.01.2011 18:56)
- Ну, заблокировал я доступ к переменной в main-е (к примеру), а тут прерывание. В прерывании смотрю - заблокировано, т.е. надо стоять до разблокировки, а кто разблокирует, если я не вышел из прерывания. Или я чего не догоняю? - Chum_A_(14.01.2011 18:27,
- Без ОС - почему встанем? - Vladimir Ljaschko(14.01.2011 17:18)