Real-time Java, первая часть серии статей IBM developerWorks, описывающая реализацию систем реального времени средствами Java.

>>Тихо и шепотом - в жаве, не смотря на отсутствие malloc и его аналогов есть утечки памяти!

>Тихо и шёпотом - виртуальная машина Java от Bea умеет разрешать циклические ссылки и удалять не используемые объекты.

Сколько звеньев в циклических ссылках, которые она разруливает может быть? Как часто это делается? Можно ли контролировать моменты когда это деалется?

>> что-то мне подсказывает что будут через N лет реалтаймщики давитя, плакать но кодить на жаве.

>C РТ непосредственно не сталкивался, но за процессом разработки наблюдал - не будет там явы.

я писал и пишу для RT на С.

от жабы не отказался бы, честно-честно.

> я писал и пишу для RT на С.

> от жабы не отказался бы, честно-честно.

Причем именно от такой, которая по ссылке?

Я смотрю, все производители, каждый раз заявляют, что в ихней реализации жавы сборщик мусора способен удалить все, что надо во всех возможных случаях. При этом сборщик мусора такой быстрый, что он не будет тормозить ваше приложение. Мне это напоминает рекламу офтопа :) Помните, как там зазывают - "Наш новый оффтоп самый быстрый оффтоп, Только на нашем новом оффтопе вы полностью защищены от злых взломщиков и т д"

>> я писал и пишу для RT на С. от жабы не отказался бы, честно-честно.

>Причем именно от такой, которая по ссылке?

по ссылкам я на ЛОРе не хожу, традиция, понимаешь.

Но, скажу по секрету, жаба уже давно если не в RT то в embedded. Правда дороговата пока. Но такие киты как WindRiver, например, ее предлагают уже н помню сколько лет.

Кстати, господа, malloc'и в RT - моветон, так что не ломайте копья. И ссылку на javolution.org вообще-то полезно поглядеть, хоть мы и на ЛОРе ;-)

Да, тут окончательно начинаешь понимать, насколько опасен фанатизм и погоня за "новейшими" технологиями. Пейшите уже на Аде софт реалтаймовый, если Си так не любите, и не парьте адекватным людям мозг.

PS: Robotron, мне жаль вашу контору, если в ней совсем не умеют оценивать риски.

> по ссылкам я на ЛОРе не хожу

Жаль

> Кстати, господа, malloc'и в RT - моветон

Не придирайся к словам. malloc или самописанный pool_alloc - неизбежны.

>malloc или самописанный pool_alloc - неизбежны. Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

>...мне жаль вашу контору, если в ней совсем не умеют оценивать риски.

Какие риски?

>> malloc или самописанный pool_alloc - неизбежны.

> Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

ОК, пусть "неизбежны в сложных приложениях".

Во, с этого места можно поподробнее:

1. Почему не отказались бы?

2. От какой именно жабы? Той, которая по ссылке - или той, которая обычная j2se-шного разлива?

РТ система - это простая система. Жаба таковой не является.

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

> Какие риски?

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

>>> malloc или самописанный pool_alloc - неизбежны.

>> Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

>ОК, пусть "неизбежны в сложных приложениях".

Шо есть, то есть. Только не стоит забывать, что в РТ програмист должен занть к чему приведет каждый вызов менеджера кучи, а в жаве с этой стороны полная неопределенность :(.

Нет, я не против gc, но помоему в РТ, он будет больше мешать, чем помогать.

> Нет, я не против gc, но помоему в РТ, он будет больше мешать, чем помогать.

Народ, приучайтесь ходить по ссылкам :) Там написано, как они собираются решать проблему - и эти способы решения делают из Java что-то другое. И лично мне из статьи осталось непонятно, как realtime часть приложения будет взаимодействовать с не-realtime частью в рамках одной JVM. А если они должны быть разнесены по разным JVM - зачем тогда огород городить? Сделать критичное на Си/Си++, а остальное - на чем угодно в другом процессе.

Сходил. ВМ там помоему одна. А вот в управление памятью до конца не вьехал. malloca не видать, про недостатки gc расказывают, но получается, что его же и юзают. :~

