[Linux Embedded] архитектура прикладного ПО

ecos
http://www.opennet.ru/opennews/art.shtml?num=21017

Без особой надобности (и малыми силами коллектива и без опыта) сильно не завязывайтесь на linux.Так как только угрохаете кучу времени и не решите задачу.

Зависит от сложности проекта. Кстати, можно обойтись и одной нитью. P.S. Если нет опыта работы с говноосями типа eCos, не связывайтесь.

Ха ха. там хоть нормальная документация и стабильный api.
Тут же, сам черт ногу сломает как припрет ...

А зачем много потоков если ядро одно?

> Ха ха. там хоть нормальная документация и стабильный api.

Ха ха. Тебе по POSIX документации мало? Или POSIX нестабилен? Или в eCos свой, особый POSIX?

> А зачем много потоков если ядро одно?

Ыыыы... вот и выросло поколение на многоядерных процессорах.

Честно говоря, от разделения времени проку было на порядок больше чем от мощей POSIX. Такая задача была.
Собственно, я сам написал тогда RTOS (адский цейтнот был, а все готовое было корявым тогда или же слишком заумным и прожорливым к ресурсам)

>Ыыыы... вот и выросло поколение на многоядерных процессорах.
Что?

И да, особо донимала кривизна gcc на сборках busybox и uclibc.

>> А зачем много потоков если ядро одно?

Ыыыы... вот и выросло поколение на многоядерных процессорах.

Тут по моему просто дело в том, что человек от программирования далек.

> Честно говоря, от разделения времени проку было на порядок больше чем от мощей POSIX.

Теплое с мягким.

Интересно услышать, что не так с моим вопросом.

А это все ресурсы и время.

>>> А зачем много потоков если ядро одно?

Ыыыы... вот и выросло поколение на многоядерных процессорах.

Что?

Какая связь между использованием нитей и многоядерностью? Ответ: никакой.

> Интересно услышать, что не так с моим вопросом.

Допустим, вам надо обслужить 32 двоичных сигнала за 100 ms.

За каждым (или группой) сигналов стоит своя задача или алгоритм.
Иногда, это алгоритм может меняться.
Написать все это в однозадачном режиме можно, но лучше никогда не видеть и больше не сопровождать это.

В случае нескольких ядер, использование нескольких потоков может быть средством оптимизации. С одним ядром нет. Наверно я не понял исходную задачу.

>И да, особо донимала кривизна gcc на сборках busybox и uclibc.

Тулчейны с glibc не кривее десктопных.

С одним ядром - тоже. Например, если нужно выполнить длительную задачу и одновременно реагировать на другие события.

>Сейчас стоит концептуальный вопрос — использовать ли многопоточное монолитное приложение, или разбить на несколько процессов-серверов

Советую подумать, хватит ли ресурсов у железки на IPC в критичные моменты. Ещё, сколько человек будет писать код. Если много, можно каждому выделить своё отдельное приложение и не придётся совместно в одном коде копаться.

Речь была о uclibc.
И да, только отклоняетесь от i386 и сразу масса сюрпризов может быть.
И начиная с отсутствия патчей именно под ваш CPU для ядра.
Порой проще взять доки на чипсет и написать самому. Имхо.

Real-time это не к Linux. И не вижу проблем обрабатывать любое количество сигналов в одном процессе, со стороны сопровождаемости кода.

> Real-time это не к Linux.

Во-первых, это еще надо понимать, что задача лучше выпишется в Real-time. Ну да, грохнуть пеньком по дребезгу контактов - это самое то сегодня.

И не вижу проблем обрабатывать любое количество сигналов в одном процессе, со стороны сопровождаемости кода.

Именно, что не видите.

Я предполагал оптимизацию на эффективность вычислений, а не скорость ответа на внешние события. Но если так, то можно сказать да, хотя как то и не совсем.

Наверно есть больше требований, если надо прерывать обработку одних сигналов для обработки более приоритетных, то да все сложно.

«A Computer is a state machine. Threads are for people who can't program state machines.»

Alan Cox

> Real-time это не к Linux.

а мужики то и не знали ;)

Нет, все еще хуже может быть:

