[Goroshko 0]

Чего тут обсуждать-то? 8-)

Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...

В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...

Ну, чего тут обсуждать? :-)))

 

А что такое сборка мусора, по Вашему? 8-) По мне, так это источник непредсказуемых задержек.

 

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

Да, кстати, речь конечно идет не о Дефрагментации, а о Фрагментации :-) памяти. С чем это связано? С алгоритмом аллокации и деаллокации памяти. Это алгоритм ничего общего с языками С или С++ не имеет, поэтому речь не о них. То, что в СРВ необходимо избегать в критических местах динамической аллокации памяти - это довольно прописные истины, уже хотя бы по тому, что это медленные операции, а зачем их вызывать в критически опасных местах? ;-)

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

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

[Владимир Е. Зюбин 0]

Чего тут обсуждать-то? 8-)

Динамические операции с ОЗУ приводят к дефрагментации памяти, а возможно и к утечкам...

В первом случае возникают неконтролируемые задержки, во-втором вообще-крах системы...

Ну, чего тут обсуждать? :-)))

 

А что такое сборка мусора, по Вашему? 8-) По мне, так это источник непредсказуемых задержек.

 

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

Да, кстати, речь конечно идет не о Дефрагментации, а о Фрагментации :-) памяти.

 

Спасибо за поправку. Принимаю.

 

С чем это связано? С алгоритмом аллокации и деаллокации памяти. Это алгоритм ничего общего с языками С или С++ не имеет, поэтому речь не о них. То, что в СРВ необходимо избегать в критических местах динамической аллокации памяти - это довольно прописные истины, уже хотя бы по тому, что это медленные операции, а зачем их вызывать в критически опасных местах? ;-)

 

Вопрос это связан еще и с диск-своппингом... который тоже не возникает просто так.

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

 

Вот и все.

 

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

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

 

Ровно то же самое можно сказать и про диск-своппинг: скорость доступа к данным постоянно растет.

А чтобы не было диск-своппинга - ставьте больше памяти. А уж коли кончилась оперативная память, не отправляйте критическое приложение в заведомо аварийное состояние, а попытайтесь что-нибудь сделать... Лучше поздно, чем никогда.

 

Я это опять к тому, что позиция т.н. РТ-сообщества (QNX-сообщества) по диск-своппингу какое-то невразумительное... особенно когда в QNX 6.0 появился диск-своппинг... все стали петь песню, про то, что это здорово, а по сравнению с Windows, его можно и отключить... а теперь диск-своппинг исчез из QNX (как заявляет Олег) по непонятным причинам... и диск-своппинг опять стал абсолютным злом. Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны. "Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

 

Я, вообще говоря, нисколько не против QNX, но фанатизм сообщества лично меня просто пугает.

[Goroshko 0]

Вопрос это связан еще и с диск-своппингом... который тоже не возникает просто так.

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

 

Вот и все.

Почему же все? Свопирование (перенос на жесткий диск) памяти приложения по скорости операции, по колличеству задействованных подсистем - очень сильно отличается от динамического распределения памяти. Кроме того ведь есть два разных понятия - свопирование данных и свопирование кода.

 

Ровно то же самое можно сказать и про диск-своппинг: скорость доступа к данным постоянно растет.

А чтобы не было диск-своппинга - ставьте больше памяти. А уж коли кончилась оперативная память, не отправляйте критическое приложение в заведомо аварийное состояние, а попытайтесь что-нибудь сделать... Лучше поздно, чем никогда.

Ну пойми те же - нет в РТ такого понятия - в РТ "поздно" и "никогда" - равнозначны. Если это критическая система, там к моменту "поздно" давно уже врубилась система резервирования, а "опоздавший" хост перезапущен каким-нибудь watch-dog таймером.

 

Я это опять к тому, что позиция т.н. РТ-сообщества (QNX-сообщества) по диск-своппингу какое-то невразумительное... особенно когда в QNX 6.0 появился диск-своппинг... все стали петь песню, про то, что это здорово, а по сравнению с Windows, его можно и отключить... а теперь диск-своппинг исчез из QNX (как заявляет Олег) по непонятным причинам... и диск-своппинг опять стал абсолютным злом.

НУ почему же невразумительное - я же уже писал об этом выше. В QNX 6.0 вводился свопинг данных для работы разработческих приложений - например gcc. И разрешался свопинг данных только для специальных приложений, типа того же gcc. Фактически свопирование данных (не кода, заметьте - свопирования кода не было вообще никогда) присутсвовало в системе исключительно опционально.

Я не знаю насчет положения с последними версиями QNX 6.3 SP2 - по видимому они нашил решение этой проблемы и окончательно убрали свопирование. Даже как опциональную возможность.

Еще раз подчеркну - его не "можно и отключить", а его нужно очень постараться что бы включить!

 

Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны. "Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

Почему на смерть? Я же говорил, да динамических операций аллокации лучше избегать. Выполнять их в некритических участках.

А вот насчет С++.... :-) Я могу еще дискутировать насчет скорости, производительности... но надежность по сравнению с С? Да все не надежные механизмы присутсвующие в С++ были унаследованны от С! Как же так С может быть надежнее чем С++?

[Olej 0]

С чем это связано? С алгоритмом аллокации и деаллокации памяти. Это алгоритм ничего общего с языками С или С++ не имеет, поэтому речь не о них. То, что в СРВ необходимо избегать в критических местах динамической аллокации памяти - это довольно прописные истины, уже хотя бы по тому, что это медленные операции, а зачем их вызывать в критически опасных местах? ;-)

 

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

Во-первых, многое зависит от базового механизма распределения, который использует конкретная ОС - я уже обращал внимание: посмотрите на pSOS, как там управляется память (а pSOS одна из лучше зарекомендовавших себя РТОС).

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

В-третьих, обращу внимание на деталь, которую часто упускают из виду:

- динамическое распределение С - malloc()/free() - использует память heap;

- динамическое распределение С++ - new()/delete - использует (по стандарту) совершенно другой класс памяти - "динамически распределяемая", который в реализации многих ОС совпадает с heap, но это совершенно не обязательно...