>>> malloc или самописанный pool_alloc - неизбежны.

>> Существует много случаев, когда можно 1 раз при старте память откусить ( с запасом ), а потом забыть, что существует куча :)

>ОК, пусть "неизбежны в сложных приложениях".

да неправда это, OSEK-like OS + специализированные сетевые стеки + управление NVRAM + таймеры + специализированноe run-time environment + ...

и ни одного malloc, XXXalloc и т.п. одна статика (но с жуткой динамикой на этапе конфигурации системы, никаким __alloc'ам не снилось)

проектировать надо уметь ;-)

>Во, с этого места можно поподробнее:

>1. Почему не отказались бы?

навскидку

A) недостижимая для С абстракция от платформы (железо, компилятор, модели памяти). в С полностью абстрагироваться можно только препроцессором, а это отвратительная гадость...

Б) очень хорошие возможности для моделирования - практически любой модуль можно тестировать отдельно

B) переносимость, пусть не идеальная, но гораздо лучше чем в С.

можно еще чего вспомнить, лень просто

>2. От какой именно жабы? Той, которая по ссылке - или той, которая обычная j2se-шного разлива?

j2se исключается конечно, по ссылкам некогда ходить, звиняйте.

сборка мусора честно говоря не очень-то и нужна, javolution хороший пример (но не единственный)

>>ОК, пусть "неизбежны в сложных приложениях".

>да неправда это, OSEK-like OS

С OSEK не знаком. А вообще не надо доводить до маразма - всегда можно захватить всех ресурсов по максимуму, и не пользоваться malloc. Но вот ресурсов на это может не хватить.

> A) недостижимая для С абстракция от платформы (железо, компилятор, модели памяти). в С полностью абстрагироваться можно только препроцессором, а это отвратительная гадость...

Согласен. Доп. вопрос: использование более осмысленных препроцессоров не помогает? Стандартный препроцессор действительно туп до невозможности.

>С OSEK не знаком. А вообще не надо доводить до маразма - всегда можно захватить всех ресурсов по максимуму, и не пользоваться malloc. Но вот ресурсов на это может не хватить.

на самом деле в embedded система всегда конфигурируется до runtime, там и ресурсы распределяются как надо, это конечно сложная штука, но жутко интересная, в OS общего назначения не встречается, поэтому мало кому известна

> всегда конфигурируется до runtime

Как я понял, на этом и играет java на смарт картах - объявляется, что gc не является узким местом, потому что "garbage" как такового нет by design. Если, конечно, design правильный;)

> Согласен. Доп. вопрос: использование более осмысленных препроцессоров не помогает? Стандартный препроцессор действительно туп до невозможности.

да, частично эту проблему можно решить доп-средствами, и на самом деле так и делается, но это не панацея к сожалению. Универсальных доп-средств нет, кроме ANSI-С препроцессора со всеми последствиями.

> на самом деле в embedded система всегда конфигурируется до runtime

embedded-системы бывают сильно разные.

> в OS общего назначения не встречается, поэтому мало кому известна

очень даже встречается

>> на самом деле в embedded система всегда конфигурируется до runtime

>embedded-системы бывают сильно разные.

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

> я имел в виду нормальные технические решения

Во всех системах для RT/embedded, которые я знаю, есть malloc. Использование malloc является признаком "ненормального" технического решения?

> демпинг на бесплатности

o_O

>Во всех системах для RT/embedded, которые я знаю, есть malloc. Использование malloc является признаком "ненормального" технического решения?

Oh, Yes! Windriver прямо не советует использовать кучу для RT, хотя malloc в VxWorks изначально.

>> демпинг на бесплатности

>o_O

ага, коммерчески linux умопомрачительно выгоден, но как только пойдет жесткая конкуренция и большие тиражи он не справится с footprint'ом

впрочем для industrial (если его не путать с embedded) уже похоже нет альтернативы linux, QNX на этом похоже и загнется.

> Windriver прямо не советует использовать кучу для RT, хотя malloc в VxWorks изначально.

в критических участках - наверное. а вообще, пулы с фиксированными накладными расходами на malloc строить.

