caxapa.ru :: Мое предположение не подтвердилось. Следующее предположение!

Argon (20.01.2008 23:24, просмотров: 198) ответил Argon на Возможно, обнаружился баг scmRTOS.

Мое предположение не подтвердилось. Следующее предположение! Вставил Sleep(100) во втором процессе, перед насасыванием сэмплов, что должно было подтвердить догадку тем, что проблема исчезнет. Однако, она осталась. Значит, дело не в ошибке разруливания ОСи. Следующая догадка: Период опроса кнопок в 1-м процессе 50 мсек. В 3-м ожидание с периодом 10 мсек, что вероятно часто приводит к одновременному совпадению событий: 1. нажатие с установкой флага в 1-м процессе 2. исход времени Buttons.Wait(10) Но если дело в этом, то получается, что ОС принудительно сбрасывает Buttons по истечении этих 10 мсек? Это разве не баг?

Ответить

- Кроме меня кто-то сталкивался с таким багом? Еще раз его суть: при ожидании флага с таймаутом ОС сбрасывает флаг принудительно при исходе времени, что иногда влечет пропуски флага. - 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 контроллеры