Ответ на »сообщение 1002« (Илья Ермаков)
___________________________
Хотелось бы услышать аргументированное мнение про применимость Явы в СРВ. Ведь изначально язык для этой области не предназначался, Sun вроде бы всегда предупреждала о неприменимости его для СРВ...
1. Не "наколенная разработка", а - промышленный стандарт, за которым стоит не "контора дяди Никанора".
2. Огромный объём наработанных библиотек и технологий.
3. Наличие (по крайней мере) двух "консорциумоподдерживаемых" спецификаций на системы реального времени.
4. esmertec.com и дальше по ссылкам... :о)

Хотя, конечно, по мне бы так лучше бы так Ада с Оберонами поддерживались...
Хотя, с gnat-ом можно получать связку Ада-кода со скомпилированными в натив-код ява частями. Но это уже сфера околошаманских компромиссов.

Ответ на »сообщение 1004« (Cardinal)
___________________________
То есть Bluebottle...
Нет.
Или надо запрещать для своих приложений сборку мусора... Хотя, тогда на кой всё остальное без этого? :о)
+ для себя-то я запрещу, а что будет происходить в остальной части операционки, я же не знаю... В смысле отношения этой части с СМ...

Хотя... С другой стороны, по опытк работы убеждаюсь, что выгодно (и правильно!) всё большую "числодробительную" часть выносить в спец железяки, а компом осуществлять только "релейно-событийное управление-отображение". Опять же классика "клиент-сервер". Сочетание в коллективе хорошего куниксоида-системщика + хорошего специалиста по контроллерам + FPGA (+, изредка DSP) даёт отличные резултаты. При особом старании "железячников", программисты и на винде всю интерфейсную с пользователем часть могут сделать.
По стуи дели "чего лучше" нет. Есть грамотное проектирование, исходя из имеющихся: денег, рабочей силы и средств реализации. Наша система была повторена местными спецами (по сути скопирована её функциональность) на винде + дельфи + спец плата на рассыпухе и FPGA (PCI-шина). Сравните: здесь работало с наворотами порядка 50-ти человек лет пять, там отец с сыном-первокурсником полтора года. По опыту общения с ними, стало понятно, что в немалой степени успех обеспечен: 1) многое просто переписалось из исходников 2)язык и среда разработки. Причём второе для них оказалось скорее первым... :о) Прменяя тот же CodeGuard, они в наших кодах  ошибки нашли.
Моё отношение к отладке и отладчикам эта работа кардинально изменила. :о)
Это - первая программа, которую должны разрабатывать при проектировании ОС. Хорошо рассуждать об отсутствии острой необходимости в нём только тем, кто работает с простыми проектами и демонстрационными поделками... и если он постоянно под рукой. 20 секунд и полсотни нажатий кнопки пошагового прохождения, стоят часа-двух написания "вывода в контрольных точках", а потом разгребания дампов мегобайтов отладочных сообщений... "Уверяю вас!" :о)
Причём учтите, что ситуация кардинально усугубляется общим уровнем исполнителей...

Ответ на »сообщение 1003« (Cardinal)
___________________________
То есть Bluebottle...

Ответ на »сообщение 1001« ()
___________________________
Может ли Active Oberon быть полноценной заменой QNX?

Ответ на »сообщение 1001« ()
___________________________
Про стандарты РВ для Явы и не слышалось.
Хотелось бы услышать аргументированное мнение про применимость Явы в СРВ. Ведь изначально язык для этой области не предназначался, Sun вроде бы всегда предупреждала о неприменимости его для СРВ...

Ответ на »сообщение 998« (Cardinal)
___________________________
1. Почему у вас никто не хочет слышать про Яву, Аду, Оберон?
Да я уже тут слёзы лил по сему поводу... Человецкий фактор... Контора пишет (по крайней мере они так считают, что они "умеют" это делать) на Си.
Про Аду до сих пор уверены были, что это интерпретатор. Про стандарты РВ для Явы и не слышалось. Оберон? - "этачавой-то?"
Короче, текущее положение дел 99% устраивает...
2. Для какой версии QNX Ваша библиотека сейчас?
6.2.х. Хотя, ПОЗИКС-варианту - какая разница? А переписанной чисто для куникса - тем более... :о)

