caxapa.ru :: Или даже так:

=AlexD= (25.01.2008 12:50, просмотров: 154) ответил =AlexD= на Ещё нашёл опечатки, вобщем, гдето так

Или даже так: bool OS::TEventFlag::Wait(TTimeout timeout) { TCritSect cs; if (Value == efOn) { Value = efOff; return true; } else { TProcessMap PrioTag = GetPrioTag(Kernel.CurProcPriority); SetPrioTag(ProcessMap, PrioTag); // put current process to wait map ClrPrioTag(Kernel.ReadyProcessMap, PrioTag); // remove current process from ready map TBaseProcess* p = Kernel.ProcessTable[Kernel.CurProcPriority]; p->Timeout = timeout; Kernel.Scheduler(); ClrPrioTag(ProcessMap, PrioTag); // remove current process from wait list p->Timeout = 0; Value = efOff; if (Flags & PrioTag) // if waked-up by signal() or signal_ISR() { ClrPrioTag(Flags, PrioTag); // clear flag for current process return true; } return false; // otherwice waked-up by timeout or by OS::ForceWakeUpProcess() } }

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

Ответить

- Т.е. если ожидающих события нет - для них ставицца общий 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, ссылка)

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