- таким образом, у вас есть и 2 механизма, надстроенных один над другим - надстройте и наворотите над ними всё что угодно...

 

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

 

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

 

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

 

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

Кроме того, "ручное" управление памятью в стиле С/С++ (malloc()/free(), new()/delete), которое тоже требует аллокаторов/деаллокаторов, и автоматическая сборка "неиспользуемого мусора", основанная на признаках неиспользуемости (напр., счётчике ссылок, но не только) - это очень разные по сложности механизмы.

 

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

 

"Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

 

Со словом "надёжность" к ПО нужно подходить с большой тщательностью - в ПО нет стареющих или изнашивающихся частей, чтобы к нему можно было применять положения теории надёжности.

Но в нём всегда есть скрытые ошибки, которые и выявляются как "не надёжность"...

Теперь смотрите сюда ;) :

- С является подмножеством С++, программа С будет всегда (ну, почти всегда ;), на 99.999%) синтаксически совместима с С++ (несовместимости - описаны, они все - из разряда казусов, и могут быть устранены)...

- программу, написанную на чистом С вы можете компилировать командой: "gcc ...", но её же и командой "g++ ..." - в режиме синтаксических правил С++...

- будет та же программа, скомпилированная во втором случае - надёжнее 1-й? (т.е. в смысле - содержать меньше скрытых ошибок). Будет! - по очень простой причине: гораздо более строгий типизированный контроль ... того же исходного кода (я иногда развлекаюсь так, компилируя pure C в режиме C++).

- это относительно одного и того же файла кода... т.е. того же подмножества языка, которое общее...

- будет ли "безошибочнее" надмножество, которое выводит С++ за пределы С ... а безошибочнее чего? с чем вы собираетесь сравнивать, если эквивалента нет?

 

Я нигде не говорил, что "надежность Си++ выше всего", я говорил: надёжности С++ при прочих равных не с чего быть ниже, чем С. И только.

 

А все "статистические, так и теоретические данные" ... смотрел я иногда - это всё из области спекуляций.

 

Я это опять к тому, что позиция т.н. РТ-сообщества (QNX-сообщества) по диск-своппингу какое-то невразумительное... особенно когда в QNX 6.0 появился диск-своппинг... все стали петь песню, про то, что это здорово, а по сравнению с Windows, его можно и отключить... а теперь диск-своппинг исчез из QNX (как заявляет Олег) по непонятным причинам... и диск-своппинг опять стал абсолютным злом. Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны.

 

Я, вообще говоря, нисколько не против QNX, но фанатизм сообщества лично меня просто пугает.

 

Владимир, а). "т.н. РТ-сообщество" ;) и QNX-сообщество - это далеко не одно и то же - 1-е намного шире 2-го; б). нет как такового и "QNX-сообщества" - есть совершенно разрознённые, хотя их и достаточно много уже, специалисты, практически работающие с QNX ... с гораздо большими основаниями можно было бы говорить об Linux-сообществе, FreeBSD-сообществе, MAC-сообществе ... там это хоть "клуб по интересам" напоминает ;)...

Так что пусть это вас так сильно не пугает ;) - вам никто не угрожает.

[Olej 0]

А вообще то, разговор уехал несколько в сторону от заданной теме, и теперь он должен был бы называться: "Какая РТОС мне бы нужна, когда она мне не нужна". ;)

[Владимир Е. Зюбин 0]

Вопрос это связан еще и с диск-своппингом... который тоже не возникает просто так.

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

 

Вот и все.

Почему же все? Свопирование (перенос на жесткий диск) памяти приложения по скорости операции, по колличеству задействованных подсистем - очень сильно отличается от динамического распределения памяти. Кроме того ведь есть два разных понятия - свопирование данных и свопирование кода.

 

а еще есть кэширование и спекулятивные вычисления... источники всякой непредсказуемости...

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

 

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

Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).

Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

 

Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет. Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.

 

Ровно то же самое можно сказать и про диск-своппинг: скорость доступа к данным постоянно растет.

А чтобы не было диск-своппинга - ставьте больше памяти. А уж коли кончилась оперативная память, не отправляйте критическое приложение в заведомо аварийное состояние, а попытайтесь что-нибудь сделать... Лучше поздно, чем никогда.

Ну пойми те же - нет в РТ такого понятия - в РТ "поздно" и "никогда" - равнозначны. Если это критическая система, там к моменту "поздно" давно уже врубилась система резервирования, а "опоздавший" хост перезапущен каким-нибудь watch-dog таймером.

 

Это Ваше личное определение РТ. Есть и много других определений и точек зрения. В частности, есть и такая точка зрения, что проблема РТ - чисто маркетинговая фишка, не имеющая ни строгого определения, ни смысла. Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".

 

Поздно/не поздно, мягко/жестко... бла-бла-бла... даже внятного определения для "реального времени" не существует. Одни пузыри. Отсюда и постоянные глупые споры, holly-wars.

 

Самые мудрые слова, которые мне встретились по поводу РВ были:

"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"

 

Сами понимаете, что это интересное определение идет вразрез с установкой т.н. РТ-сообщества, типа QNX сообщества и прочих нескольких. ;-) Т.к. там не предусматривается всякая чушь типа шедулеров, прерываний, приоритетов, работы при недостатке выч.ресурсов и "быстрых" времен.

 

В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.

К сожалению, особое место ОС тут не предусмотрено, более того, решать задачи управления, проще специализированными средствами (теми же языками МЭК 61131-3), чем средствами ОС, которые тут играют лишь вспомогательную (хотя и часто полезную) роль: драйверы, работа с ОЗУ, файлы, протоколы связи и т.п.

 

Но вот динамические операции с ОЗУ - тут мы стоим насмерть... можно и все. Мнения экспертов в области автоматизации - дискуссионны. "Надежность Си++ выше всего" - тут тоже какое-то труднообъяснимое упорство в опровержении как статистических, так и теоретических данных...

Почему на смерть? Я же говорил, да динамических операций аллокации лучше избегать. Выполнять их в некритических участках.