Ответ на »сообщение 989« (Robin)
___________________________

я еще ничего не слышал об опровержении теорем Геделя - ни первой, ни второй. А суть этих теорем, если отбросить математические "заумности" такова: ни одна формальная система не может содержать полное и формальное описание самой себя.

Ну как же! Вот оно, опровержение! ;)
Я могу написать скажем, на Delphi компилятор Оберона и наоборот.

Ответ на »сообщение 997« (Владимир Лось)
___________________________

...наиболее гибкий подход в Яве. Он же и самый опасный в плане возможности напортачить. Основная претензия к нему - невозможность определить по описанию класса, является ли доступ к его полям синхронизируемым или нет. Кроме того, синхронизация может располагаться не только в методах самого класса, но и "где придётся". Из-за этого могут возникать ошибки по невнимательности.


Аналогично в .Net. Залочить любой объект можно как "внутри него" выполнив lock (this) {...}, так и "снаружи" вызвав lock (obj) {...}. Очевидно, что одновременное использование "внутренних" и "внешних" по отношению к объекту блокировок может привести к не предсказуемым последствиям. Доходит до маразма: поскольку "внешние" блокировки контролировать невозможно, то в MSDN предлагается для большей безопасности ни когда не пользоваться "внутренними" блокировками на this.

Ответ на »сообщение 997« (Владимир Лось)
___________________________
1. Почему у вас никто не хочет слышать про Яву, Аду, Оберон?
2. Для какой версии QNX Ваша библиотека сейчас?

Монополизация доступа к ресурсу.
Если рассматривать различные реализации мониторов Хоара-Хансенна (Ада, Аберон, Ява), то наиболее гибкий подход в Яве. Он же и самый опасный в плане возможности напортачить. Основная претензия к нему - невозможность определить по описанию класса, является ли доступ к его полям синхронизируемым или нет. Кроме того, синхронизация может располагаться не только в методах самого класса, но и "где придётся". Из-за этого могут возникать ошибки по невнимательности.
Далее, в середине спектра идёт Аберон. Здесь также есть блоки исключительного доступа, но они получают ограничение на применимость относительно текущего экземпляра.
Самым строгим является подход Ады. Тут вообще блоки, как таковые признак исключительности (синхронности) доступа носить не могут, всё выродилось в функции, процедуры и входы задач. Плюс от такого подхода - ясное выражение намерений автора класса из описания класса. Кроме того, Ада строго блюдёт дисциплину изменчивости доступных ресурсов из соответствующих единиц исполнения. В функции изменять ничего нельзя, только возвращать результат. В процедуре и входе - можно. Относительно "монопольности" - функции обеспечивают "параллельный доступ по чтению", или "правило читателей", когда одновременный параллельный доступ может быть предоставлен множеству читателей, при отсутствии писателей. Соответственно, для процедур и входов задач - доступ по записи, по "правилу писателей" - только один писатель, если нет читателей.
Ещё один тонкий момент, про который я узнал ну совершенно недавно и к немалому для себя удивлению... Оказывается поток (задача) в Аде не может вызывать входы одной задачи, если он уже находятся во входе другой задачи. Просто компилятор не пропустит такой код.
Здесь "убивают двух зайцев".
1. Первый заяц, видимо, из леса возможных взаимоблокировок.
2. Второй – из чисто прикладных, практических интересов. Ведь вход задачи – это некий аналог Абероновской процедуры с AWAIT первым оператором. Ада создавался для систем РВ и встроенных. Таким решением разработчики Ada95, видимо, решили снизить вероятность "стопорения" кучи потоков на первом входе задачи, пока мы, имея наш объект "залоченны" пытаемся пробиться сквозь условие на каком-то другом входе. По их оценкам ожидания выполнения условия на входе задачи является "более длительным процессом" (или более "затратным" с точки зрения среды поддержки исполнения), чем выполнение целой процедуры или функции...
В любом случае, получение в руки инструмента, указывающего на возможные места появления взаимоблокировок мне понравилось. Мгновенно "по неволе" переключает мозги с кодирования на проектирование...