> linux умопомрачительно выгоден, но как только пойдет жесткая конкуренция и большие тиражи он не справится с footprint'ом

зависит от объемов памяти, наверное... накладные расходы могут оказаться приемлемыми.

> для industrial (если его не путать с embedded)

я бы сказал, что они частично перекрываются :)

> QNX на этом похоже и загнется.

Охх... Жаль будет. Все-таки технически это очень интересная система.

а чем она интересна?

Много ли микроядерных систем справились стать коммерческим явлением? winnt & macosх просьба не беспокоиться - первая перестала быть мироядерной еще в нт4, вторая и не была никогда - там bsd было запихано в ядро с самого начала.

>> QNX на этом похоже и загнется.

> Охх... Жаль будет. Все-таки технически это очень интересная система.

только в узкой области - в ядре, в плане полноценного решения (обвязки, протоколы, средства разработки, спектр поддержки платформ) она всегда была достаточно убога и отставала от Windriver и GHS, на чем и погорела, хороший промышленный UNIX и только.

> вопрос в другом зачем java в обработке RT?

Чтобы Томми больше не убивался.

Там денег просют вроде. Здесь (http://www.research.ibm.com/people/d/dfb/papers/Bacon03Realtime.pdf) - свободно.

> A) недостижимая для С абстракция от платформы

Эээээ а зачем абстрагироваться при разработке embedded ?

> очень хорошие возможности для моделирования - практически любой модуль можно тестировать отдельно

Ну с моделированием ясно... когда надо "хочу прям щас"

> переносимость, пусть не идеальная, но гораздо лучше чем в С.

Опять же РТ и embedded тут никаким боком...

PS: Хотя конечно если некеому R&D не захотелось позагорать лишь под конец проекта находя в себе силы рожать одноглазых буратин в косметике...

> и ни одного malloc, XXXalloc и т.п. одна статика (но с жуткой динамикой на этапе конфигурации системы, никаким __alloc'ам не снилось)

А) Про динамическую масштабируемость можно забыть

Б) От интеграции заранее отбиваться руками и ногами (ну не поймет клиент зачем ему вразрезы таких фиговин лепить отдельные сервера в качестве лоадбалансеров)

>> A) недостижимая для С абстракция от платформы

>Эээээ а зачем абстрагироваться при разработке embedded ?

очень просто - в embedded железо имеет свойство сменяться со страшной скоростью, а если железо не меняется меняются компиляторы, а если компиляторы не меняются меняются модели памяти, свичи, и т.д. и т.п.

вот у меня пример был когда один и тот же модуль надо одновременно на 16-ти платформах тянуть. бр-р-р. А один компилятор хочет чтобы ему "far int *a;" писали, а другой чтобы обязательно "int * far a;" и др. веселые картинки. Ну про линкеры на ночь глядя не буду ничего писать...

>А) Про динамическую масштабируемость можно забыть

не совсем так, если нужна динамика, то она с лихвой покрывается дискретным набором конфигураций

>Б) От интеграции заранее отбиваться руками и ногами (ну не поймет клиент зачем ему вразрезы таких фиговин лепить отдельные сервера в качестве лоадбалансеров)

про сервера не понял, но интеграция делается на ура. клиенту кроме target софта поставляется среда конфигурирования, проектирования, опимизирования конфигураций и т.п. и реально возможно стыковать модули разных производителей.

> и т.д. и т.п.

Хммм... прям настолько быстро ? (кроме шуток, в пределах одного брэнда железо меняется достаточно редко).

> А один компилятор хочет чтобы ему

#ifdef + хороший RCS

Хотя каждому свой терем ближе...

> то она с лихвой покрывается дискретным набором конфигураций

А стоимость ?

> про сервера не понял

Имелось ввиду ситуации когда железка становится "узким местом". Cкорости растут быстрее чем развивается оборудование и железки масштабирующиеся путем количественного наращивания очень быстро вытесняются. Учитывая, что большинство целевой аудитории таких комплексов помешано на резервировании.

>Хммм... прям настолько быстро ? (кроме шуток, в пределах одного брэнда железо меняется достаточно редко).

