| |
|
  |
 Требуется совет по выбору RTOS, программист я хреновый |
|
|
|
|
 Apr 18 2006, 19:16
|
Местный
Группа: Свой
Сообщений: 337
Регистрация: 1-02-06
Пользователь №: 13 874
|
Созревает проект на LPC213x. Сюдя по всему конечным автоматом на таймере обойтись не получится ввиду большого числа событий и источников прерываний. Это на мой профанский взгляд. Да и надо наконец научиться писать с использованием RTOS. В связи с чем просьба к общественности посоветовать ПРОСТУЮ RTOS. И не просто посоветовать, а подсказать где ее взять. В принципе и купить можно, но сначала хотелось бы пощупать. Главное чтобы софт был качественно задокументирован, а то в С++ я как свинья в апельсинах, разбираться с исходниками не буду да и не смогу наверное. Мне бы на пальцах показать, как создать тред и исполнить в нем мой код. Соответственно хотелось бы иметь готовый порт на мой процик. Вытесняющая она должна быть или невытесняющая, еще не понял. Чтобы это понять, желательно Ваши примеры задач, для которых то или иное больше подходит.
Также просьба не отвечать вроде "да на хрена тебе ртос", "атмел sam7 рулит" и "ваще надо на асме писать"
С уважением, я
--------------------
"А я все помню, я был не пьяный!.." (С)Владимир Семенович
|
|
|
|
|
|
|
|
Apr 18 2006, 20:58
|
Профессионал
Группа: Свой
Сообщений: 1 065
Регистрация: 8-10-05
Из: Kiev, UA
Пользователь №: 9 380
|
Цитата На сайте можно взять готовые шаблоны проектов для LPC. А так же роскошное руководство. uCOS-II - первая мысль возникающая по прочтении вашего поста. В принципе можно посмотреть также FreeRTOS, тоже неплохо описана и на LPC вроде уже портирована.
Сообщение отредактировал beer_warrior - Apr 18 2006, 20:58
--------------------
Вони шукають те, чого нема,
Щоб довести, що його не існує.
|
|
|
|
|
|
|
|
Apr 19 2006, 04:47
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 17-01-05
Пользователь №: 1 995
|
Цитата(dch @ Apr 19 2006, 02:29)  eCos тоже хвалят У LPC213x для eCOS оперативной памяти маловато будет. Да трудно будет недостаточно опытному человеку разобраться в коде eCOS, который написан со всеми наворотами С++ как-то: шаблоны, исключительные ситуации и их обработка. По теме. 1. FreeRTOS. Адрес - http://www.freertos.org . Сам не использовал, но порт для семейства LPC вроде бы существует. Исходники открыты. 2. embOS. Адрес - http://www.segger.de . Использовал сам при работе с микронтролерами Fujitsu F2MC. Впечатления очень приятные. Исходники недоступны. На сайте выложена библиотека для нескольких компиляторов под ARM. Есть ли среди них LPC213x - не знаю. У библиотеки есть ограничение - приложение может создать не более 3-х задач, но это достаточно легко обходится.
|
|
|
|
|
|
|
|
Apr 19 2006, 09:22
|
Группа: Новичок
Сообщений: 10
Регистрация: 4-02-05
Пользователь №: 2 416
|
|
|
|
|
|
|
|
|
Apr 19 2006, 09:31
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 17-01-05
Пользователь №: 1 995
|
Цитата(DASM @ Apr 19 2006, 09:11) а embOS от UCOS вообще отличается ? В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры.
|
|
|
|
|
|
|
|
Apr 19 2006, 11:54
|
Народный чинитель
Группа: Участник
Сообщений: 415
Регистрация: 15-07-05
Пользователь №: 6 811
|
Цитата 64 задачи. Начиная с версии 2.80 255!!!
Сообщение отредактировал jasper - Apr 19 2006, 11:56
|
|
|
|
|
|
|
|
Apr 19 2006, 12:06
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Цитата(jasper @ Apr 19 2006, 17:54) Цитата 64 задачи. Начиная с версии 2.80 255!!! В тех приложениях, где ucos целесообразно исполльзовать, и 64 много. В 255 сделали - имхо выпендриваются просто, типа нужно показать, что ось как-то развивается.
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 19 2006, 12:18
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Цитата(alogvinov @ Apr 19 2006, 15:31) Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры. что имеется ввиду?
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 20 2006, 02:52
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Цитата(Evgeny_CD @ Apr 20 2006, 02:02) Цитата(Electrovoicer @ Apr 19 2006, 16:53) кстати а программу для мониторинга висящих задач/загрузки из под виндовс где бы взять? вроде микриум ее не дает так просто... и как эта фича связана с C-SPY и что это такое? uC-VIEW, качайте http://rapidshare.de/files/18434373/uCOS-V...-V110.ZIP_.htmlНа ftp оно есть, но самого ftp пока нет. А интересно его кто пользовал? Помогает хоть как-то? Или так - веселые картинки? А то я вроде сначала хотел, а потом лень стало поднимать.
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 20 2006, 04:30
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 17-01-05
Пользователь №: 1 995
|
Цитата(DASM @ Apr 19 2006, 13:54) мужики, вы правда зря Nucleus игнорируете.. неплохая оська то.. Mentor... Accelated Technology/..знакомые слова - не так ли ? При этом скажу я вам - сурцы очень поняты, на чистом С, хорошая дока... А теперь сравним - какой-то Лябросс.. какая-то полудохлая оська, где все задачи надо с разным приоритетом... Проблема в том, что саму Nucleus найти проблема. Ссылки на uCos же есть на любом сайте соответствующей тематики. Инерцию мышления со счетов тоже сбрасывать не стоит.
|
|
|
|
|
|
|
|
Apr 20 2006, 05:13
|
Народный чинитель
Группа: Участник
Сообщений: 415
Регистрация: 15-07-05
Пользователь №: 6 811
|
Цитата и все же что такое C-SPY? Так называется дебугер входящий в комлект IARовского компилятора.
|
|
|
|
|
|
|
|
Apr 20 2006, 05:26
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 17-01-05
Пользователь №: 1 995
|
Цитата(Andy Mozzhevilov @ Apr 19 2006, 16:18) Цитата(alogvinov @ Apr 19 2006, 15:31) Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры. что имеется ввиду? Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС. Таймеров таких может быть произвольное количество. Его можно запустить, остановить, перезапустить, удалить. Я начал использовать этот механизм в embOS. Мне понравилось.
|
|
|
|
|
|
|
|
Apr 20 2006, 06:24
|
Гуру
Группа: Свой
Сообщений: 3 644
Регистрация: 28-05-05
Пользователь №: 5 493
|
Цитата(alogvinov @ Apr 20 2006, 09:26) Цитата(Andy Mozzhevilov @ Apr 19 2006, 16:18) Цитата(alogvinov @ Apr 19 2006, 15:31) Цитата(DASM @ Apr 19 2006, 09:11)
а embOS от UCOS вообще отличается ?
В общем-то одного поля ягоды. Вот только в uCos напрочь отсутствуют программные таймеры. что имеется ввиду? Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС. Таймеров таких может быть произвольное количество. Его можно запустить, остановить, перезапустить, удалить. Я начал использовать этот механизм в embOS. Мне понравилось. Гы, я в свое время (да и сейчас часто) собственно всю систему и строю без оси. Некое подобие кооперативки выходит. Вобщем-то неплохо имхо, только задачки простые надо - там клапан включить, кнопку опросить и т п....
|
|
|
|
|
|
|
|
Apr 20 2006, 09:36
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 19 2006, 21:27) Цитата(sensor_ua @ Apr 19 2006, 13:14)
А вот FreeRTOS после анализа этих самых критических кусочков пришлось забраковать.
??? Что такое жуткое вскрылось при анализе? Сразу оговорюсь, что сам не программист, потому прошу сильно не пинать. В TNKernel наблюдаю int tn_cpu_save_sr(void); void tn_cpu_restore_sr(int sr); #define tn_disable_interrupt() tn_save_status_reg = tn_cpu_save_sr() #define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg) Во FreeRTOS /* The code generated by the Keil compiler does not maintain separate stack and frame pointers. The portENTER_CRITICAL macro cannot therefore use the stack as per other ports. Instead a variable is used to keep track of the critical section nesting. This necessitates the use of a function in place of the macro. */ void vPortEnterCritical( void ){...} void vPortExitCritical( void ){...} В uCOS-II, IMHO, подобное называлось уровнем (паранойи?  )) то ли 1, то ли 2, а теперь прописано, что пользуют уровень 3 - практически то же по асму, что и в предпоследней TNKernel (в последней заменили (в tn_cpu_save_sr() и tn_cpu_restore_sr(..)) bx, lr на mov pc,lr Мне решение в TNKernel и uCOS-II кажется обоснованным и разумным.
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 20 2006, 10:15
|
Участник
Группа: Участник
Сообщений: 30
Регистрация: 17-01-05
Пользователь №: 1 995
|
Цитата(dxp @ Apr 20 2006, 10:30) Цитата(alogvinov @ Apr 20 2006, 12:26)
Под программым таймером подразумевается структура, одним из полей которой является указатель на функцию. Эта функция вызывается через заданное пользователем число квантов ОС.
И на каком уровне эта функция реально вызывается - на уровне прерываний или на уровне задач? Если на уровне задач, то в контексте какой задачи она выполняется (в чьем стеке работает)? Функция выполняется в контексте прерывания, со всеми вытекающими отсюда ограничениями.
|
|
|
|
|
|
|
|
Apr 20 2006, 16:44
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(sensor_ua @ Apr 20 2006, 12:36) В TNKernel наблюдаю
int tn_cpu_save_sr(void);
void tn_cpu_restore_sr(int sr);
#define tn_disable_interrupt() tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg)
Во FreeRTOS
void vPortEnterCritical( void ){...}
void vPortExitCritical( void ){...}
Мне решение в TNKernel и uCOS-II кажется обоснованным и разумным. Цитата В TNKernel и uCOS-II сохраняется регистр статуса и это видно по коду, а во FreeRTOS эти функции void. Может оно там тоже как-то сохраняется, но я не смог увидеть куда Самый странный критерий выбора операционной системы, какой я только встречал на данный момент. Или я чего-то не понял :-( В TNKernel много чего хорошего, но реализация ограждения критических секций более чем спорная. Для сохрания состояния используется персональная поименованная переменная и за этим необходимо следить глазами и руками. Не дай бог вам пару раз подряд вызвать tn_cpu_save_sr() с сохранением в одну и ту-же переменную. А макросами tn_disable_interrupt() и tn_enable_interrupt() вообще находясь в здравом уме и твердой памяти пользоваться нельзя, ибо при вложенном вызове их критической секции еще одной критической секции кирдык в виде запрещенных навсегда прерываний наступит незамедлительно. Несимметричное количество вызовов тоже черевано. Теперь о FreeRTOS: void vPortEnterCritical() void vPortExitCritical() Имеют исходники. Они просты, как лом, откомментированы, и так-же надежно работают. Код void vPortEnterCritical( void )
{
/* Disable interrupts first! */
__disable_interrupt();
/* Now interrupts are disabled ulCriticalNesting can be accessed
directly. Increment ulCriticalNesting to keep a count of how many times
portENTER_CRITICAL() has been called. */
ulCriticalNesting++;
}
void vPortExitCritical( void )
{
if( ulCriticalNesting > portNO_CRITICAL_NESTING )
{
/* Decrement the nesting count as we are leaving a critical section. */
ulCriticalNesting--;
/* If the nesting level has reached zero then interrupts should be
re-enabled. */
if( ulCriticalNesting == portNO_CRITICAL_NESTING )
{
__enable_interrupt();
}
}
} При входе прерывания безусловно запрещаются и наращивается обезличеный счетчик запретов. При выходе разрешаются если счетчик запретов равен 0. Никаких проблем с реализацией вложений. Хранения состояния не нужно, переменная для блокировок всего одна.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 20 2006, 17:50
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Специально скачал последнюю FreeRTOS 4.0.1, а то рассматривал 3.2.4, а там то, что теперь прозрачно, было написано асмовыми вставками - мне такое было тяжело читать Насчет Цитата Для сохрания состояния используется персональная поименованная переменная Ваши замечания мне пришлось учесть (немного раньше, чем сегодня - макросы модифицировать открывающими/закрывающими фигурными скобками, побороться с "персональностью" переменной, соответственно ввести Цитата обезличеный счетчик запретов Параноидальные требования возникли от безысходности - пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо. Пришлось положить избыточность в 500% в ресурсы железа(может больше - меги128 без внешнего ОЗУ на частоте 3.68МГц хватало) и... А насчет Цитата просты, как лом, откомментированы, и так-же надежно работают ещё раз скажу - в uCOS-II такой вариант имелся как самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться.
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 20 2006, 18:54
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(sensor_ua @ Apr 20 2006, 20:50) самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться. Ну а причины отказа? Я теряюсь в догадках! Цитата Специально скачал последнюю FreeRTOS 4.0.1, а то рассматривал 3.2.4, а там то, что теперь прозрачно, было написано асмовыми вставками - мне такое было тяжело читать А аналогичный по назначению ASM код TNKernel 'легко'??? Да и где там ASM удалось углядеть? Там такой 'С' код испокон веку, я даже сам себе не поверил и заклянул в 3.2.3..... Все сказанное Вами по отношению к TNKernel прямо противоречит написанному вами-же: Цитата пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо. Я бы понял, если Вы заговорили-бы об некоторой времени в асмописаных обрамителях критических секций и чем-то подобном. Но то, что написано НЕ ВЯЖЕТСЯ с АККУРАТНО написанной, но более НЕЖНОЙ в использовании, да и менее обкатанной NTKernel. Практически по тем-же причинам (постороние писатели прикладных программ произвольной квалификации) мною был сделан прямо противоположный вывод.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 20 2006, 19:04
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 20 2006, 21:54) Цитата(sensor_ua @ Apr 20 2006, 20:50)
самый низкий уровень паранойи - он понятен, имеет свои плюсы, но от него постарались отказаться.
Ну а причины отказа? Я теряюсь в догадках! Вот выдранное из os_cpu.h /* ******************************************************************************** ************************* * ARM * * Method #1: Disable/Enable interrupts using simple instructions. After critical section, interrupts * will be enabled even if they were disabled before entering the critical section. * NOT IMPLEMENTED * * Method #2: Disable/Enable interrupts by preserving the state of interrupts. In other words, if * interrupts were disabled before entering the critical section, they will be disabled when * leaving the critical section. * NOT IMPLEMENTED * * Method #3: Disable/Enable interrupts by preserving the state of interrupts. Generally speaking you * would store the state of the interrupt disable flag in the local variable 'cpu_sr' and then * disable interrupts. 'cpu_sr' is allocated in all of uC/OS-II's functions that need to * disable interrupts. You would restore the interrupt disable state by copying back 'cpu_sr' * into the CPU's status register. ******************************************************************************** ************************* */ Цитата Специально скачал последнюю FreeRTOS 4.0.1, а то рассматривал 3.2.4, а там то, что теперь прозрачно, было написано асмовыми вставками - мне такое было тяжело читать А аналогичный по назначению ASM код TNKernel 'легко'??? Да, без переводчика и без проблем. Все сказанное Вами по отношению к TNKernel прямо противоречит написанному вами-же: Цитата пишу дрова (в широком смысле - зачатки ОСи тоже) для имеющихся программистов - ребята попались с большими амбициями, непредсказуемым стилем программирования и тяжелым наследием незнания железа (непочитания дейташитов) - я завидую белой завистью их пофигизму, но работу делать надо. Я бы понял, если Вы заговорили-бы об некоторой времени в асмописаных обрамителях критических секций и чем-то подобном. Но то, что написано НЕ ВЯЖЕТСЯ с АККУРАТНО написанной, но более НЕЖНОЙ в использовании, да и менее обкатанной NTKernel. Практически по тем-же причинам (постороние писатели прикладных программ произвольной квалификации) мною был сделан прямо противоположный вывод. Если насчёт TNKernel применить вааще, то задача не применить ОС, а именно не дать этого увидеть )) товаришчам
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 20 2006, 20:12
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 20 2006, 22:28) Цитата(sensor_ua @ Apr 20 2006, 22:04)
Ну а причины отказа? Я теряюсь в догадках!
Вот выдранное из os_cpu.h
/*
.....
*/
Если о 'параное', но 'наивысший уровень' в TNKernel реализован сложнее и ненадежнее, нежели в той-же FreeRTOS. Вот такие дела. Простое запрещение прерываний вообще никому не запрещено пременять с умом, естественно. Насчет "сложнее и ненадежнее", то интересны аргументы. Если только "персональность" переменной для хранения статуса, то уже обсуждали. А насчет "Простое запрещение прерываний" хотелось бы отклониться в сторону - например, вспомнить spurious interrupt - AN10414 от Philips - ИМХО, это вообще сложный вопрос, и его действительно нужно решать "с умом, естественно".
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 20 2006, 20:51
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(sensor_ua @ Apr 20 2006, 23:12) Насчет "сложнее и ненадежнее", то интересны аргументы. Если только "персональность" переменной для хранения статуса, то уже обсуждали. Еще раз повторить? 1. Сложнее - вместо простейшей обертки над стандартной де-факто библиотечной функции гарантированно работающей на любом процессоре. Писанная на асме чисто армовсая, да еще с заточкой под ARM Mode 2. Ненадежнее - легко ошибиться (особенно не зная потрохов и соответствено границ применимости) при использовании вложеных критических секций. Про macros писал - ну просто подстава чистейшей воды. Практически использование недалеко ушло от аккуратного использования пресловутого запрещения прерывания. Цитата А насчет "Простое запрещение прерываний" хотелось бы отклониться в сторону А ненадо отклоняться, ибо все равно оно имеет место быть. Это TNKernel: Код tn_cpu_save_sr:
mrs r0,CPSR
orr r1,r0,#NOINT
msr CPSR_c,r1
;-- Atmel add-on
mrs r1,CPSR ;-- Check CPSR for correct contents
and r1,r1,#NOINT
cmp r1,#NOINT
bne tn_cpu_save_sr ;-- Not disabled - loop to try again
;--------
bx lr Это кусок IARовской библиотеки: Код cfi_ARM_BLOCK_start disableInterrupt_a
CODE32
??DiI_a
mrs r12,CPSR
orr r12,r12,#0xC0
msr CPSR_c,r12
mrs r12,CPSR
ands r12,r12,#+0xC0
beq ??DiI_a
bx lr
cfi_ARM_BLOCK_end disableInterrupt_a Как Вам разница?
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 05:42
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(zltigo @ Apr 20 2006, 23:44) Теперь о FreeRTOS: void vPortEnterCritical() void vPortExitCritical() Имеют исходники. Они просты, как лом, откомментированы, и так-же надежно работают. Код void vPortEnterCritical( void )
{
/* Disable interrupts first! */
[...skipped...]
}
} При входе прерывания безусловно запрещаются и наращивается обезличеный счетчик запретов. При выходе разрешаются если счетчик запретов равен 0. Никаких проблем с реализацией вложений. Хранения состояния не нужно, переменная для блокировок всего одна. А зачем такие навороты с подсчетом входов, анализом их при выходе и т.д.? Тут, насколько я понимаю: во-первых, прилично кода - накладные расходы, т.е. во-вторых, а если при первом вызове прерывания были по какой-то причине запрещены? Ведь при выходе они будут разрешены, что есть нарушение логики работы программы. Почему бы не использовать простую схему (псевдокод): Код CritEnter()
{
SaveInterruptState();
DisableInterrupt();
}
CritExit()
{
RestoreInterruptState();
} Все, ничего подсчитывать и анализировать не надо и логическая целостность программы не нарушается. Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функиций, но это надо делать при любом подходе. На С, к сожалению, это приходится делать руками, тут ничего не поделать. К счастью, на С++ этот момент поддается автоматизации, поэтому использование критических секций там тривиально и совершенно безопасно. :-)
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Apr 21 2006, 06:20
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(dxp @ Apr 21 2006, 08:42) А зачем такие навороты с подсчетом входов, анализом их при выходе и т.д.? -Ну про 'навороты' это уж перебор :-) -Безболезненная вложенность. -При использовании этого механизма без левых запретов прерывания будет отсутствовать это: Цитата во-вторых, а если при первом вызове прерывания были по какой-то причине запрещены? Ведь при выходе они будут разрешены, что есть нарушение логики работы программы. Цитата прилично кода - накладные расходы, т.е. Одного порядка, на самом деле, в FreeRTOS случае дополнительная работа со счетчиком в памяти, в варианте "с сохранением" тоже работа с памятью - считать-запомнить-прочитать-записать. Цитата Почему бы не использовать простую схему (псевдокод):
....
Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функций, но это надо делать при любом подходе. -Увы, не единственное, вроде уже распинался :-(. - в варианте "со счетчиком" комплементарность можно слегка нарушить :-) лишними вызовами конца критической секции. Цитата(DASM @ Apr 21 2006, 08:46) объясните неразумному, почему EnterCriticalSection у вас ассоцируется с запретом прерываний ? Мне это как-то неочевидно.. У меня не ассоциируется, просто здесь речь идет о двух реалиациях оных в двух конкретных системах, которые обе базируются на таком решении. Обсуждаются отличия, причем автором во главу угла была поставлена (если я правильно все это понимаю) мнимая большая дуракоустойчивость TNKernel в сравнении c FreeRTOS.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 06:26
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Цитата(DASM @ Apr 21 2006, 12:01) а мне всегда казалось, что назначение критических секций - это не допустить одновременного использования одного расшаренного ресурса разными потоками...... Нет, этот сервис предоставляется семафорами. Цитата Про прерывания течения кода как-то читать не доводилось... Где я могу просветить свою темноту ? Да хоть не любимого тобой Лябрусса  , книгу по uCOS
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 21 2006, 06:51
|
Гуру
Группа: Свой
Сообщений: 3 644
Регистрация: 28-05-05
Пользователь №: 5 493
|
Извините за ошибки распознования текста finereader -ом
Семафоры
Объекты ядра «семафор» используются для учета ресурсов. Как и все объекты ядра они содержат счетчик числа пользователей, но, кроме того, поддерживают два 32-битных значения со знаком: одно определяет максимальное число ресурсов (контролируемое семафором), другое используется как счетчик текущего числа ресурсов.
Мьютексы
Объекты ядра «мьютексы» гарантируют потокам взаимоисключающий доступ к единственному ресурсу. Отсюда и произошло название этих объектов (mutual exclusion, mutex). Они содержат счетчик числа пользователей, счетчик рекурсии и переменную', в которой запоминается идентификатор потока. Мьютексы ведут себя точно так же, как и критические секции. Однако, если последние являются объектами пользовательского режима, то мьютексы — объектами ядра. Кроме того, единственный объект-мью-текс позволяет синхронизировать доступ к ресурсу нескольких потоков из разных процессов; при этом можно задать максимальное время ожидания доступа к ресурсу.
Критические секции
Критическая секция (critical section) — это небольшой участок кода, требующий монопольного доступа к каким-то общим данным. Она позволяет сделать так, чтобы единовременно только один поток получал доступ к определенному ресурсу. Естественно, система может в любой момент вытеснить Ваш поток и подключить к процессору другой, но ни один из потоков, которым нужен занятый Вами ресурс, не получит процессорное время до тех пор, пока Ваш поток не выйдет за границы критической секции.
Насчет то чего читать - давай тогда Дейкстру поднимем, как основателя теории синхронизации.... Лябрус он больше по рюшечкам, сеггеру, и безумным ГУЯм
|
|
|
|
|
|
|
|
Apr 21 2006, 06:54
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(zltigo @ Apr 21 2006, 13:20) -Безболезненная вложенность. -При использовании этого механизма без левых запретов прерывания будет отсутствовать это: Цитата
во-вторых, а если при первом вызове прерывания были по какой-то причине запрещены? Ведь при выходе они будут разрешены, что есть нарушение логики работы программы.
В варианте с сохранением/восстановлением аналогично - вложенность безболезненная. Зато есть ограничение - нельзя самому рулить состоянием прерываний. Цитата(zltigo @ Apr 21 2006, 13:20) Цитата
прилично кода - накладные расходы, т.е.
Одного порядка, на самом деле, в FreeRTOS случае дополнительная работа со счетчиком в памяти, в варианте "с сохранением" тоже работа с памятью - считать-запомнить-прочитать-записать. Ну да, тут в корне меньше - записал в память, на выходе извлек. А со счетчиком - прочитал, проинкрементировал, записал. (на входе), прочитал, проанализировал, сделал переход (а переход сам по себе наклАдная инструкция, и чем толще проц, тем она наклАднее), декрементировал, записал обратно в память. Фигассе! Вот реализация по схеме сохранил/восстановил для AVR: Вход: Код TCritSect cs;
B72F IN R18, 0x3F
8328 ST Y, R18
94F8 CLI выход Код 8108 LD R16, Y
BF0F OUT 0x3F, R16 Что может быть короче и нативнее? Цитата(zltigo @ Apr 21 2006, 13:20) Цитата
Почему бы не использовать простую схему (псевдокод):
....
Единственное требование - это необходимо жестко соблюдать комплементарность вызвовов этих функций, но это надо делать при любом подходе.
-Увы, не единственное, вроде уже распинался :-(. Прошу прощения, я как-то пропустил это. Можно для меня напомнить что там не единственное? Цитата(zltigo @ Apr 21 2006, 13:20) - в варианте "со счетчиком" комплементарность можно слегка нарушить :-) лишними вызовами
конца критической секции. Как это нарушить? Т.е. вход вызвали 3 раза и выход 4? Но ведь при этом работать-то оно будет неправильно - прерывания будут разрешены не в том месте, где были запрещены.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Apr 21 2006, 07:25
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(dxp @ Apr 21 2006, 09:54) Ну да, тут в корне меньше - записал в память, на выходе извлек. А со счетчиком - прочитал, проинкрементировал, записал. (на входе), прочитал, проанализировал, сделал переход (а переход сам по себе наклАдная инструкция, и чем толще проц, тем она наклАднее), декрементировал, записал обратно в память. Фигассе! Вот реализация по схеме сохранил/восстановил для AVR: Ну а теперь "на бис" для ARM, о которых здесь речь :-). И не в регистр сохранять. В ARM с памятью поработать - много хуже :-(. И заменитель 'CLI' выглядит тоскливо (выше приводил кусок кода). Зато у ARM "переходы" через несколько команд могут начисто отсутствовать. В результате разница будет крайне невелика. Цитата Прошу прощения, я как-то пропустил это. Можно для меня напомнить что там не единственное? Либо руками (Про C++ - не надо, я в курсе) будете выделять индивидуальную память для сохранения текущего зачения при каждом вызове, либо не будет вложенности. Про комплиментарноть - ниже. Цитата Как это нарушить? Т.е. вход вызвали 3 раза и выход 4? Но ведь при этом работать-то оно будет неправильно - прерывания будут разрешены не в том месте, где были запрещены. Хоть 444 раза - посмотрите код - действия просто будут проигнорированы, в отличие от варианта "с сохранением" в котором будет упорно переписываться последнее сохраненное бог всесть когда значение, а если еще и в регистре сохранить :-)
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 07:35
|
Частый гость
Группа: Свой
Сообщений: 173
Регистрация: 30-11-05
Из: San Francisco
Пользователь №: 11 593
|
А DASM вроде как прав получается, касательно критической секции.
Если Таненбаума книгу "Современные ОС" посмотреть, так там написано, что
Критическая секция служит для того, чтобы предотвратить одновременный доступ к обшим данным. Одно из требований, это то, что в критической области не могут находиться одновременно 2 процесса.
Но для этого действительно не обязательно запрещать прерывания. Поток находящийся в крит.секции, может вытесниться, но если какой другой поток захочет в нее войти, он должен ожидать пока она освободится.
Там есть рисунок, где рассматривается именно случай, когда 2-й поток вытесняет первый, пока он находится в крит.секции, и тоже пытается в нее войти. В результате он блокируется пока крит. секция не освободится.
|
|
|
|
|
|
|
|
Apr 21 2006, 07:44
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 20 2006, 23:51) Цитата(sensor_ua @ Apr 20 2006, 23:12)
Насчет "сложнее и ненадежнее", то интересны аргументы. Если только "персональность" переменной для хранения статуса, то уже обсуждали.
Еще раз повторить? 1. Сложнее - вместо простейшей обертки над стандартной де-факто библиотечной функции гарантированно работающей на любом процессоре. Писанная на асме чисто армовсая, да еще с заточкой под ARM Mode 2. Ненадежнее - легко ошибиться (особенно не зная потрохов и соответствено границ применимости) при использовании вложеных критических секций. Про macros писал - ну просто подстава чистейшей воды. Практически использование недалеко ушло от аккуратного использования пресловутого запрещения прерывания. Цитата А насчет "Простое запрещение прерываний" хотелось бы отклониться в сторону А ненадо отклоняться, ибо все равно оно имеет место быть. Это TNKernel: Код tn_cpu_save_sr:
mrs r0,CPSR
orr r1,r0,#NOINT
msr CPSR_c,r1
;-- Atmel add-on
mrs r1,CPSR ;-- Check CPSR for correct contents
and r1,r1,#NOINT
cmp r1,#NOINT
bne tn_cpu_save_sr ;-- Not disabled - loop to try again
;--------
bx lr Это кусок IARовской библиотеки: Код cfi_ARM_BLOCK_start disableInterrupt_a
CODE32
??DiI_a
mrs r12,CPSR
orr r12,r12,#0xC0
msr CPSR_c,r12
mrs r12,CPSR
ands r12,r12,#+0xC0
beq ??DiI_a
bx lr
cfi_ARM_BLOCK_end disableInterrupt_a Как Вам разница? Мои познания в асме закончились на #+0xC0. Вообще же, как по мне - не очень-то и разнится код - похоже, смысл тот же. Правда чуть короче запись. Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";))) Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает...
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 08:02
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(sensor_ua @ Apr 21 2006, 10:44) Вообще же, как по мне - не очень-то и разнится код - похоже, смысл тот же. Ага, для этого вывода и приводились эти куски. Только один почему-то в результате "анализа" был признан непонятным и некошерным. Что меня и удивило и подвигнуло на мой первый пост. Вот собственно и все.
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 08:13
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Цитата(zuy @ Apr 21 2006, 13:35) А DASM вроде как прав получается, касательно критической секции.
Если Таненбаума книгу "Современные ОС" посмотреть, так там написано, что
Критическая секция служит для того, чтобы предотвратить одновременный доступ к обшим данным. Одно из требований, это то, что в критической области не могут находиться одновременно 2 процесса.
Но для этого действительно не обязательно запрещать прерывания. Поток находящийся в крит.секции, может вытесниться, но если какой другой поток захочет в нее войти, он должен ожидать пока она освободится. В общем, спор о терминах. В принципе можно называть критической секцией любую секцию, где предотвращается одновременный доступ к каким-либо ресурсам из разных процессов. Способ реализации может быть, как методом запрета прерываний, так и с организацией доступа через бинарный семафор (или можно применить модное слово мютекс ) или какой-нибудь флаг. Причем иногда доступ запретом прерываний вообще может оказаться не приемлем, потому как ресурс, доступ к которому разделяется, может сам работать через прерывания, например захватили uart, передали строку символов, освободили uart. Понятно, что разделить доступ к такому ресурсу через запрет прерываний нельзя. Другое дело, когда надо сделать действие, достаточно короткое и быстрое, но требующее также гарантий ограничения доступа к этом ресурсу. Например, работа со связанными списками. Вставка элемента списка в цепочку должна быть сделана в критической секции. Но пользование в этом случае системных сервисов ОС (типа мютексов) - нецелесообразно, потому как накладные расходы возрастут раз в 100 по сравнению с методом разрешения/запрещения прерываний. И совсем другое дело, когда говорится о критических секциях, используемых в самой ОС, то есть когда сервисы ОС прописываются. Здесь термин "критическая секция" как раз всегда означает запрещение прерываний. А речь как раз о них и была (выше по теме). У меня терминология (моя локальная) устоялась так, что критической секцией я называю секцию, где запрещены прерывания, и не важно, используется в проекте ОС или нет. Цитата(sensor_ua @ Apr 21 2006, 13:44) Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";)))
Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает... #0xC0 маска для запрета IRQ и FIQ прерываний Маска 0x80 для регистра CPSR - это запрет IRQ , а 0x40 - для запрета FIQ.
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 21 2006, 08:13
|
Гуру
Группа: Свой
Сообщений: 3 644
Регистрация: 28-05-05
Пользователь №: 5 493
|
тогда предлагаю прямо и говорить "я называю критической секцией стакан с пивом, поэтому у нас несогласованность терминологий" Простенький пример, скажите, что тут защищает КОД ?? Код CRITICAL_SECTION cs;
CRITICAL_SECTION cs1;
//
struct common_struct{
int a;
CRITICAL_SECTION* myGuard;
};
//
DWORD WINAPI MyThread (LPVOID *p)
{
common_struct *pstruct = (common_struct *)p;
for (;;)
{
EnterCriticalSection(pstruct->myGuard);
pstruct->a++;
LeaveCriticalSection(pstruct->myGuard);
Sleep(0);
}
return 0;
}
//
int _tmain(int argc, _TCHAR* argv[])
{
DWORD dwID = 0;
common_struct com1 = {0, &cs}, com2 = {0, &cs1};
InitializeCriticalSection(&cs); InitializeCriticalSection(&cs1);
HANDLE hMyThr1 = CreateThread (NULL, 0, (LPTHREAD_START_ROUTINE)MyThread, &com1, CREATE_SUSPENDED, &dwID);
HANDLE hMyThr2 = CreateThread (NULL, 0, (LPTHREAD_START_ROUTINE)MyThread, &com2, CREATE_SUSPENDED, &dwID);
ResumeThread(hMyThr1);
ResumeThread(hMyThr2);
for (;;)
{
}
return 0;
}
|
|
|
|
|
|
|
|
Apr 21 2006, 08:20
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания ... Цитата(Andy Mozzhevilov @ Apr 21 2006, 11:13) Цитата(zuy @ Apr 21 2006, 13:35)
А DASM вроде как прав получается, касательно критической секции.
Если Таненбаума книгу "Современные ОС" посмотреть, так там написано, что
Критическая секция служит для того, чтобы предотвратить одновременный доступ к обшим данным. Одно из требований, это то, что в критической области не могут находиться одновременно 2 процесса.
Но для этого действительно не обязательно запрещать прерывания. Поток находящийся в крит.секции, может вытесниться, но если какой другой поток захочет в нее войти, он должен ожидать пока она освободится.
В общем, спор о терминах. В принципе можно называть критической секцией любую секцию, где предотвращается одновременный доступ к каким-либо ресурсам из разных процессов. Способ реализации может быть, как методом запрета прерываний, так и с организацией доступа через бинарный семафор (или можно применить модное слово мютекс ) или какой-нибудь флаг. Причем иногда доступ запретом прерываний вообще может оказаться не приемлем, потому как ресурс, доступ к которому разделяется, может сам работать через прерывания, например захватили uart, передали строку символов, освободили uart. Понятно, что разделить доступ к такому ресурсу через запрет прерываний нельзя. Другое дело, когда надо сделать действие, достаточно короткое и быстрое, но требующее также гарантий ограничения доступа к этом ресурсу. Например, работа со связанными списками. Вставка элемента списка в цепочку должна быть сделана в критической секции. Но пользование в этом случае системных сервисов ОС (типа мютексов) - нецелесообразно, потому как накладные расходы возрастут раз в 100 по сравнению с методом разрешения/запрещения прерываний. И совсем другое дело, когда говорится о критических секциях, используемых в самой ОС, то есть когда сервисы ОС прописываются. Здесь термин "критическая секция" как раз всегда означает запрещение прерываний. А речь как раз о них и была (выше по теме). У меня терминология (моя локальная) устоялась так, что критической секцией я называю секцию, где запрещены прерывания, и не важно, используется в проекте ОС или нет. Цитата(sensor_ua @ Apr 21 2006, 13:44) Пока пороюсь поищу что такое #+0xC0, а то "чукча не читатель";)))
Может подскажете, где? А то ARM7TDMI Data Sheet (ARM DDI 0029E) не помогает... #0xC0 маска для запрета IRQ и FIQ прерываний Маска 0x80 для регистра CPSR - это запрет IRQ , а 0x40 - для запрета FIQ. Простите, не указал точно - мне непонятно только "#+"
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 08:42
|
Знающий
Группа: Свой
Сообщений: 877
Регистрация: 26-01-05
Из: Екатеринбург
Пользователь №: 2 206
|
Цитата(sensor_ua @ Apr 21 2006, 14:20) Простите, не указал точно - мне непонятно только "#+" Ну, это значит "не минус" Цитата(DASM @ Apr 21 2006, 14:13) тогда предлагаю прямо и говорить "я называю критической секцией стакан с пивом, поэтому у нас несогласованность терминологий"
Простенький пример, скажите, что тут защищает КОД ?? понятия не имею.
--------------------
Пасу котов...
|
|
|
|
|
|
|
|
Apr 21 2006, 08:46
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата Ну, это значит "не минус" smile.gif Спасибо.
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 09:23
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(zltigo @ Apr 21 2006, 14:25) Ну а теперь "на бис" для ARM, о которых здесь речь :-). И не в регистр сохранять. В ARM с памятью поработать - много хуже :-(. Если Вы обратили внимание, то могли заметить, что сохраняется не в регистр, а в память. :-Р И с чего это у АРМа так плохо с памятью? Обычное дело для любого фон неймана. В случае со счетчиком тоже в память надо лазить и еще больше, т.к. чтение-модификация-запись. Если так плохо при работе с памятью, то в результате этот подход вообще плохо для АРМа подходит. Цитата(zltigo @ Apr 21 2006, 14:25) Цитата
Прошу прощения, я как-то пропустил это. Можно для меня напомнить что там не единственное?
Либо руками (Про C++ - не надо, я в курсе) будете выделять индивидуальную память для сохранения текущего зачения при каждом вызове, либо не будет вложенности. Про комплиментарноть - ниже. Зачем что-то выделять руками? Внутри функции выделяется локальная переменная. Она и работа с ней скрыты внутри и совершенно не касаются пользователя. Внешне все выглядит так же - функция-вход и функция-выход. С++ позволяет лишь автоматизировать вызов фунции-выхода, чтобы не забыть ее вызвать в нужном месте. Цитата(zltigo @ Apr 21 2006, 14:25) Цитата
Как это нарушить? Т.е. вход вызвали 3 раза и выход 4? Но ведь при этом работать-то оно будет неправильно - прерывания будут разрешены не в том месте, где были запрещены.
Хоть 444 раза - посмотрите код - действия просто будут проигнорированы, в отличие от варианта "с сохранением" в котором будет упорно переписываться последнее сохраненное бог всесть когда значение, а если еще и в регистре сохранить :-) Что-то Вы не про то. Вот пример: CritEnter() // 1 раз вызвали, прерывания запретили ... CritEnter() // 2 раз вызвали ... CritEnter() // 3 раз вызвали ... ... CritExit() // это соответствует 3 ... CritExit() // это соответствует 2 ... CritExit() // а это по ошибке вызвали, здесь разрешились прерывания, а не должны! ... CritExit() // а здесь должны были быть разрешены прерывания ... Т.е. вот лишний вызов вносит семантическую ошибку из-за нарушения комплементарности вызова. И толку-то от этих проверок. Комплементарность должна строго соблюдаться, иначе будет, как уже сказал, нарушение функциональной целостности программы.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Apr 21 2006, 09:40
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(DASM @ Apr 21 2006, 14:45) Цитата(vet @ Apr 21 2006, 11:42) Глупость это. Причем тут КОД ? Представьте себе 128 экземпляров некоего класса. Код у них один и тот же, разные у них данные. Пусть объект один захватил за попку одну девушку (разделяемый ресурс, вошел в свою критическую секцию) Да, это не даст другим экземплярам трогать туже поку, но разве это запрещает другим экземплярам лапать другие попы ? В том же участке кода, теми же руками. Просто Критические секции будут разными, разными объектами в памяти. Позволю себе заметить, что у всех 100 экземпляров классов КОД их функций-членов - ОДИН И ТОТ ЖЕ! Будете с этим спорить? Цитата(DASM @ Apr 21 2006, 14:45) И запрещать тут прерывания - форменное свинство. Запрещение прерываний - это один из способов реализации. Наверное, самый простой. Предложите другой способ защитить код, выполняемый в планировщике, где изменяются состояния объектов ядра и все изменения должны быть выполненны атомарно?
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Apr 21 2006, 09:53
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
Дело все в том,что понятие критическая секция ( монопольное исполнение операции
над ресурсом) и ее реализация - это разные вещи. Реализована критическая секция
может быть не только зарещением прерываний(что обычно делается в небольших
системах),но и другими способами. Все объекты синхронизации более высокого
уровня(семафоры, мьютексы и т.д.) уже используют внутри себя критические секции
(в вышеуказанном понимании).
Что же касается сохранения одного из статусных регистров при прерываниях в ARM,
то это надо делать дополнительно(что и делается в VxWorks,ThreadX,uC-OS,TNKernel
и т.д.) - либо в стеке вызываемой ф-ции(ThreadX,uC-OS,TNKernel),либо в специальном
фрейме стека/памяти (VxWorks). За это спасибо разработчикам архитектуры ARMа.
|
|
|
|
|
|
|
|
Apr 21 2006, 12:47
|
Гуру
Группа: СуперМодераторы
Сообщений: 2 065
Регистрация: 11-01-05
Из: Москва
Пользователь №: 1 892
|
Цитата(yuri_t @ Apr 21 2006, 16:22) IMHO, пользователь любой ОS от Windows/Linux до TNKernel никогда
не должен запрещать/разрешать прерывания в своей программе - OS делает это для него в своих семафорах, очередях и т.д.
Если прикладной программе требуется запрещать/разрешать прерывания
напрямую - это плохо написанная программа.
Единственное исключение из вышесказанного - это когда программа
пользователя фактически является расширением ОС - драйвером (USB,networks etc.). Вот это я категорически поддерживаю!!! Вообще, в ОСях, IMHO, должна быть такая немаловажная деталь, как синтетический порт под Win32 (или Linux) или на пЫсюк. В начале почти каждого проекта важно отладить его структуру, форматы данных и пр. А такие вещи пишутся на palin С, и им пофиг, на какой платформе работать. Это просто лично моя мечта - взять синтетический порт ОСи на Win32, запустить http://www.mingw.orghttp://www.bloodshed.net/devcpp.htmlhttp://www.codeblocks.org/И написать там весь проект без дров. Дрова на таком этапе удобно заменять консолью, файлами, IP и именованными каналами (для связи с другими процессами и машинами). Все-таки аппаратно независимую алгоритмику отлаживать на целевой платформе - глуповатое занятие  А на пЫсюке test units писать - самое то! Тут для тестирования Python, Matlab и другие мощные тулзы подрубить можно. Что касается ассемблерных вставок для эффективной реализации критических кусков - для этого препроцессор есть. Все равно такой кусок имеет вход и выход, да еще рабочую память. Вот и пишется вначале C прототип такого куска, чтобы отладить его взаимодействие с другими частями (и пусть он будет в 100 раз медленнее оптимальнго асмового кода - на этом этапе это не важно, "точность попадания компенсируется диаметром изделия", будет пЫсюк тормозить - возьмем мощнее ), и только потом переводитсмя на асм. А другой человек (или ты, но в другой момент времени) самозабвенно JTAG'ит дрова на целевой платформе. Затем на эти дрова одевается основной каркас, и делается тонкая доводка. IMHO, за счет общей оптимизации проекта можно добиться гораздо большего (главное - фантазию на этом этапе включить по полной, полностью раскрепоститься), чем за счет сверхоптимального асмового и С кодинга (как справделиво учит методология XP программизма - опитимизировать надо потом, когда станет очевидно, что именно этот кусок и надо оптимизировать!). А решать все задачи сразу - так только клиенты Кащенко умеют. Именно их этих соображений я и выбрал eCos (порт на PC (готовая загрузочная дискета) и синтетический порт на Linux), котрый потихоньку изучаю. В связи с колоссальным ростом возможностей SOC, IMHO, именно такой методологический подход будет эффекивнее на перспективу. Ибо после выхода STR91xxx "ограничений для фантазии" в плане ОС почти не останется - в 512К FLASH и 96k SRAM влезет почти все! 
|
|
|
|
|
|
|
|
Apr 21 2006, 15:45
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
В какую-то параною скатывается разговор. Почему _Я_ начал этот разговор -я уже 'оправдывался'. Цитата(dxp @ Apr 21 2006, 12:23) Если Вы обратили внимание, то могли заметить, что сохраняется не в регистр, а в память. :-Р - не обратил, поскольку с Atmel не имел дела и уже не буду, а увидев явное указание регистра предположил сохранение в регистре, при этом естественно, должен отметить Ваше лукавство заключающееся в отсутствии занесения регистра, ну да бог с ним.... Цитата И с чего это у АРМа так плохо с памятью? Обычное дело для любого фон неймана. В случае со счетчиком тоже в память надо лазить и еще больше, т.к. чтение-модификация-запись. Если так плохо при работе с памятью, то в результате этот подход вообще плохо для АРМа подходит. Вот как раз по причине "плохого Неймана" и по причине кривизны SAMовской реализации блокировки прерываний, и по причине возможности условного выполнения команд на ARM, как-раз для ARM сие подходит, ибо даже не особо длиннее и пожалуй быстрее ввиду отсутствия необходимости всегда бездумно выполнять кучку команд для разблокировки и особенно блокировки. Если это типа x86 pushf cli ..... popf То тогда еще можно говорить о введении вместо этого глобального счетчика, как о заметном усложнении и торможении процесса, но не для ARM. Цитата Зачем что-то выделять руками? Внутри функции выделяется локальная переменная. Она и работа с ней скрыты внутри и совершенно не касаются пользователя. Внешне все выглядит так же - функция-вход и функция-выход. С++ позволяет лишь автоматизировать вызов фунции-выхода, чтобы не забыть ее вызвать в нужном месте. Это мы о какой функции? Если о той из которой вызывается, то создание локальной переменной я и называю 'руками', а если из нее еще вызвать, то создать еще одну локальную и..... Cкрыть-то можно в функции 'entercritical' - но там она не может быть локальной :-) по определению, так что о чем мы это говорим - я не понял. (Это я все НЕ о C++) Цитата Что-то Вы не про то. Вот пример:
CritEnter() // 1 раз вызвали, прерывания запретили
...
CritEnter() // 2 раз вызвали
...
CritEnter() // 3 раз вызвали
...
...
CritExit() // это соответствует 3
...
CritExit() // это соответствует 2
...
CritExit() // а это по ошибке вызвали, здесь разрешились прерывания, а не должны!
...
CritExit() // а здесь должны были быть разрешены прерывания
...
Т.е. вот лишний вызов вносит семантическую ошибку из-за нарушения комплементарности вызова. И толку-то от этих проверок. Комплементарность должна строго соблюдаться, иначе будет, как уже сказал, нарушение функциональной целостности программы. А Вы поменяйте в своем примере две последние строчки местами и..... ошибки НЕ произойдет. Таким образом, есть ситуация, когда эти "лишние" навороты приносят пользу. И уж как минимум, эти навороты если и длинее чуть-чуть для ARM платформы, то уж НЕ ХУЖЕ справляются со своими обязаностями, нежели принятая в TNKernel реализация. И уж точно не могут быть причиной НЕ ИСПОЛЬЗОВАНИЯ FreeRTOS. Ну и "дуракоустойчивость" на мой взгляд получше. Закончим???
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 16:17
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(sensor_ua @ Apr 21 2006, 11:20) У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания ... Я не понял :-( Вообще ничего из вышеизложенного не понял. Если речь идет о том, что Вы имеете некоторую процедуру,которая для обеспечения ее непрерывности обрамлена critical и по этой причине ее нельзя вызывать из обработчика прерывания, то 0. Нужно делать вещи максимально близкие к естественным. 1. Делается процедура без запретов. 2. Для работы в прерывании вызывается прямо или через прямую макроподстановку 3. Для прочего использования через макрос-обертку с __disable/enable. Если обработчики прерываний в отдельном файле, то макроимена могут быть вообще одинаковыми. В результате начисто отпадают все ненужные навороты как в виде 'счетчиков', так и ввиде 'сохранений', заодно не надо вникать в реализацию critical в каждой конкретной операционке. Все выглядит (живой пример) примерно так: Код //-----------------------------------------------------------
// Read/Write SLIC Registers with CLOSED interrupts
void wr_sreg_int( BYTE channel, BYTE reg, BYTE value );
......
//-----------------------------------------------------------
// Read/Write SLIC Registers
#define wr_sreg( x, y, z ) \
{ __disable_interrupt(); \
wr_sreg_int( x, y, z ); \
__enable_interrupt(); }
...... Если всенеприменнейше хотите critical, то можете добавить свой critical для обработчиков прерываний, единственной функцией которого будет наращивание/уменьшение 'счетчика'. Цитата(sensor_ua @ Apr 21 2006, 19:08) 2 zltigo
У меня насчёт правильности запрещения/разрешения прерываний вопрос к Вам остался.
Представьте себе, что пишет подпрограмму с критической секцией не Вы, а коллега. Вы эту подпрограмму интегрируете в свой проект.
Ответьте, пожалуйста, на каком основании Ваш коллега имеет право разрешать прерывания (при выходе из критической секции), если он не узнаЁт при запрещении (при входе в критическую секцию), были ли они (прерывания) разрешены? Так они и не будут разрешены если Вы вызвали его из критической секции и соответственно счетчик на входе в подпрограмму колеги уже не будет 0. Ежели коллега, или Вы пожелает в _прикладной_ программе воспользоваться прямым запретом/разрешением вместо critical , то, как здесь уже было замечено, надо наказывать, ибо против лома нет приема.
Сообщение отредактировал zltigo - Apr 21 2006, 16:26
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 16:23
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 21 2006, 19:17) Цитата(sensor_ua @ Apr 21 2006, 11:20) У меня железка с неким ногодрыганием, устроенным типа импровизированной шины. Как известно, GPIO сами не имеют в АРМ операций чтение-модификация-запись, дык ещё в железке есть выборки внешних устройств на "шине" через опять же GPIO. Если подвигать GPIO в прерывании, а оно может возникнуть когда двигались GPIO вне прерывания, чегой-то нужно сохранять. Т.е. либо в административном порядке запрещать использовать GPIO в прерывании, либо реализовать атомарность каким-либо способом. АРМ позволяет, например, выполнить SWI, можно просто запрещать прерывания на входе в критическую секцию, при выходе - разрешать, но тогда если при входе если были запрещены прерывания, при выходе они разрешатся... иначе нужно при входе не просто запрещать, а сохранять регистр статуса, затем запрещать прерывания, а при выходе всего-лишь восстанавливать что было. Можно вообще завести обработчик IRQ, в который вваливаться через VICSoftInt, а там творить чего угодно, пока не разрешили вложенные прерывания ... Я не понял :-( Вообще ничего из вышеизложенного не понял. Если речь идет о том, что Вы имеете некоторую процедуру,которая для обеспечения ее непрерывности обрамлена critical и по этой причине ее нельзя вызывать из обработчика прерывания, то 0. Нужно делать вещи максимально близкие к естественным. 1. Делается процедура без запретов. 2. Для работы в прерывании вызывается прямо или через прямую макроподстановку 3. Для прочего использования через макрос-обертку с __disable/enable. Если обработчики прерываний в отдельном файле, то макроимена могут быть вообще одинаковыми. В результате начисто отпадают все ненужные навороты как в виде 'счетчиков', так и ввиде 'сохранений', заодно не надо вникать в реализацию critical в каждой конкретной операционке. Все выглядит (живой пример) примерно так: Код //-----------------------------------------------------------
// Read/Write SLIC Registers with CLOSED interrupts
void wr_sreg_int( BYTE channel, BYTE reg, BYTE value );
......
//-----------------------------------------------------------
// Read/Write SLIC Registers
#define wr_sreg( x, y, z ) \
{ __disable_interrupt(); \
wr_sreg_int( x, y, z ); \
__enable_interrupt(); }
...... Цитата(sensor_ua @ Apr 21 2006, 19:08) 2 zltigo
У меня насчёт правильности запрещения/разрешения прерываний вопрос к Вам остался.
Представьте себе, что пишет подпрограмму с критической секцией не Вы, а коллега. Вы эту подпрограмму интегрируете в свой проект.
Ответьте, пожалуйста, на каком основании Ваш коллега имеет право разрешать прерывания (при выходе из критической секции), если он не узнаЁт при запрещении (при входе в критическую секцию), были ли они (прерывания) разрешены? Так они и не будут разрешены если Вы вызвали его из критической секции и соответственно счетчик на входе в подпрограмму колеги уже не будет 0. Ежели коллега, или Вы пожелает в _прикладной_ программе воспользоваться прямым запретом/разрешением вместо critical , то, как здесь уже было замечено, надо наказывать, ибо против лома нет приема. Я о варианте, когда в основной программе прерывания в какой-то прекрасный момент выключены не в критической секции. Как быть с разрешением в подпрограмме коллеги?
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 16:36
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
To sensor_ua
-------------------
Учитывая Ваш искренний интерес и желание все понять "до последнего винтика",
отвечу:
Во первых,такое выражение просто не будет работать:
#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg); }
Если следовать этим путем, то должно быть, наверное, так:
#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr(); }
#define tn_enable_interrupt() { tn_cpu_restore_sr(tn_save_status_reg); }
Теперь, если Вы вызовете это выражение внутри одной функции несколько
раз, то согласно стандарта на язык С, локальная переменная int tn_save_status_reg
будет видна только внутри блока, где она объявлена, следовательно,
сколько раз вы вызвали tn_disable_interrupt(), столько раз она
и будет создаваться.
Далее, при вызове tn_enable_interrupt() компилятор не увидит
tn_save_status_reg - блок, где было определение, уже завершился.
(а если бы не завершился - то пришлось бы иметь несколько переменных
с одним именем - что всех бы запутало(и компилятор, и программиста) и
поэтому невозможно).
Поэтому давайте оставим это место в коде так, как оно существует сейчас.
И в заключение - при использовании ОС стоит работать на уровне семафоров,
очередей и т.д.
ОС для того и создается,чтобы избавить пользователя от всей этой возни с
сохранением регистров, запрещением/разрешением преываний, etc.
C уважением, yuri_t
Сообщение отредактировал yuri_t - Apr 21 2006, 16:48
|
|
|
|
|
|
|
|
Apr 21 2006, 17:05
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 21 2006, 19:32) Цитата(sensor_ua @ Apr 21 2006, 19:23)
Я о варианте, когда в основной программе прерывания в какой-то прекрасный момент выключены не в критической секции. Как быть с разрешением в подпрограмме коллеги?
Мне казалось, что я ответил. У меня, тогда больше нет слов для обьяснения :-(. Попробуйте перечитать написанное в моем предыдущем посте. ИМХО, Вы приняли как за оскорбление мое мнение об критической секции в конкретной ОС - FreeRTOS и, рассказав о недостатках реализации в другой ОС- TNKernel (а точнее других, потому как ассемблерная часть в uCOS-II и TNKernel совпадает, вероятно и в других ОС) пытаетесь доказать, что сам механизм выбран неверно, а я от Вас пытаюсь получить четкие пояснения преимуществ/недостатков механизма, который в коммерческой ОС uCOS-II не применяется, хотя написано, что о нем хорошо знают. Я не понимаю как можно не проверив, было ли разрешено прерывание перед входом в критическую секцию, после окончания таковой его взводить. Вы же мне о Вашем мнении об разных ОС и макрообертках
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 17:15
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(yuri_t @ Apr 21 2006, 19:36) To sensor_ua
-------------------
Учитывая Ваш искренний интерес и желание все понять "до последнего винтика",
отвечу:
Во первых,такое выражение просто не будет работать:
#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr()
#define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg); }
Если следовать этим путем, то должно быть, наверное, так:
#define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr(); }
#define tn_enable_interrupt() { tn_cpu_restore_sr(tn_save_status_reg); }
Теперь, если Вы вызовете это выражение внутри одной функции несколько
раз, то согласно стандарта на язык С, локальная переменная int tn_save_status_reg
будет видна только внутри блока, где она объявлена, следовательно,
сколько раз вы вызвали tn_disable_interrupt(), столько раз она
и будет создаваться.
Далее, при вызове tn_enable_interrupt() компилятор не увидит
tn_save_status_reg - блок, где было определение, уже завершился.
(а если бы не завершился - то пришлось бы иметь несколько переменных
с одним именем - что всех бы запутало(и компилятор, и программиста) и
поэтому невозможно).
Поэтому давайте оставим это место в коде так, как оно существует сейчас.
И в заключение - при использовании ОС стоит работать на уровне семафоров,
очередей и т.д.
ОС для того и создается,чтобы избавить пользователя от всей этой возни с
сохранением регистров, запрещением/разрешением преываний, etc.
C уважением, yuri_t Во-первых, работает RVDMK2.5. Без ОС как таковой Макрос, открывающий блок и объявлящий/определяющий локальную переменную #define tn_disable_interrupt() { int tn_save_status_reg = tn_cpu_save_sr() ну и макрос, закрывающий блок #define tn_enable_interrupt() tn_cpu_restore_sr(tn_save_status_reg); } после него, естественно, о переменной, локальной для блока, забываем Насчет "в заключение" - спасибо за совет - подучусь, почитаю и уж тогда...
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 18:07
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(yuri_t @ Apr 21 2006, 20:33) To sensor_ua
-------------------
Ситуация, когда компилятор не полностью следует ANSI стандарту,
хорошо известна.
Например Visual C/C++ 6 (Microsoft) видит все локальные переменные,
объявленные внутри блока и далее вниз по тексту,
а Borland C/C++ 5 (CBuilder) - не видит.
IMHO, eсли Вы хотите писать переносимый код, то следует придерживаться
ANSI стандарта. Простите, под рукой нет стандарта (где-то был только C99), но есть справочник Шилдта 4-е издание. В разделе "Переменные", подразделе "Локальные переменные" есть следующее: /-------- Из соображений удобства и в силу устоявшейся традиции все локальные переменные функции чаще всего объявляются в самом начале функции, сразу после открывающейся фигурной скобки. Однако можно объявить локальную переменную и внутри блока программы (блок функции - это частный случай блока программы. . . . В стандарте C89 все локальные переменные должны быть объявлены в начале блока, до любого выполнимого оператора. . . . Однако в C99 ... локальная переменная может быть объявлена в любом месте блока до ее первого использования. ---------/ Не встречал случая "невидимости" локальной переменной внутри блока и не знаком с такой возможностью.
--------------------
aka Vit
|
|
|
|
|
|
|
|
Apr 21 2006, 18:24
|
Частый гость
Группа: Свой
Сообщений: 163
Регистрация: 24-08-05
Пользователь №: 7 937
|
Когда я писал "Например Visual C/C++ 6 (Microsoft) видит все локальные переменные, объявленные внутри блока и далее вниз по тексту, а Borland C/C++ 5 (CBuilder) - не видит.", я имел ввиду, что Visual C/C++ 6 (Microsoft) видит все локальные переменные, объявленные внутри блока и далее вниз по тексту, когда блок уже
завершился, что не соответствует ANSI стандарту, a Borland C/C++ 5 strictly supports ANSI (хотя ,заметим, и генерит код худшего качества). <pre> void my_func(void) { int i = 0; { int a1 =3; } { a1 = i+3; //-- Microsoft Visual C считает что a1 уже определена //-- а Borland C (and any another strictly ANSI compiler) будет ругаться //-- что a1 не описана. } } </pre> By the way, TNKernel компилировалась на 8 различных компиляторах. Дaвайте на этом и завершим разговор о макросах,компиляторах и прочей "ветвистой пшенице"(с). C уважением, yuri_t
Сообщение отредактировал yuri_t - Apr 21 2006, 18:39
|
|
|
|
|
|
|
|
Apr 21 2006, 19:06
|
Гуру
Группа: Свой
Сообщений: 13 372
Регистрация: 27-11-04
Из: Riga, Latvia
Пользователь №: 1 244
|
Цитата(sensor_ua @ Apr 21 2006, 20:05) Я не понимаю как можно не проверив, было ли разрешено прерывание перед входом в критическую секцию, после окончания таковой его взводить. Зачем нести очевидный бред - не понимаю :-( Цитата ИМХО, Вы приняли как за оскорбление мое мнение об критической секции в конкретной ОС - FreeRTOS и, рассказав о недостатках реализации в другой ОС- TNKernel (а точнее других, потому как ассемблерная часть в uCOS-II и TNKernel совпадает, вероятно и в других ОС) пытаетесь доказать, что сам механизм выбран неверно Оскорбление? :-) Похоже проблемы с пониманием письменного текста :-(. Нет, механизмы близки между собой настолько, что ни о какой непригодности FreeRTOSного речи идти не может. Что-же касается неимоверно косноязычно изложенной 'проблемы', то для ее решения вообще не надо пользоватся вышеупомянутыми механизмами вне зависимости от их реализации. Либо спуститься на уровень ниже и с умом оперировать элементарными запретами/разрешениями либо наоборот использовать исключительно высокоуровневые системные средства (к этому Вас призывают целых два Автора операционных систем не считая 'прочих').
--------------------
Feci, quod potui, faciant meliora potentes
|
|
|
|
|
|
|
|
Apr 21 2006, 19:45
|
Профессионал
Группа: Свой
Сообщений: 1 266
Регистрация: 22-04-05
Из: Киев
Пользователь №: 4 387
|
Цитата(zltigo @ Apr 21 2006, 22:06) Цитата(sensor_ua @ Apr 21 2006, 20:05)
Я не понимаю как можно не проверив, было ли разрешено прерывание перед входом в критическую секцию, после окончания таковой его взводить.
Зачем нести очевидный бред - не понимаю :-( Цитата ИМХО, Вы приняли как за оскорбление мое мнение об критической секции в конкретной ОС - FreeRTOS и, рассказав о недостатках реализации в другой ОС- TNKernel (а точнее других, потому как ассемблерная часть в uCOS-II и TNKernel совпадает, вероятно и в других ОС) пытаетесь доказать, что сам механизм выбран неверно Оскорбление? :-) Похоже проблемы с пониманием письменного текста :-(. Нет, механизмы близки между собой настолько, что ни о какой непригодности FreeRTOSного речи идти не может. Что-же касается неимоверно косноязычно изложенной 'проблемы', то для ее решения вообще не надо пользоватся вышеупомянутыми механизмами вне зависимости от их реализации. Либо спуститься на уровень ниже и с умом оперировать элементарными запретами/разрешениями либо наоборот использовать исключительно высокоуровневые системные средства (к этому Вас призывают целых два Автора операционных систем не считая 'прочих'). Жаль, что Вы не хотите агументированного обсуждения. И грубите. IMNHO, сами ответить на очевидный свой промах в рассуждениях не желаете априори. Цитата(yuri_t @ Apr 21 2006, 21:24) Когда я писал "Например Visual C/C++ 6 (Microsoft) видит все локальные переменные, объявленные внутри блока и далее вниз по тексту, а Borland C/C++ 5 (CBuilder) - не видит.", я имел ввиду, что Visual C/C++ 6 (Microsoft) видит все локальные переменные, объявленные внутри блока и далее вниз по тексту, когда блок уже
завершился, что не соответствует ANSI стандарту, a Borland C/C++ 5 strictly supports ANSI (хотя ,заметим, и генерит код худшего качества). <pre> void my_func(void) { int i = 0; { int a1 =3; } { a1 = i+3; //-- Microsoft Visual C считает что a1 уже определена //-- а Borland C (and any another strictly ANSI compiler) будет ругаться //-- что a1 не описана. } } </pre> By the way, TNKernel компилировалась на 8 различных компиляторах. Дaвайте на этом и завершим разговор о макросах,компиляторах и прочей "ветвистой пшенице"(с). C уважением, yuri_t Спасибо, разъяснили.
--------------------
aka Vit
|
|
|
|
|
|
|
|
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0
|
|
|