А вот насчет С++.... :-) Я могу еще дискутировать насчет скорости, производительности... но надежность по сравнению с С? Да все не надежные механизмы присутсвующие в С++ были унаследованны от С! Как же так С может быть надежнее чем С++?

 

По-моему к таким выводам эксперты пришли на основании трех фактов:

1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.

[Goroshko 0]

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

Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).

Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

Нет вы все таки не о том говорите - никого не волнует что медленно. Главная проблема - определить момент когда это замедление наступит. В Виндоус (да и в любой другой системе) это очень сложно. Когда вы сами выполняете дисковые операции - вы точно знаете когда это делает. В случае же со свопингом - это предсказать нельзя. Именно в этом причина. Не в самих задержках, а в их не предсказуемости. Проблема фрагментации памяти все равно лежит в другой плоскости - там из-за отсутсвия единого участка заказанной памяти при наличии в общем достаточного колличества свободного места верент ошибку операция заказа памяти. По большому счету бороться с этой проблемой не так и сложно. Ведь когда необходимо динамическое распределение памяти - когда вам надо передавать из одного участак приложения большие объемы данных в другие участки. Альтернативой тут может быть только копирование - что зачастую может быть в высшей стпени не рационально. Проблема фрагментированности памяти возникает как раз в другой ситуации - когда память аллокируется и освобождается недобльшими учасками и не равномерно.

Поэтому обощать проблемы свопирование и фрагментации памяти явно ошибочно.

 

Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет. Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.

Да конечно ничего страшного, да замечательно что становится надежнее. Только меня изумляют попытки прилепить ее к месту и не к месту исключительно из тех соображений что разработчики с ней знакомы. Почему разработчки самой XP не позиционируют ее для РТ применения? Если уж они сами считают что она для этого не подходит, почему же все таки пытаются ее наклонить на выполнение не свойственных ей функций? Я лично ничего против виндоуса как настольной, офисной, даже разработческой системы против не имею, но как сказал один мой знакомый - когда делаешь что-то серьезное, хочется положить его в простое и надежное место. И это место может быть совсем не обязательно QNX, есть масса ОС которые находятся гораздо ближе к области РТ чем Виндоус.

 

Это Ваше личное определение РТ. Есть и много других определений и точек зрения. В частности, есть и такая точка зрения, что проблема РТ - чисто маркетинговая фишка, не имеющая ни строгого определения, ни смысла. Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".

 

Поздно/не поздно, мягко/жестко... бла-бла-бла... даже внятного определения для "реального времени" не существует. Одни пузыри. Отсюда и постоянные глупые споры, holly-wars.

 

Самые мудрые слова, которые мне встретились по поводу РВ были:

"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"

По поводу формулировок

http://qnxclub.net/files/articles/rtos/rtos.html

Ваша цитата лишь еще одно перефразирование определений СРВ. Фактически все они именно к этому и сводятся.

Вот и давайте разберемся с этим определением - что ж в нем говорится.

Что означает "порядок обработки информации предопределяется ходом процессов вне ЭВМ"? Это значит что по наступлению какого-то внешнего события не позднее некоторого срока должна наступить какая-то реакция программы. Так? Причем срок реакции и сама длительность реакции должны быть не длинне заданного - иначе следующее событие не будет вовремя обработано.

Именно об этом я все время и говорю.

Сами понимаете, что это интересное определение идет вразрез с установкой т.н. РТ-сообщества, типа QNX сообщества и прочих нескольких. ;-) Т.к. там не предусматривается всякая чушь типа шедулеров, прерываний, приоритетов, работы при недостатке выч.ресурсов и "быстрых" времен.

Нигде в определении термина РВ нет слов о шедулерах, вы наверно не внимательно читали (я имею в виду не определения Васи Пупкина, а определения принятые стандартами). Собственно таких страшных слов и не может быть в определении термина "реальное время". Их также нет в определении термина "Система Реального Времени". А вот в определении понятия "Операционная Система Реального Времени" эти слова вполне законно могут присутствать.

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

 

В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.

К сожалению, особое место ОС тут не предусмотрено, более того, решать задачи управления, проще специализированными средствами (теми же языками МЭК 61131-3), чем средствами ОС, которые тут играют лишь вспомогательную (хотя и часто полезную) роль: драйверы, работа с ОЗУ, файлы, протоколы связи и т.п.

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

 

По-моему к таким выводам эксперты пришли на основании трех фактов:

1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.

1. Сразу возникает вопрос - какие экперты?

2. В чем заключается более высокая прозрачность структурного языка перед объектным? Ведь он заведомо дальше от предметной области!

3. В Си операции с указателями это исключение? А зачем тогда его вообще использовать? Он ведь как раз для этого и создавался!

4. Статистика..... замечательная вешь. :-) Но это невероятно слабый аргумент особенно в таком виде.

Учитывая что значительная часть моей карьеры прошла в качестве физика-экспериментатора, я очень хорошо представляю себе что такое статистические данные :-)

[Olej 0]

а еще есть кэширование и спекулятивные вычисления... источники всякой непредсказуемости...

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

 

Есть ;).

 

Только вот в чём дело, когда вы выполняете операцию с адресуемой в RAM областью, типа оператора:

int i;

i = 0;

- то в зависимости от того, попадает она в кэш или нет, вы имеете разницу во времени операции отличающуюся в лучшем случае в 2-3 раза (я реально это смотрел), и операцию (если x86) на 5-8 машинных тактов (десяток-другой нсек.), если вы последовательно выполняете операции над наукад 1000 переменными, скажем, если очень грубо считать что 50% их попадает в кэш, а 50% - нет, то разброс у вас (по сравнению с оптимумом) будет 1.5-2 раза.

 

Физческие операции загрузки-выгрузки на диск - на 2-3 порядка медленнее...

Но и это не самое худшее, когда вы выполняете ту же операцию, которую я выписал выше, и i находится на выгруженной странице, то загрузка-выгрузка производится страницами RAM, в x86 - 4K "туда" + 4К "обратно" - вот вам ещё 1 порядок непредсказуемости на времени тривиальной операции - до 4-х порядков.

 

