caxapa.ru :: Возможно, обнаружился баг scmRTOS.

Argon (20.01.2008 23:15, просмотров: 40528)

Возможно, обнаружился баг scmRTOS. Есть 3 процесса. Есть флаги OS::TEventFlag Buttons. OS::TEventFlag Sound_Start. 1. Высший приоритет. Опрашивает клавиатуру. При изменении сигналит: Buttons.Signal(); Sound_Start.Signal(); далее процесс спит 50 мсек. Выставленные флаги сбрасываются только в процессах с низшим приоритетом. 2. Средний приоритет. Ждет в спячке Sound_Start (флаг после этого автоматически сбрасывается), после чего запускает генерацию звука - читает из флэшки сэмплы в буфер и выводит в ЦАП, в промежутках спит. Время спячки однозначно ненулевое, так что он иногда дает время процессу с низшим приоритетом. 3. Низший приоритет. Ловит Buttons. Но по какой-то странной причине Buttons ловится раз из 10 нажатий. Больше этот флаг нигде не сбрасывается. if(Buttons.Wait(10)) { ...некие действия (вывод на дисплей и т.п.)... } И в этот-то цикл управление передается где-то раз из 10. Неизвестно где Buttons оказывается сброшен. Предположение такое: его сбрасывает ядро ОС при обработке Wait. Т.е. вроде как управление должно перейти в цикл. Но управление сразу же забирает 2-й, более приоритетный процесс (это-то работает надежно), т.к. ему сначала нужно насосать сэмплы в буфер. И почему-то ОС "забывает" передать управление 3-му процессу, несмотря на то, что флаг сброшен. Можно, конечно, в 3-м процессе ожидание убрать, т.к. он менее приоритетный и ничего страшного, если он будет молотить в тупом цикле. Тогда все работает, но факт остается фактом, хотелось бы разобраться с явлением.

Ответить

- А почему такое странное использование? Зачем ждать события с таймаутом? Если надо обработать кнопки, то просто Wait() и все - событие придет, процесс будет разбужен и обработает его. А так оно похоже на polling. dxp(546 знак., 24.01.2008 07:51)
  - Да нет, ожидание события с периодическим просыпанием для отработки всяких таймаутов - очень нужное свойство. И глюк в этой части крайне неприятен. - =AlexD=(24.01.2008 08:06)
    - Не спорю, все так. В конце концов логика работы должна соответствовать, как грицца, observable behaviour, а это в данном случае не так. - dxp(24.01.2008 09:13)
