caxapa.ru :: Один момент! Вместо эвента получился бинарный семафор. Теряется совместимость. В общем, я так думаю, эвент нужно передавать через флаг в TBaseProcess шедулером. А это уже серьёзное перелопачивание.

=AlexD= (24.01.2008 08:01, просмотров: 197) ответил Сергей Борщ на Да, похоже это баг. Внесите его в багтрекер, чтобы не забылся. Счас сам занесу. Argon, вы можете проверить этот код, чтобы внести исправление? У меня сейчас нет возможности провести полноценное тестирование :(

Один момент! Вместо эвента получился бинарный семафор. Теряется совместимость. В общем, я так думаю, эвент нужно передавать через флаг в TBaseProcess шедулером. А это уже серьёзное перелопачивание.

Три кита на которых зиждется реклама: враньё, преувеличение, замалчивание. Новости СМИ - это политическая реклама.

Ответить

- Объясните подробнее, пожалуйста. Где получился семафор? - 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)

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