Неопределённость (дисперсия) времён 50-100% - это одно, а 4 порядка - это, согласитесь, несколько другое... Это не я придумал ;), и именно из подобных соображений на кэширование и другие подобные "ускорители" (те же спекулятивные вычисление, опережающее конвейерное выполнение etc.) смотрят в обсуждениях и публикациях об РВ "сквозь пальцы", а такие возможности как виртуализация страниц RAM - отвергаются категорически.

 

Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).

Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

 

"Медленнее/быстрее" - вообще к РВ не имеет касательства, общепризнанно и с этим уже, кажется, смирились ;), что система (ОС или целевая система вообще), удовлетворяющая требованиям РВ будет, при прочих равных, несколько медленнее, чем аналогичная, к которой такие требования не предъявлялись (GPOS, например).

 

А вот то, что "зато система живет, а не рушится" ... это достаточно сомнительное достоинство в системах, требующих критической по времени реакции ... Goroshko Egor затронул это...

Ну представьте, к примеру, РЛС системы ПВО/ПРО, как одну из систем РВ ... в чём разница между тем, что она пропустит отметку цели, или обнаружит её с сильно превышенным подлётным временем?

Разве только в том, что в 1-м случае система "накроется" в полностью благодушном неведении, а во 2-м - в стоп-кадре "паническое разбегание персонала кто-куда"...

 

Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет.

 

"Жизнь становится лучше, товарищи. Жизнь становится веселее"(с) - автор известен...

Ничего страшного в том, что "Виндовоз становится все надежнее и надежнее", конечно, нет ... несколько настораживает, правда, то, что он "становится надежнее" уже порядка 20-ти лет, и ... "завтра вот-вот ...".

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

 

Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.

 

Конечно не надо ;) - если бы это было время реакции, время ответа ... и т.д. - но это единица шкалы, неточность определения, а минимальные разрешимые интервалы будут в несколько раз больше единицы шкалы ... а это уже "не не надо" ;).

 

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

 

Есть и такая точка зрения ... только она тоже не "строго определённая" - отмечается, что и такой компонент есть в терминологии "РВ" ;)...

 

Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".

 

Почему же нет? Есть - безупречная success story более 25-лет - всегда безотказной работы, годами в необслуживаемом режиме... (это 25 лет - ~ столько, сколько вся история MS DOS + Windows с уговорами, что "завтра будет лучше чем вчера").

 

Самые мудрые слова, которые мне встретились по поводу РВ были:

"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"

 

Хорошее определение ... только "масло маслянное": а что, в IBM 360 60-х годов - порядок обработки информации не предопределялся ходом процессов вне ЭВМ? начиная с того, как пользователь вложил коложу перфокарт?, и как он правильно их вложил? ... и до того места, провернулся ли уже барабан АЦПУ до положения, когда следует печатать следующую строчку "простыни"? ...

 

В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.

 

Да пожалуйста ... описывайте. Кто ж возбраняет?

Только, по возможности, воздержитесь от непреодолимого желания его продавать как "средства описания режимов работы в реальном масштабе времени" - тем, кому может прийти в голову начать описывать такие режимы ;)...

 

По-моему к таким выводам эксперты пришли на основании трех фактов:

1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.

 

1.

- Так выпьем же за то, что грузины лучше чем армяне...

- Ну чем, чем лучше?

- ... чем армяне.

(с).

 

С "более прозрачен" для тех, кто не знает С++, так же как и наоборот.

 

2. "операции с тем же ОЗУ" ... ? (я не заню какое это "то же" ОЗУ - это С & C++ работают с одним и тем же ОЗУ ;)) ... наверное имелись в виду динамические операции? - так их "плотность" определяется желаниями пишущего использовать или не использовать, а не то, на чём он выражает свои желания...

А кстати - как на счёт strdup()? ;) - многие ли задумываются что они при этом делают?

А если так ;) :

void func( char* S1 ) {
   char* S2 = S1;
   ...
   return( strdup( S2) );
};

 

3. где она - эта статистика? и уровень её адекватности? - URL в студию!

 

P.S. сравнивать С/С++ по критерию "плотности ошибок" вообще неблагодарное занятие - слишком близкие эти 2 клона, и оба предрпсположенные к ошибкам... а хотите принципиально другую защищённость от ошибок - учите Ada ;)!

 

 

Ну ладно ...

Повеселились, покуражились - и будя!

[Владимир Е. Зюбин 0]

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

Просто тут (у представителей QNX-сообщества) налицо какая-то предвзятость. Это непонятно (пока).

Ну и что что, медленнее? Ну и что, что там больше транзисторов задействовано? Зато система живет, а не рушится.

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

 

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

ОБЕСПЕЧЕНО КОНСТРУКТИВНО

 

Владимир Е. Зюбин:"Я понимаю, что год от года Виндовоз становится все надежнее и надежнее, ничего страшного в этом нет."

 

Да конечно ничего страшного, да замечательно что становится надежнее. Только меня изумляют попытки прилепить ее к месту и не к месту исключительно из тех соображений что разработчики с ней знакомы. Почему разработчки самой XP не позиционируют ее для РТ применения?

Все очень просто. Виндовоз предоставляет: 1) однородность среды разработки/исполнения 2)

Видндовоз предоставляет несоизмеримо большую функциональность, т.к. это MAINSTREAM.

 

Как видите, ответы очень просты. Сходите, кстати, на сайт Прософта, Виндовоз продается наравне с QNX, его и позиционировать не надо... все и так все понимают, не удивлюсь, если объемы его продаж превышают позиционируемый как ОСРТ QNX.

 

Может, дело в том, что тема реального времени давно устарела? Не думали над этим?

 

Самые мудрые слова, которые мне встретились по поводу РВ были:

"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"

По поводу формулировок

http://qnxclub.net/files/articles/rtos/rtos.html

Ваша цитата лишь еще одно перефразирование определений СРВ. Фактически все они именно к этому и сводятся.

