aoreh (10.12.2013 11:32, просмотров: 360) ответил fk0 на Без механизма ожидания более чем одного события одновременно в принципе невозможно строить некоторые алгоритмы управления, в 10-й раз повторяю. На практическом примере: когда, например, стиральная машина должна остановиться когда сработал датчик-
- По существу ответить нечего, вопрос исчерпан? Приведи пример для 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)
- Я не прав. Реализовать можно всё что угодно. Но средства и методы... дописать отсутствующий функционал к оси -- лучший вариант. Остальное выливается в тормозное bloatware. - fk0(10.12.2013 15:44)
- судя по всему, товарищ знает много теории, но не умеет использовать ее на практике... - aoreh(10.12.2013 13:58)
- Замечательно! Может все же укажете алгоритм, который невозможно реализовать в RTOS без WaitForMultipleObjects? - LightElf(10.12.2013 15:27)
- Товарищ различает т.н. Event Object и Message Queue. - fk0(10.12.2013 13:50)
- Еще раз... Ожидание события из очереди, пока там нет событий - спим, появилось - поток просыпается - обрабатывает. В очеред можно поставить событие как по кнопке, так и по датчику, какой еще грязный трюк? - 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)
- Ооо... уже дошли до того, что никсовые оси то же недооси, с костылями вокруг сигналов? бугагага... - 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:26)
- Вещь принципиально необходимая если алгоритмы управления подразумевают ветвление, а не линейное исполнение 1->2->3->4... Если мы пытаемся попросту имеющийся "не линейный" конечный автомат переписать в рамках такой ОС. Альтернативу мы уже видели fk0(226 знак., 10.12.2013 15:03)
- бред, а не тезис, нет, что бы не перегружать ос для цпу с минимальными ресурсами не столь сверхнеобходимой вещью, но с другой стороны таже фриртос - в исходниках, добавь туда это, если сильно надо, много времени не займет ни добавление, ни отладка - aoreh(10.12.2013 14:54)
- uCOS первой версии не имела event flags, потом ввели. Что ещё? В сколько-нибудь "большой" ОС есть какой-либо механизм ожидания множества событий, хоть и примитивный (vs WaitForMultipleEvents из windows). В игрушечных ОС его нет просто потому, что fk0(61 знак., 10.12.2013 14:48)
- И в догонку, причем тут freeRTOS и кто сказал что она любимая? хотя, думаю, ее можно оочень неплохо использовать в своих нуждах, каждому свое. - aoreh(10.12.2013 14:40)
- Вдогонку. В более приличных RTOS, вроде TNKernel и других *TRON подобных, в eCOS, в RTEMS... есть event flags, например, для того. В любимой FreeRTOS -- нет. В выросших из unix -- нет (и родные IPC там тем же страдают), но там есть асинхронные fk0(17 знак., 10.12.2013 14:35)
- Если подразумевается publisher-subscriber pattern, то ничего волшебного кроме того, что излишне избыточно на пустом месте (т.е. вместо легковесного события, просто разблокирующего поток в нормальной ОС, у нас на каждый чих будут сообщения через fk0(121 знак., 10.12.2013 14:26)
- какая разница на чьей стороне этот костыль? Почему волшебный? что в мэпах и списках волшебного? - aoreh(10.12.2013 14:19)
- Всё это сложные искусственные механизмы призванные исправить очевидный недостаток: невозможность ожидания множества событий в одном потоке. Иными словами говоря -- костыли и подпорки. Ожидать в одном потоке -- та же проблема. Этот волшебный поток fk0(28 знак., 10.12.2013 14:17)
- То, что нужно знать о их существовании вообще-то. Т.е. следуя такой логике драйвер клавиатуры должен знать о всех программах, которым захочется получать коды клавиш. - 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)
- Действительно, какой-то откровенный неадекват попёр. - SciFi(10.12.2013 14:05)
- А как быть? Откуда драйвер узнает кому посылать сообщение? Пусть не клавиатура. Пусть датчик воды в стиральной машине. Которым может интересоваться несколько параллельных потоков. Причём в некоторых моделях машины их только 5, а в некоторых все fk0(67 знак., 10.12.2013 14:17)
- не нужно ничего знать в драйвере, не нужно фантазировать - aoreh(10.12.2013 13:57)
- та можно реализовать события со списками подписчиков, можно ожидать все в одном потоке, в нем отдавать на обработку в нужный, можно вообще, как рекомендуют часто иметь минимум потоков, один - получающий события, и отдающий их на обработку любому aoreh(129 знак., 10.12.2013 13:54)
- Трюк, опять трюк. В данном случае трюк в том, что нет как такового события специфичного для источника события. Источник событий _должен_ _знать_ _о_ _получателе_ и класть сообщение в его message-box, fifo, очередь, как ни назови. Такой подход fk0(300 знак., 10.12.2013 13:36)
- Товарищ наверно под Windows не писал оконную процедуру. - LightElf(10.12.2013 12:39)
- По существу ответить нечего, вопрос исчерпан? Приведи пример для libpthreads (без асинхронных сигналов) или windows (с ожиданием одиночного события), как быть в такой ситуации. Если и приведёшь, то там будет грязный трюк с проверкой "флагов" fk0(246 знак., 10.12.2013 11:47)