- Мое предположение не подтвердилось. Следующее предположение! Argon(567 знак., 20.01.2008 23:24)
  - Кроме меня кто-то сталкивался с таким багом? Еще раз его суть: при ожидании флага с таймаутом ОС сбрасывает флаг принудительно при исходе времени, что иногда влечет пропуски флага. - Argon(23.01.2008 13:38)
    - Ну так поправь исходник, раз считаешь что не правильно работает. Сейчас посмотрел - действительно, проверяется только факт того, кончился таймаут или нет. Не знаю, почему так сделано. =AlexD=(1853 знак., 23.01.2008 13:58)
      - Я был не уверен, вдруг это "не баг а фича" :) Если баг, то должен быть исправлен "официально" (автором порта), поскольку scmRTOS является законченным продуктом, имеющим номер версии. - Argon(23.01.2008 14:24)
        
        Да, похоже это баг. Внесите его в багтрекер, чтобы не забылся. Счас сам занесу. Argon, вы можете проверить этот код, чтобы внести исправление? У меня сейчас нет возможности провести полноценное тестирование :( Сергей Борщ(1443 знак., 23.01.2008 15:10, ссылка)
        
        Один момент! Вместо эвента получился бинарный семафор. Теряется совместимость. В общем, я так думаю, эвент нужно передавать через флаг в TBaseProcess шедулером. А это уже серьёзное перелопачивание. - =AlexD=(24.01.2008 08:01)
        
        Объясните подробнее, пожалуйста. Где получился семафор? - Cepгeй Бopщ(24.01.2008 14:04)
        
        Дык... Раньше как было - сигналишь, все задачи, которые сигнал ждут просыпаются и работают. А теперь проснётся только одна самая приоритетная задача. Т.е. вместо эвента(будит всех) получили бинарный семафор(будит только самого приоритетного) - =AlexD=(24.01.2008 14:28)
        
        Нда, сюжет :( А я голову ломаю, чего я в своей ветке сделал Value типа TProcessMap! - Cepгeй Бopщ(24.01.2008 14:48, ссылка)
        
        Хороший вариант. Только OS::TEventFlag::Signal() недоделаный, нужно Value |= ProcessMap; - =AlexD=(24.01.2008 15:03)
        
        А вот не уверен. Получается, что если флаг просигнален раньше, чем его кто-то начал ждать - флаг потеряется. Раньше не терялся. Поправил по этому варианту, но все равно не получается добиться исходной функциональности. - Сергей Борщ(24.01.2008 19:12, ссылка)
        
        А вот снова промахнулся :( Теперь процесс, ждущий без таймаута нельзя разбудить с помощью OS::ForceWakeUpProcess() Гляньте, может так? Сергей Борщ(1209 знак., 24.01.2008 19:36, ссылка)
        
        Может как-то так извернуться? =AlexD=(2317 знак., 25.01.2008 08:48)
        
        Не понял, а кто сбрасывает Flags? - Сергей Борщ(25.01.2008 12:19)
        
        Ещё нашёл опечатки, вобщем, гдето так =AlexD=(1283 знак., 25.01.2008 12:42)
        
        Или даже так: =AlexD=(1059 знак., 25.01.2008 12:50)
        
        Т.е. если ожидающих события нет - для них ставицца общий Value, если есть - индивидуальные Flags. Ну а если быть совсем точным, вероятно нужно что-то вроде: =AlexD=(1448 знак., 25.01.2008 13:00)
        
        Да, это ближе к истине. Еще можно сэкономить Value, использовав в его качестве бит Idle-процесса в Flags. Буду думать. - Сергей Борщ(25.01.2008 13:36)
        
        Угу - =AlexD=(25.01.2008 13:52)
        
        Так. Что-то у меня возникло непонимание логики работы TEventFlag Сергей Борщ(438 знак., 25.01.2008 18:34)
        
        ИМХО У меня такое же понимание. Argon(544 знак., 25.01.2008 19:54)
        
        Совершенно верно. Вполне разумное поведение. В принципе это два разных свойства для разных способов использования. Просто теперь это стало более явно выражено в коде. Причём в одном из моих небольших проектов используются оба метода. - =AlexD=(25.01.2008 19:42)
        
        Вот, получилось такое, надо тестировать. Сможете проверить в своем проекте? На примере работает, как в жизни - не знаю. Надо бы еще придумать пример, который показывает все эти аспекты поведения. - Cepгeй Бopщ(25.01.2008 21:37, ссылка)
        
        Тааак... а если =AlexD=(2190 знак., 28.01.2008 08:45)
        
        Озадачил. Будет время - погоняю. Только наверное вот так: Cepгeй Бopщ(733 знак., 28.01.2008 14:41)
        
        А, ну да, или так :-) =AlexD=(593 знак., 28.01.2008 15:12)
        
        неее... efOn тоже живет в ProcessMap, поэтому просто if(ProcessMap) не пройдет, efOn надо замаскировать перед проверкой. - Cepгeй Бopщ(28.01.2008 18:16)
        
        Я знаю :-). Но что плохого произойдёт в моём варианте, если с установленным efOn сработает верхняя ветка? Да ничего. Ничего не изменится :-) - =AlexD=(29.01.2008 07:59)
        
        Получится однобитный счетчик - на каждый "безответный" сигнал флаг будет инвертироваться. Cepгeй Бopщ(172 знак., 29.01.2008 14:22)
        
        8-0 С какого это бодуна он станет инвертироваться??? Впрочем с отказом от совмещения согласен. - =AlexD=(29.01.2008 15:19)
        
        Ну как же? Cepгeй Бopщ(701 знак., 29.01.2008 15:58)
        
        :-) ДобрО. Думаю это уже вполне рабочий вариант. - =AlexD=(30.01.2008 09:55)
        
        Кажется все же есть одна нестыковка. Пока только в уме ее прокрутил, может где-то и ошибаюсь. Cepгeй Бopщ(493 знак., 30.01.2008 18:19)
        
        А нужно ли? Это выглядит скорее как полезная фича, чем бага. - =AlexD=(01.02.2008 10:16)
        
        По логике работы надо. Вот если от момента wait() до получения управления произошли и signal() и таймаут - что должен вернуть wait()? Внес правку, вроде работает. Добро пожаловать в рассылку scmrtos-ru@googlegroups.com, там и обсудим. - Cepгeй Бopщ(01.02.2008 14:26)
        
        Ok. - =AlexD=(01.02.2008 14:36)
        
        Добавил тест. Попытался смоделировать все ситуации, вроде работает как в описании. - Cepгeй Бopщ(26.01.2008 01:06, ссылка)
        
        Просьба ко всем, у кого есть возможность - проверить этот код на "живых" проектах. - Cepгeй Бopщ(27.01.2008 15:07)
        
        У меня работает, но в моем проекте все флаги используются для общения между двумя процессами, т.е. каждый флаг захватывается только одним. Т.е. как хороший тест мой проект вряд ли годится. Argon(362 знак., 27.01.2008 18:33)
        
        Любой проект хорош. Я почти уверен, что в моем тесте не моделируются все возможные комбинации. Возможно, в вашем проекте вылезло бы какое-то неблагоприятное сочетание. Тут ведь главное не поломать то, что уже работало. Cepгeй Бopщ(768 знак., 27.01.2008 20:53)
        
        Если не сложно, вышлите на адрес Argon(27 знак., 27.01.2008 21:17)
        
        Сергей, в полученной версии обнаружил след. проблемы Argon(672 знак., 28.01.2008 12:30)
        
        Ой, ой. Теперь надо полный размер стека Idle указывать в scmRTOS_config.h Я писал себе памятку, на что обратить внимание при переползании с релиза 3.0: Cepгeй Бopщ(783 знак., 28.01.2008 18:23)
        
        Все, разобрался с последними. Заменил scmRTOS_config.h в папке с исходниками на новый и RESET_SYSTIMER_INT заменил на T0IR = T0IR (LPC21xx) по аналогии с прежним релизом. Вроде все работает. - Argon(28.01.2008 12:46)
        
        Ой. А я чего-то подумал, что у вас sam7. Положил порт LPC в upload - Cepгeй Бopщ(28.01.2008 14:51, ссылка)
        
        ага, пасиба, посмотрю - Argon(28.01.2008 14:53)
        
        порты для SAM7 и LPC ведь идентичны? Argon(539 знак., 28.01.2008 19:23)
        
        Все чудесатее и чудесатее :) Cepгeй Бopщ(895 знак., 28.01.2008 23:15)
        
        Все, разобрался! Был устаревший файл scmRTOS_TARGET_CFG.h от предыдущего релиза. Сбило с толку то, что он находится в папке с исходниками, потому не заменил сразу. - Argon(29.01.2008 09:24)
        
        Получил, спасибо! - Argon(28.01.2008 09:01)
        
        По логике вещей во всех портах есть эта проблема? - Argon(25.01.2008 16:42)
        
        Да. Но пока вы не будете будить процесс, ушедший в Wait(0) при помощи OS::ForceWakeUpProcess(), версия по ссылке должна вас спасти - Сергей Борщ(25.01.2008 18:23, ссылка)
        
        Опечатка: ClrPrioTag(Value, PrioTag); --> ClrPrioTag(Flags, PrioTag); - =AlexD=(25.01.2008 12:34)
        
        Да, безусловно, цикла быть не должно. А вот с потерей эвента, которого никто не ждёт - засада. - =AlexD=(25.01.2008 08:27)
        
        Да, проверил оба варианта, ваш и от AlexD. В обоих случаях проблема исчезла, спасибо! - Argon(23.01.2008 18:51)
        
        Хорошо, завтра внесу изменения. - Сергей Борщ(23.01.2008 19:22)
        
        Это не отменяет возможности исправить ошибку, проверить(!) исправления и сообщить автору. Ишь, нежные какие все. - =AlexD=(23.01.2008 15:01)
        
        Я уважаю работу других и авторское право, поэтому сразу не стал этого делать до консультации. Ну раз уж автор ОС не запрещает третьим лицам копаться во внутренностях, тогда Вы правы ;-) - Argon(23.01.2008 17:20, ссылка)
        
        добро пожаловать в опен-сорс. scmRTOS распространяется по MIT-лицензии. С кодом можно делать практически все что угодно, кроме как пытаться выдать его за свой собственный. - bialix_(25.01.2008 13:55)
        
        Более того, есть разнообразные средства обратной связи на ресурсе sf.net (для этого там ресурс и живет) - форум, система трекинга предложений и ошибок. Можно исправить и прислать diff отлаженного варианта, такой результат внести в исходники Sergey Pinigin(230 знак., 23.01.2008 19:06)

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