Вот и давайте разберемся с этим определением - что ж в нем говорится.

Что означает "порядок обработки информации предопределяется ходом процессов вне ЭВМ"? Это значит что по наступлению какого-то внешнего события не позднее некоторого срока должна наступить какая-то реакция программы. Так? Причем срок реакции и сама длительность реакции должны быть не длинне заданного - иначе следующее событие не будет вовремя обработано.

Именно об этом я все время и говорю.

 

Кроме этого это значит, что ПО не содержит ошибок, нет перебоев с питанием, проц не глючит, у датчиков погрешность в норме (метрологически аттестованы), исполнительные органы не заклинило... и т.д. и т.п.

 

проблема выч.ресурсов - это одна из возможных причин отклонений от заданных режимов работы.

и на настоящий момент не самая актуальная... для 99% случаев.

 

Сами понимаете, что это интересное определение идет вразрез с установкой т.н. РТ-сообщества, типа QNX сообщества и прочих нескольких. ;-) Т.к. там не предусматривается всякая чушь типа шедулеров, прерываний, приоритетов, работы при недостатке выч.ресурсов и "быстрых" времен.

Нигде в определении термина РВ нет слов о шедулерах, вы наверно не внимательно читали (я имею в виду не определения Васи Пупкина, а определения принятые стандартами).

 

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

 

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

 

Что осталось? ;-)

 

Вы вот пишете...

"Одним из наиболее спорных и сложных терминов систем автоматизации является английское выражение «realtime»", а потом встаете ложную тропинку - дать наконец-то определение этому РТ... и пардон, опять с нулевым эффектом (как и многие до Вас).

 

А ответ-то прост - нет в этом словосочетании смысла, придуман и использовался он чисто в маркетинговых целях - наделить продаваемый продукт отличительными признаками. Вот и все.

Технически для ОС QNX более правильная характеристика - ОС с микроядерной архитектурой. ;-)

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

 

В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.

К сожалению, особое место ОС тут не предусмотрено, более того, решать задачи управления, проще специализированными средствами (теми же языками МЭК 61131-3), чем средствами ОС, которые тут играют лишь вспомогательную (хотя и часто полезную) роль: драйверы, работа с ОЗУ, файлы, протоколы связи и т.п.

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

 

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

 

Увы, QNX-сообщество вызывает у меня сочувствие, но истина дороже... рекламная кампания производителя QNX строится на технически безграмотной терминологии... ну или "на спорном и сложном термине", как Вы это сами признаете...

 

По-моему к таким выводам эксперты пришли на основании трех фактов:

1. Си более прозрачен, чем Си++, и 2. Операции с тем же ОЗУ там скорее исключение, чем правило, в отличие от Си++. 3. статистика.

1. Сразу возникает вопрос - какие экперты?

2. В чем заключается более высокая прозрачность структурного языка перед объектным? Ведь он заведомо дальше от предметной области!

3. В Си операции с указателями это исключение? А зачем тогда его вообще использовать? Он ведь как раз для этого и создавался!

4. Статистика..... замечательная вешь. :-) Но это невероятно слабый аргумент особенно в таком виде.

Учитывая что значительная часть моей карьеры прошла в качестве физика-экспериментатора, я очень хорошо представляю себе что такое статистические данные :-)

 

Тут просто нужно понимать проблемную ориентацию Си++. Тогда все встанет на свои места.

А Си++ предназначен для группового и скоростного проектирования WIMP-интерфейсов.

Вот и все. Так и используется в MS. WIMP - это по сути GES (good enough software). Надежность тут сами понимаете, отнюдь не на первом месте. Гораздо важнее скорость разработки и модифицируемость.

 

Ну а насчет вопроса, "а судьи кто?" - Не знаю что сказать. В печатном и прямом виде это утверждение встречал в "Открытых системах". Номер не помню.

[Владимир Е. Зюбин 0]

Физческие операции загрузки-выгрузки на диск - на 2-3 порядка медленнее...

Неопределённость (дисперсия) времён 50-100% - это одно, а 4 порядка - это, согласитесь, несколько другое...

 

Где в определении РТ об этом?! Или Вы перекинулись в лагерь адептов наивного определения реального времени... "РТ=быстро"? Какая разница 1 наносекунда или 1 час? Какая разница в сто раз или в два раза... для мифического и любимого QNX-сообществом самолета, врезавшегося во взлетно-посадочную полосу?

 

Кстати, не глупо ли, вести самолет в режиме, когда жизнь и смерть пассажиров разделяет задержка в одну миллисекунду? по-моему, так это высшая степень идиотизма.

 

 

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

 

Да про какие Вы системы толкуете-то? Я толкую про пром.автоматизацию... где основная проблема сложность алгоритма, где основная сложность, чтобы все ПРАВИЛЬНО работало.

 

А Вы про какую-то военную технику все рассуждаете.. ПРО/ПВО... ставьте там двуядерный процессор или десятиядерный... или десять процессоров... Задачи-то вы обсуждаете чисто вычислительные...

"кто быстрее вычислит". Это для пром.автоматизации не самое интересное из.

 

Вот:

Goroshko Egor затронул это...

Ну представьте, к примеру, РЛС системы ПВО/ПРО, как одну из систем РВ ... в чём разница между тем, что она пропустит отметку цели, или обнаружит её с сильно превышенным подлётным временем?

Разве только в том, что в 1-м случае система "накроется" в полностью благодушном неведении, а во 2-м - в стоп-кадре "паническое разбегание персонала кто-куда"...

 

Это именно ВАШЕ "сильно/слабо"... и не надо обижаться на меня за "быстро/медленно"...

 

Лучше уж трезво смотреть в глаза фактам. Ну и по временному разрешению 10 мс - это вполне приличное время. Для большинства (подавляющего большинства) задач автоматизации - меньше и не надо.

 

Конечно не надо ;) - если бы это было время реакции, время ответа ... и т.д. - но это единица шкалы, неточность определения, а минимальные разрешимые интервалы будут в несколько раз больше единицы шкалы ... а это уже "не не надо" ;).

 

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

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

 

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

 