Ветвление алгоритма от различный состояний входов + временные технологические задержки.Тут «ифы» плодятся как тараканы уже и все становится нечитабельным.

Threads и Real-time - таки это разные вещи.

насколько я понял постановку задачи, делай монолит. деление на процессы здесь лишнее, нитей на pthreads будет более чем достаточно (или, если выберешь qtopia, то на QThread).

Кладем в очередь данные сигнала когда он приходит (в прерывании), в процессе обработчике вынимаем по одному и обрабатываем. Где ифы?

> деление на процессы здесь лишнее,

нитей на pthreads будет более чем достаточно (или, если выберешь qtopia, то на QThread).

Arm - это в лучшем случае как 300-ый пенек, и я бы не стал, не зная всех спецификаций и требований, впадать в категоричность.
Иногда, всплывают пару мерзких и пустяковых требований портящих писюкообразные подходы.

Очереди - это откладывание решение, буферизация.
А работу надо таки делать.

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

тонко

С этим к TC за подробным TЗ.

этот год я только с армами и работал (как системный программист),

И теперь в мире все похоже на армы и ваши задачи ?))

я что-то упустил и вы мне сейчас всё подробно расскажете, а?

Угу, нет четких требований от ТС. Тут можно долго лялякать ни о чем.

> И теперь в мире все похоже на армы и ваши задачи ?))

шутка не удалась, на кошках тренируйтесь… oh, wait…

Угу, нет четких требований от ТС.

ТС дал достаточно информации.

Тут можно долго лялякать ни о чем.

но вам же это так нравится! ;) и я вам тут не «лялякаю», сударь.

>ТС дал достаточно информации.

Ну это вам так кажется.
Один мой заказчик смог написать ТЗ только задним числом и уже по работающей системе. Я показал ему исходный вариант ТЗ и попросил найти похожие слова там.))

> Ну это вам так кажется.

ну это вам так кажется, что мне так кажется. намёк понятен?

С тобой все ясно.
зы: бесконечная самоуверенность и склонность к демонстрации своей крутости лечится только опытом и временем.))

а ничо так, самокритично, мне понравилось ;)

У тебя какой разряд по тенису ?

а ничо так, самокритично, мне понравилось ;)

А ты как думал ?
За двадцать пять лет в разработке самому приходилось на грабли наступать и на «подвиги» других смотреть.
Так что можешь не выпендриваться. Ничего нового тут нет , на любой хрен есть своя гайка с левой резьбой.))

сталкивался не с одним десятком разработчиков, которые «двадцать пять лет в разработке». по их коду можно написать десятитомник «как не нужно писать программы: примеры самых неудачных решений». «Так что можешь не выпендриваться».

> сталкивался не с одним десятком разработчиков, которые «двадцать пять лет в разработке». по их коду можно написать десятитомник

Ай какие мы крутые , а все дурные ...
Ок, я не буду больше отписывать на твои реплики.
Ты - прав, и прав всегда. Устраивает ?))

> Ок, я не буду больше отписывать на твои реплики.

> Устраивает ?))

вполне ;) а если в игнор добавите — вообще будет супер.

> вполне ;)

вот и чудненько.

а если в игнор добавите — вообще будет супер.

Ты не тянешь пока на игнор.
Игнор у меня для «наглючих толстолобиков» и «назойливых мух».)

> Ты не тянешь пока на игнор.

вот облом :( а авансом? я буду стараться, обещаю! ;)

> «A Computer is a state machine. Threads are for people who can't program state machines.»

Над тобой пошутили, а ты повелся.

> В случае нескольких ядер, использование нескольких потоков может быть средством оптимизации.

Какая связь между использованием нитей, несколькими ядрами и оптимизацией? Ответ: никакой.

Тебе уже сказали, что нити - это способ группировки задач по приоритетам (и логического разбиения задач тоже). А еще нити - это средство мультипрограммирования.

Не, ничего не выйдет. Не проси, не тужся и не трать на это время.)
Должны быть дела и по-важнее у тебя.
Возможно, я вновь не прав, а с этим тебе уже придется как-то жить и смирится.

Alan Cox прав как никогда.