по разному бывает, иногда контора производит и продает только софт

>> А один компилятор хочет чтобы ему

>#ifdef + хороший RCS

ну да, но только таких мелочей много набегает, и С код лишается даже убогого контроля ANSI-компилятора

>> то она с лихвой покрывается дискретным набором конфигураций

>А стоимость ?

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

Ява в обработке RT (или, как в моем случае, квази-RT) нужна ровно по тем же причинам, что и везде -- для переносимости и для удобства. Удобства для программиста и для пользователя: одна система, один гуй, одни и те же кнопки и никаких левых библиотек не надо тащить за собой каждый раз -- только JRE надо для работы.


в нашем случае реально мы своей разработкой заменили монстра (написанного на це/це++, кстати), работающего (не ползающего) на двухядерном серваке, с 2 гигами памяти, с базой данных и прочей enterprise-мутью на маленькую прогу (ну сравнительно маленькую: 300K собственных классов - это не так уж и мало) на яве. так вот наше полностью кроет этого монстра по функциональности и работает при этом даже на ноуте 5-ти летней давности (p3-128Mb ram). Повторяюсь - работает оно, даже на таком Г. Собирает данные с десятка сейсмических станций в квази-реалтайм (каждая станция льет данные по UDP серваку с некоторыми интервалами), раздает эти данные клиентам на обработку и никаких проблем мы не имеем.


А монстр на це/це++ даже жить на таком железе отказывается, не то что работу делать. :)

>Ява в обработке RT (или, как в моем случае, квази-RT) нужна ровно по тем же причинам, что и везде -- для переносимости и для удобства...

Какую Java использовали, J2SE или Real Time Java?

> Ява в обработке RT (или, как в моем случае, квази-RT) нужна ровно по тем же причинам, что и везде

То есть у тебя была не RT-задача - ну и тогда к чему ты это?

> так вот наше полностью кроет этого монстра по функциональности и работает при этом даже на ноуте 5-ти летней давности (p3-128Mb ram).

Конечно, бывают фантастически плохо написанные программы на Си++, но почему-то я тебе не верю... или ты не всё рассказал.

сразу на оба вопроса ответ.

использовалась Java 5.0 SE

задача таки RT. просто счет идет не на миллисекунды отклика, но данные пропускать таки нельзя, иначе не хватит пропускной способности сети на лишние перепосылки (там 1/10 Mbit по WiFi в плохих условиях приема), да и буфер у сейсмостанций небольшой..

бывают не просто плохо написанные це++ программы. бывают монстры, разрабатывающиеся на протяжении 20 лет и бывает чудовищная служба поддержки, которая единичный глюк в таких вот монстрах не может исправить за полгода. они на нас забили - мы на них забили и сделали замену. у них глюк до сих пор не устранен, а у нас свой продукт, заменяющий их продукт.

подробностей не будет, из-за комм. тайны (они еще и партнеры) и анти-рекламы делать нельзя. Но факт остается фактом - на яве можно делать промышленные пакеты. можно делать лучше, чем на це++. причем не хуже и за более короткий срок, нежели срок устранения единичной ошибки в старом >1M строк це++ проекте.

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

А какая либа использовалась для взаимодействия Java и WiFi?

> задача таки RT. просто счет идет не на миллисекунды отклика

Если время реакции - порядка секунд, то всё равно, на чем писать :)

> бывают не просто плохо написанные це++ программы. бывают монстры, разрабатывающиеся на протяжении 20 лет

> можно делать лучше, чем на це++.

ИМХО, пример, мягко говоря, нетипичный - переписывание корявого монстра возрастом 20 лет в условиях РВ с очень мягкими директивными сроками.

> факт остается фактом - на яве можно делать промышленные пакеты.

Никто и не сомневается, Я, в общем-то, не против Java - но ее особенности делают ее применение в системах со коль-нибудь жестким РВ невозможным, а без этих особенностей Java - не Java, а что-то другое. После чего встает вопрос - а нужно ли?

Как Java с WiFi связали???

> Как Java с WiFi связали???

Средствами ОС, наверное :)