Есть и такая точка зрения ... только она тоже не "строго определённая" - отмечается, что и такой компонент есть в терминологии "РВ" ;)...

 

Это строгое определение, хоть и метауровневое (с выходом над проблемой):

смысл термина "реальное время", не сложен и запутан, а равен нулю.

 

И следует каждый раз для каждого конкретного случая выбирать адекватные и технически грамотные термины: алгоритм планирования, архитектура ОС, временные интервалы, период, и т.д.

 

Просто QNX больше нечего предоставить в качестве отличительного свойства своего продукта, кроме мифического "РТ".

 

Почему же нет? Есть - безупречная success story более 25-лет - всегда безотказной работы, годами в необслуживаемом режиме... (это 25 лет - ~ столько, сколько вся история MS DOS + Windows с уговорами, что "завтра будет лучше чем вчера").

 

статистика нужна, а не success stories, рожденные в рекламных отделах QNX... а статистика такова, что основная масса аварий с участием QNX (и без оного) происходит за счет ошибок программирования, зачастую просто логических, невнятного интерфейса, отсутствия защит от неверных действий оператора и т.д.

 

Самые мудрые слова, которые мне встретились по поводу РВ были:

"Режим работы ЭВМ, при котором порядок обработки информации предопределяется ходом процессов вне ЭВМ, называется работой в реальном масштабе времени (РМВ)"

 

Хорошее определение ... только "масло маслянное": а что, в IBM 360 60-х годов - порядок обработки информации не предопределялся ходом процессов вне ЭВМ? начиная с того, как пользователь вложил коложу перфокарт?, и как он правильно их вложил? ... и до того места, провернулся ли уже барабан АЦПУ до положения, когда следует печатать следующую строчку "простыни"? ...

 

Зачем путать функционирование системы и ее загрузку? Или Вы не различаете вычислительные задачи и задачи управления? Режим штатного функционирования и отказ аппаратной части?

 

В этом смысле языки, типа Рефлекс, это и есть средства описания режимов работы в реальном масштабе времени.

 

Да пожалуйста ... описывайте. Кто ж возбраняет?

Только, по возможности, воздержитесь от непреодолимого желания его продавать как "средства описания режимов работы в реальном масштабе времени" - тем, кому может прийти в голову начать описывать такие режимы ;)...

 

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

 

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

 

А кстати - как на счёт strdup()? ;) - многие ли задумываются что они при этом делают?

А если так ;) :

void func( char* S1 ) {
   char* S2 = S1;
   ...
   return( strdup( S2) );
};

 

насчет strdup, "я такой умный вещь скажу, ты только не обижайся"(с):

в алгоритмах управления strdup-ы не встречаются. Ни к чему они там.

(а что делают strdup, malloc и calloc я себе прекрасно представляю).

 

Кстати, и просто strcpy употреблять не рекомундуется... подумайте на досуге, почему.

ключевое слово - устойчивость (robustness).

 

Что примечательно: к теме критических систем strcpy имеет прямое отношение, а вот с РТ никак не связано... ;-)

[Thistle 0]

1) однородность среды разработки/исполнения

 

Вот это как раз и настораживает: у вас когда-нибудб пропадали элементы меню"Пуск"?, а рабочий стол не превращался в "картинку", абсолютно на ваши действия не реагирующую?

 

2)

Видндовоз предоставляет несоизмеримо большую функциональность, т.к. это .

 

Знаете, ДОМ 2 Это тоже вроде MAINSTREAM а тем не менее меня от него почему-то воротит

:cranky: (тема отдельного разговора))) ) да и как-то логически ваши слова не увязываются:

MAINSTREAM и

функциональность

:unsure:

 

Как видите, ответы очень просты. Сходите, кстати, на сайт Прософта, Виндовоз продается наравне с QNX, его и позиционировать не надо... все и так все понимают, не удивлюсь, если объемы его продаж превышают позиционируемый как ОСРТ QNX.

Вы знаете, а вот туалетную бумагу тоже как то часто очень покупают... видимо потому что дёшево и с

функциональность

только вот для строительства орбитальных станций почему-то спец сплавы применяют... хм....или если рынок продиктует и она попадёт в этот самый MAINSTREAM то следующий блок для МКС будет на Байкальском целлюлозно-бумажном изготовляться?

 

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

 

Технически для ОС QNX более правильная характеристика - ОС с микроядерной архитектурой. ;-)

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

 

 

кстати очень даже не кисло, они - именно это и делают!!! :laugh:

[Andrew2000 0]

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

При чем тут Рефлекс? Тут вроде ОС обсуждаются - не надо мешать все в одну кучу - про Рефлекс отдельная ветка есть.

 

Все очень просто. Виндовоз предоставляет: ...

Конечно, предоставляет - мелким фирмочкам сваять на коленке "пром. ПЛК", продать и свалить через месяц в неизвестном направлении (ну пару месяцев) ...

 

Может, дело в том, что тема реального времени давно устарела? Не думали над этим?

...

Понимаете, словосочетание "реальное время" уже давно используется всеми кому не лень, его заездили, ...

Технически для ОС QNX более правильная характеристика - ОС с микроядерной архитектурой. ;-)

...

Да, и и словосочетание заездили, и для QNX и любой другой ОС я бы не применял термин РТОС.

(Ну, раз их так называют, что делать, и я буду).

 

Что мне (или какому-нить пользователю ПЛК) нужно. Нужна Система РВ (не отдельная РТОС, а коробка в сборе) - управляющая система.

А изнутри: Мне нужно, например, чтоб управляющая задача получала управление каждые 10мс (дрожание начала такта +- 100мкс) и занимала на 5мс ЦПУ, задача связи - ...

Применяя РТОС типа CMX, Nucleus, eCos - я знаю как это сделать (ессно. с учетом быстродействия ЦПУ и сложности алгоритма).

Применяя QNX я на 99% уверен, что смогу это сделать.

