caxapa.ru :: не касаемо прототреадс, а ртос вообще... вот сколько раз вижу этот твой конец света без вэйтформногоевентс и просто понять не могу, что мешает использовать очередь (приоритетную, если нужно)? тем более, как ты сам отмечал, пока событие

aoreh (10.12.2013 03:07 - 03:25, просмотров: 266) ответил fk0 на Нет. Большинство т.н. RTOS "любительского уровня" позволяют ожидать _одно_ событие одновременно. Не надо объяснять, что это годится только для "линейных" автоматов (с переходами строго 1->2->3->4...) ? Попытка закодировать сколько-нибудь сложный

не касаемо прототреадс, а ртос вообще... вот сколько раз вижу этот твой конец света без вэйтформногоевентс и просто понять не могу, что мешает использовать очередь (приоритетную, если нужно)? тем более, как ты сам отмечал, пока событие не обработано, его второй раз взводить нельзя, т.е. макс. глубину этой очереди еще и легко просчитать

Ответить

- Если б у бабушки был... А где в protothreads очередь? Нет eё. Такой подход применён в quantim leaps (теперь state-machine.com), когда события записываются в очередь, а после извлекаются и дальше... а дальше имеем ситуацию как в автомате: в fk0(1841 знак., 10.12.2013 09:56 - 09:58)
  - Я ж написал "не касаемо прототреадс, а ртос вообще". У тебя это необходимая фишка номер один в любом упоминании и обсуждении любой ртос - aoreh(10.12.2013 10:34)
    - Так и есть. Допустим, у нас 4 состояния и есть переходы не только 1->2->3->4, а между любыми состояниями, в зависимости от внешних событий и состояния. Как без "фишки" спрашивается это записать? Вот Зелёный даёт пример: while (1) { if (event)... fk0(171 знак., 10.12.2013 10:50)
      - _(зевая) От переноса кода этой проверки в супервизор, издержки не уменьшаться - Скрипач(10.12.2013 13:43)
        
        Нет. Супервизор может быть устроен таким образом, что проверка будет не в цикле, а выполняться вовсе один раз. Вообще-то все нормальные RTOS так устроены, для того вообще-то ОС и нужна. Для этого внутри обычно очереди есть. Не событий, а ожидающих fk0(35 знак., 10.12.2013 13:52)
        
        Дайте пример. Пусть, для опроса нескольких контактов с гашением дребезга. - Скрипач(10.12.2013 13:57 - 14:02)
        
        Речь о работе планировщика. Причём здесь контакты? Подробности можно подсмотреть в uCOS, автор книгу написал, там всё есть. - fk0(10.12.2013 14:21)
        
        Вы рассписываете некий ПРИНЦИП. Покажите его на простом примере. Не почтите за труд, уважьте старика. - Скрипач(10.12.2013 14:27)
        
        Какой-либо поток ожидает, например события (поступление данных в fifo, семафора, да не важно чего). Есть очередь связанная с событием (внутри ОС). И при вызове функции ожидания ОС помещает поток в эту очередь. Дальше ОС никак не затрагивает поток fk0(972 знак., 10.12.2013 14:40 - 14:42)
        
        Я, извините, просил показать НА ПРОСТОМ ПРИМЕРЕ. (два входа с дребезгом) В чем экономия переноса опроса входов в ОС? - Скрипач(10.12.2013 14:46)
        
        Экономия не в переносе входов в ОС, а в другом механизме взаимодействия драйвера клавиатуры и использующих её модулей. - fk0(10.12.2013 14:59)
        
        :) - Скрипач(10.12.2013 15:03)
      - чем ид евента (или некая дополнительная инфа из него) будет хуже номера сработавшего евента из массива евентов переданного в вэйтфоревентс? - aoreh(10.12.2013 11:04)
        
        Ничем. Но причём это. Нет возможности одновременно ожидать все нужные события. А есть возможность, например, ожидать только _одно_ событие вообще (хотя обычно два -- часто есть таймаут). Да и не нужна она, возможность эта, наверное. Если fk0(133 знак., 10.12.2013 11:09)
        
        Притом, что ты в каждой, абсолютно в каждой теме про ртос пишешь, что без этого никуда, я же пытаюсь тебе сказать, что без этого ни чем не хуже, может, иногда, менее удобно, но не хуже. aoreh(184 знак., 10.12.2013 11:14)
        
        Без механизма ожидания более чем одного события одновременно в принципе невозможно строить некоторые алгоритмы управления, в 10-й раз повторяю. На практическом примере: когда, например, стиральная машина должна остановиться когда сработал датчик fk0(720 знак., 10.12.2013 11:26)
        
        ...без этого невзможно. При этом речь идет о некоем абстрактном принципе, которым никто (даже заявивший) не пользуется. - Скрипач(10.12.2013 13:46)
        
        А-ха-ха! А где в стиральной машине батарейка? Да проверяй условия хоть 100500 раз в секунду! Это же стиральная машинка, а не космический корабль! - SciFi(10.12.2013 12:05)
        
        Вот это -- серьёзный аргумент. - fk0(10.12.2013 13:54)
        
        Именно так. Я просто напоминаю, что совсем не плохо, когда инструмент адекватен задаче. Кроме того, "преждевременная оптимизация..." - ну, вы помните. Далеко не во всех задачах требуется микропотребление. - SciFi(10.12.2013 14:03)
        
        даешь по VxWorks-у в каждую стиралку! иначе - никак - aoreh(10.12.2013 14:06)
        
        LG давно делает компьютеры со встроенным холодильником... - fk0(10.12.2013 14:13)
        
        no comments... - aoreh(10.12.2013 14:18)
        
        О майн гад... Ты вообще разработчик или преподаватель информатики??? Я просто в шоке от этого бреда... - aoreh(10.12.2013 11:32)
        
        По существу ответить нечего, вопрос исчерпан? Приведи пример для libpthreads (без асинхронных сигналов) или windows (с ожиданием одиночного события), как быть в такой ситуации. Если и приведёшь, то там будет грязный трюк с проверкой "флагов" fk0(246 знак., 10.12.2013 11:47)
        
        Товарищ наверно под Windows не писал оконную процедуру. - LightElf(10.12.2013 12:39)
        
        Товарищ различает т.н. Event Object и Message Queue. - fk0(10.12.2013 13:50)
        
        Замечательно! Может все же укажете алгоритм, который невозможно реализовать в RTOS без WaitForMultipleObjects? - LightElf(10.12.2013 15:27)
        
        Я не прав. Реализовать можно всё что угодно. Но средства и методы... дописать отсутствующий функционал к оси -- лучший вариант. Остальное выливается в тормозное bloatware. - fk0(10.12.2013 15:44)
        
        Вопрос об Multiple Events регулярно всплывает в конфе FreeRTOS и регулярно Барри обламывает страждущих. Это просто невозможно реализовать хорошо. Получается связь "многие к многим", что выльется в хождение по спискам внутри критической секции LightElf(96 знак., 10.12.2013 18:42)
        
        Уже который человек который раз просит тебя привести конкретный алгоритм! Хватит словоблудия. Хотя чем больше ты пишешь, тем больше убеждаюсь, что ты к практике вообще не причастен, давай, признавайся, где и что ты преподаешь? - aoreh(10.12.2013 15:58)
        
        так он уже дважды приводил, он не умеет обрабатывать клавиатуру, кроме как WaitForMultipleObjects, причем обязательно в нескольких потоках. :))))) - aoreh(10.12.2013 15:42)
        
        судя по всему, товарищ знает много теории, но не умеет использовать ее на практике... - aoreh(10.12.2013 13:58)
        
        Еще раз... Ожидание события из очереди, пока там нет событий - спим, появилось - поток просыпается - обрабатывает. В очеред можно поставить событие как по кнопке, так и по датчику, какой еще грязный трюк? - aoreh(10.12.2013 12:00)
        
        Трюк, опять трюк. В данном случае трюк в том, что нет как такового события специфичного для источника события. Источник событий _должен_ _знать_ _о_ _получателе_ и класть сообщение в его message-box, fifo, очередь, как ни назови. Такой подход fk0(300 знак., 10.12.2013 13:36)
        
        вариантов решения - масса, никакого трюкачества. Или так - любое программирование - набор трюков - aoreh(10.12.2013 13:52)
        
        А что мешает оповещать каждый ожидающий поток о событии? Религия? - SciFi(10.12.2013 13:41)
        
        та можно реализовать события со списками подписчиков, можно ожидать все в одном потоке, в нем отдавать на обработку в нужный, можно вообще, как рекомендуют часто иметь минимум потоков, один - получающий события, и отдающий их на обработку любому aoreh(129 знак., 10.12.2013 13:54)
        
        Всё это сложные искусственные механизмы призванные исправить очевидный недостаток: невозможность ожидания множества событий в одном потоке. Иными словами говоря -- костыли и подпорки. Ожидать в одном потоке -- та же проблема. Этот волшебный поток fk0(28 знак., 10.12.2013 14:17)
        
        какая разница на чьей стороне этот костыль? Почему волшебный? что в мэпах и списках волшебного? - aoreh(10.12.2013 14:19)
        
        Если подразумевается publisher-subscriber pattern, то ничего волшебного кроме того, что излишне избыточно на пустом месте (т.е. вместо легковесного события, просто разблокирующего поток в нормальной ОС, у нас на каждый чих будут сообщения через fk0(121 знак., 10.12.2013 14:26)
        
        Вдогонку. В более приличных RTOS, вроде TNKernel и других *TRON подобных, в eCOS, в RTEMS... есть event flags, например, для того. В любимой FreeRTOS -- нет. В выросших из unix -- нет (и родные IPC там тем же страдают), но там есть асинхронные fk0(17 знак., 10.12.2013 14:35)
        
        У FreeRTOS своя специфика. Она очень детерминированная. Хождение по спискам автор обходит любой ценой. EventFlag требует обхода списка переменной длины. - LightElf(10.12.2013 15:36)
        
        Да там полно всяких списков. Может я конечно не понял, на счёт очень детерминированной. Может в этом глубокий смысл. Но мне почему-то кажется... что это из той же области, почему TLS нет из коробки (я понимаю, его легко сделать). - fk0(10.12.2013 15:51, ссылка)
        
        Списков там конечно навалом, но всячески избегается хождение по ним туда-сюда-обратно в рантайме. Потому, например, свой список задач для каждого уровня приоритета. Отдельный список для спящих задач. Список задач, ожидающих на семафоре LightElf(406 знак., 10.12.2013 19:12)
        
        Ооо... уже дошли до того, что никсовые оси то же недооси, с костылями вокруг сигналов? бугагага... - aoreh(10.12.2013 14:38)
        
        И в догонку, причем тут freeRTOS и кто сказал что она любимая? хотя, думаю, ее можно оочень неплохо использовать в своих нуждах, каждому свое. - aoreh(10.12.2013 14:40)
        
        uCOS первой версии не имела event flags, потом ввели. Что ещё? В сколько-нибудь "большой" ОС есть какой-либо механизм ожидания множества событий, хоть и примитивный (vs WaitForMultipleEvents из windows). В игрушечных ОС его нет просто потому, что fk0(61 знак., 10.12.2013 14:48)
        
        бред, а не тезис, нет, что бы не перегружать ос для цпу с минимальными ресурсами не столь сверхнеобходимой вещью, но с другой стороны таже фриртос - в исходниках, добавь туда это, если сильно надо, много времени не займет ни добавление, ни отладка - aoreh(10.12.2013 14:54)
        
        Вещь принципиально необходимая если алгоритмы управления подразумевают ветвление, а не линейное исполнение 1->2->3->4... Если мы пытаемся попросту имеющийся "не линейный" конечный автомат переписать в рамках такой ОС. Альтернативу мы уже видели fk0(226 знак., 10.12.2013 15:03)
        
        т.е. ты так считаешь, что реализация внутри ос без оверхида? :)))) - aoreh(10.12.2013 15:26)
        
        Он может быть существенно меньший, чем подписка на сообщения через fifo или опрос. - fk0(10.12.2013 15:47)
        
        может быть, а может и не быть. Те же списки, те же очереди, только внутри, но вот разница будет в том, что внутри это будет универсальный механизм, а снаружи - решение заточенное под задачу, так что будет скорее наоборот - aoreh(10.12.2013 15:56)
        
        То, что нужно знать о их существовании вообще-то. Т.е. следуя такой логике драйвер клавиатуры должен знать о всех программах, которым захочется получать коды клавиш. - fk0(10.12.2013 13:54)
        
        не нужно ничего знать в драйвере, не нужно фантазировать - aoreh(10.12.2013 13:57)
        
        А как быть? Откуда драйвер узнает кому посылать сообщение? Пусть не клавиатура. Пусть датчик воды в стиральной машине. Которым может интересоваться несколько параллельных потоков. Причём в некоторых моделях машины их только 5, а в некоторых все fk0(67 знак., 10.12.2013 14:17)
        
        а зачем ему знать об этом? - aoreh(10.12.2013 14:18)
        
        Опять 25. Сам же выше пишешь, мол источник события посылает их в fifo принадлежащий получателю. А откуда он узнает какие получатели есть? - fk0(10.12.2013 14:20)
        
        Действительно, какой-то откровенный неадекват попёр. - SciFi(10.12.2013 14:05)

Микроконтроллеры AVR