А вот применяя Linux или Windows я _наверное_ смогу это сделать, но только применив спец. "расширители" РВ для этих ОС (от того же CoDeSys, например). Но вот в чем я не уверен, так это в том, что такая система проживет больше месяца непрерывной работы.

Для системы вытягивания кремния больше месяца, наверное, и не надо, а для управления конвеером?

 

Применяя РТОС типа CMX, ... - я уверен, что кроме меня самого никто (т.е. система) динамическую память не запрашивает - я все выделяю в момент инициализации, до while(1) - рабочего цикла.

Все, что нужно после - выделяется/освобождается _только_ блоками фиксированного размера.

Применяя QNX ?? - не знаю, не пробовал.

Применяя Windows - ни в чем не уверен, чем она там занимается.

 

Ну, и маленький совет тем, кто будет делать ПЛК под Win - когда оставляете машину управлять объектом без присмотра - выдергивайте мышъ!!! Страшнее мышиных прерываний от ползания по коврику для производительности нет ! :)

[Olej 0]

А кстати - как на счёт strdup()? ;) - многие ли задумываются что они при этом делают?

А если так ;) :

void func( char* S1 ) {
   char* S2 = S1;
   ...
   return( strdup( S2) );
};

 

насчет strdup, "я такой умный вещь скажу, ты только не обижайся"(с):

в алгоритмах управления strdup-ы не встречаются. Ни к чему они там.

 

Круто!

А i++ - встречаются ? а ++i ?

Теперь осталось только проделать ревизию "встречаются" / "не встречаются" - и оформить ... "руководящим и направляющим" документом, обязательным к исполнению ;) ... что-то мне это мучительно напомнило ... а, вот оно (прошу прощения за длинную off-topic цитату)

http://qnx.org.ru/viewpagedthread7n4227n4.html :

Hа дискетке ,что пpинесли с винтом был текст.

Обpаботал - выкинул шапки-заставки , заменил фамилии , имена и цифpы символом "@" .

Пеpевёл в фоpмат "обычный текст", для облегчения объёма.

Более ничего не менял !!!

 

===================================================================

Техническому Диpектоpу

ООО "Пpоком-Электpоникс"

от Командиpа В/Ч @@@@@@

Полковника @@@@@@@@@@

 

Пpосьба.

 

Пpошу пеpеписать с жосткова диска MODEL 2B010H1 11A PCBA 05A UNIQUE 11A CODE

WAH21PBO

CILINDERS 1638 HEADS 16 SECTORS : 63 LBA 20012832

QUANTUM FIREBAL BY MAXTOR

Maxtor 541DX 5400RPM

10 Gb Ultra ATA/100 Hard Drive

1 Gb = 1,000,000,000 Bytes

2b010H1110511

Mfg Date 300CT2001

ER

Made in Singapore ( 2 ) K,M,B,A

инфоpмацию "Мои Документы" с диска "Цэ".

 

Что было : Компьютеp пеpестал пеpезагpужаться и л-т @@@@@@@@ своими силами pешил его починить.

 

Выяснилось что компьютеp не выполняет функции загpузки с жосткова диска - он включается и тутужэ останавливается.

 

Л-т @@@@@@@@@ извлёк жосткий диск из коpпуса компьютеpа, откpыл веpхнюю кpышку и смазал зеpкальную повеpхтность жидкой смазкой ЦИАТИМ-201 ГОСТ 6267-74 для облехчения скольжения узла вычитывателя, но это не помгло и инфоpмация "Мои Документы" осталась недоступной, т.к.компьютеp всёpавно не пpоизводил запуск пpогpамы Виндоуз.

 

Лично пpоконтpолиpовав последствия действий л-та @@@@@@@@@ я выяснил, что внутpи жосткого диска отсутствует узел вычитывателя,видимо неаккуpатными действиями ,нанося жидкую смазку ЦИАТИМ-201 ГОСТ 6267-74 л-т его сломал и удалил,за что обязательно будет наказан.

Hеобходимо установить на место узел вычитывателя инфоpмации и пеpеписать инфоpмацию из папки "Мои Документы" с диска "Цэ", т.к. она нужна для опеpативной pаботы В/Ч.

В пpоцесе pемонта добавочную смазку наносить нет необходимости т.к. смазка ЦИАТИМ-201 ГОСТ 6267-74 очень высокого качества и поставляется в нашу B/Ч напpямую с завода Омскнефтеоpгсинтез и используеця на большом количестве узлов и агpегатов автомобилей с дизельными двигателями. ( не китайская потделка ).

 

Пpошу пеpепесать содеpжимое папки "Мои Документы" с диска "Цэ"на компакт-диск маpки CD-RW . Дальнейшие действия с жостким диском в целях экономии Вашего вpемени можно не пpоизводить, л-т @@@@@@@@@ сам сумеет установить его в коpпус компьютеpа и пеpезагpузить его пpогpаммой Виндоуз.

 

Поpядок оплаты согластно выставленного счёта гаpантиpую.

 

Полковник @@@@@@@@@@@

В/Ч @@@@@@@@@

===================================================================

[Владимир Е. Зюбин 0]

1) однородность среды разработки/исполнения

 

Вот это как раз и настораживает: у вас когда-нибудб пропадали элементы меню"Пуск"?, а рабочий стол не превращался в "картинку", абсолютно на ваши действия не реагирующую?

 

Под win95/98 превращался, когда намешано там до кучи всего, чего только вздумается. Но редко.

А вот 2000 - ни разу. ХР - очень устойчив, нареканий нет. Причем это, опять же, системы самые "мусорные" в смысле разнородности приложений.

 

2) Видндовоз предоставляет несоизмеримо большую функциональность, т.к. это .

 

Знаете, ДОМ 2 Это тоже вроде MAINSTREAM а тем не менее меня от него почему-то воротит

:cranky: (тема отдельного разговора))) ) да и как-то логически ваши слова не увязываются:

MAINSTREAM и функциональность.

 

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

 

Вы покупаете железку, какие драйверы для нее будут в комплекте? - обычно Виндовоз, изредка редко ДОС и Линукс. Вот практически и все.

 

Как видите, ответы очень просты. Сходите, кстати, на сайт Прософта, Виндовоз продается наравне с QNX, его и позиционировать не надо... все и так все понимают, не удивлюсь, если объемы его продаж превышают позиционируемый как ОСРТ QNX.

Вы знаете, а вот туалетную бумагу тоже как то часто очень покупают... видимо потому что дёшево и с

функциональность

только вот для строительства орбитальных станций почему-то спец сплавы применяют... хм....или если рынок продиктует и она попадёт в этот самый MAINSTREAM то следующий блок для МКС будет на Байкальском целлюлозно-бумажном изготовляться?

 

Я не говорю про орбитальные станции... кстати, какие там ОС используются открытый вопрос.

Да и вообще, не очевидно что там за железо используется. ;-) Возможно, к Интелу никакого отношения не имеющее... так что, сами понимаете.

 

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

 

Технически для ОС QNX более правильная характеристика - ОС с микроядерной архитектурой. ;-)

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

 

кстати очень даже не кисло, они - именно это и делают!!! :laugh:

 

Что они делают? используют невнятные (сложные и спорные) термины? Я об этом и говорю.

Меня лично напрягает, когда меня за дурачка держат...

[Владимир Е. Зюбин 0]

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

При чем тут Рефлекс? Тут вроде ОС обсуждаются - не надо мешать все в одну кучу - про Рефлекс отдельная ветка есть.

 

Рефлекс позволяет создавать приложения без участия ОС (создавать standalone приложения). Ну, а поскольку тема топика поиск ответа на вопрос "Когда не нужна ОС РВ", тема Рефлекса тут к месту.

 

Так что один из возможных ответов на вопрос: ОС не нужна, когда есть Рефлекс и нет проблемы со standalone драйверами УСО.

 

Все очень просто. Виндовоз предоставляет: ...

Конечно, предоставляет - мелким фирмочкам сваять на коленке "пром. ПЛК", продать и свалить через месяц в неизвестном направлении (ну пару месяцев) ...

 

Ну, не знаю, под Виндовозом работет куча программ, те же LabView. Если сходить на сайт NI, можно узнать много интересного по этому поводу.

 

Может, дело в том, что тема реального времени давно устарела? Не думали над этим?

...

Понимаете, словосочетание "реальное время" уже давно используется всеми кому не лень, его заездили, ...

Технически для ОС QNX более правильная характеристика - ОС с микроядерной архитектурой. ;-)

...

Да, и и словосочетание заездили, и для QNX и любой другой ОС я бы не применял термин РТОС.

(Ну, раз их так называют, что делать, и я буду).

 

Что мне (или какому-нить пользователю ПЛК) нужно. Нужна Система РВ (не отдельная РТОС, а коробка в сборе) - управляющая система.

 

Все верно. Любого конечного пользователя интересует выполнение требований ТЗ, а не абстрактные словеса насчет непонятно чего...

 

А изнутри: Мне нужно, например, чтоб управляющая задача получала управление каждые 10мс (дрожание начала такта +- 100мкс) и занимала на 5мс ЦПУ, задача связи - ...

Применяя РТОС типа CMX, Nucleus, eCos - я знаю как это сделать (ессно. с учетом быстродействия ЦПУ и сложности алгоритма).

Применяя QNX я на 99% уверен, что смогу это сделать.

А вот применяя Linux или Windows я _наверное_ смогу это сделать, но только применив спец. "расширители" РВ для этих ОС (от того же CoDeSys, например). Но вот в чем я не уверен, так это в том, что такая система проживет больше месяца непрерывной работы.

Для системы вытягивания кремния больше месяца, наверное, и не надо, а для управления конвеером?

 

Система вытягивания кремния имеет ПЛК ядро без ОС вообще. И работать оно будет вечно (пока железо не посыпется). Виндовоз же там только для операторского интерфейса (сенсорный экран,графики, видео, голосовые сообщения, архивы и т.д. и т.п.) Получается дешево, надежно, и стильно. Но поработав с Виндовозом, которая зарекомендовала себя весьма надежной ОС, мы планируем перенести ПЛК-ядро на Виндовозную сторону.

 

Применяя РТОС типа CMX, ... - я уверен, что кроме меня самого никто (т.е. система) динамическую память не запрашивает - я все выделяю в момент инициализации, до while(1) - рабочего цикла.

Все, что нужно после - выделяется/освобождается _только_ блоками фиксированного размера.

Применяя QNX ?? - не знаю, не пробовал.

Применяя Windows - ни в чем не уверен, чем она там занимается.

 

Ну, и маленький совет тем, кто будет делать ПЛК под Win - когда оставляете машину управлять объектом без присмотра - выдергивайте мышъ!!! Страшнее мышиных прерываний от ползания по коврику для производительности нет ! :)

 

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

 

Можно предложить что-то типа такого:

Каждому процессу по ядру, а планировщиков - в корзину.

 

А кстати - как на счёт strdup()? ;) - многие ли задумываются что они при этом делают?

А если так ;) :

void func( char* S1 ) {
   char* S2 = S1;
   ...
   return( strdup( S2) );
};

 

насчет strdup, "я такой умный вещь скажу, ты только не обижайся"(с):

в алгоритмах управления strdup-ы не встречаются. Ни к чему они там.

 

Круто!

А i++ - встречаются ? а ++i ?

 

Это жизнь.

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

 

Теперь осталось только проделать ревизию "встречаются" / "не встречаются" - и оформить ... "руководящим и направляющим" документом, обязательным к исполнению ;) ... что-то мне это мучительно напомнило ... а, вот оно (прошу прощения за длинную off-topic цитату)

 

Да не нужен Си++ при описании алгоритмов управления, не нужен и не приспособлен для этого...

Поделитесь лучше, в каких случаях при управлении Вы используете strdup? Может действительно, я чего-то не понимаю. И мне надо срочно перейти на strdup-технологию.

(Олег, только, чур, без обид, мне хотелось бы, чтобы Вы вели разговор, постоянно имея ввиду промышленную автоматизацию уровня ПЛК).