Страниц: [1] 2 3 ... 14
  Печать  
Автор Тема: Объясните ламеру, что такое ОС реального времени ?  (Прочитано 56743 раз)
Anonymous
Гость
« : Июня 20, 2003, 08:50:00 pm »

Собственно сабж...
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #1 : Июня 20, 2003, 08:56:00 pm »


Anonymous пишет:
Собственно сабж...


Когда-то dmi брался об том статью написать ... хороший был черновик .
Можно почитать кое-что здесь: www.swd.ru
Можно здесь: www.nautsilus.ru/sys/winnt.htm (там, собственно, о том "что не является realtime" - но методом исключения понятно).

В 2-х словах: что если "быстро, круто, cool ..." - то это как-раз не то .
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #2 : Июня 20, 2003, 11:07:00 pm »


Olej пишет:

Anonymous пишет:
Собственно сабж...


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

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


В 2-х словах: что если "быстро, круто, cool ..." - то это как-раз не то .

Agreed.

Общий смысл теории ОСРВ сводится к недавно услышанной фразе на /. :
"...when a nuclear reactor is about to blow, every nano-second counts". И это есть "very true"(c).
Записан
klalafuda
QOR.Team
****
Offline Offline

Сообщений: 1


Просмотр профиля
« Ответ #3 : Июня 20, 2003, 11:11:00 pm »


dmi пишет:

Olej пишет:

Anonymous пишет:
Собственно сабж...


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

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


В 2-х словах: что если "быстро, круто, cool ..." - то это как-раз не то .

Agreed.

Общий смысл теории ОСРВ сводится к недавно услышанной фразе на /. :
"...when a nuclear reactor is about to blow, every nano-second counts". И это есть "very true"(c).


точно. lestat подтвердит

// wbr
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #4 : Июня 20, 2003, 11:28:00 pm »

2 dmi
Дима! А нельзя ли в приватном порядке почитать этот черновик - помнится во времена зарождения форума (был тогда раздел "Теория ОСРВ") мы пытались обсуждать этот вопрос...

Клятвенно обещаю не пользоваться продуктами "второй свежести"
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #5 : Июня 20, 2003, 11:50:00 pm »


Evgeniy пишет:
2 dmi
Дима! А нельзя ли в приватном порядке почитать этот черновик - помнится во времена зарождения форума (был тогда раздел "Теория ОСРВ") мы пытались обсуждать этот вопрос...

Клятвенно обещаю не пользоваться продуктами "второй свежести"


Мне очень стыдно за этот опус. Боюсь мне было стыдно настолько, что я его потерял. По крайней мере найти его не могу - ни на дисках, ни в почте я его не вижу.
Olej: не посылал ли я случайно этот черновик почтой?

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

Это всё будет не раньше июля месяца, т.к. сейчас сдаю экзамены и ищу работу.


[ Это Сообщение было отредактировано: dmi в 2003-06-20 21:49 ]
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #6 : Июня 21, 2003, 04:53:00 am »

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

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

Реальных же методов расчёта компьютерных систем работающих в реальном масштабе времени не существует. По крайней мере – известных мне.

--

На самом деле, вопрос всем: постановка задачи ОСРВ и диспетчера задач ОСРВ. Как они звучат?

Что-нибудь вроде: считая актуальность каждой из выполняемых задач суммой заранее известного веса и времени её простоя в состоянии готовности, распределить процессорное время между задачами таким образом, чтобы не позволить наиболее актуальной на данный момент задаче простаивать дольше некоего заранее декларированного периода времени?
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #7 : Июня 21, 2003, 06:58:00 am »


dmi пишет:
ОСРВ, в теории,- это ОС, которая “привязывает” процесс выполнения своих задач к сетке (реального/живого)времени и обеспечивает наихудшее время задержки не более декларированного. Т.е. остаётся предсказуемой по времени реакции даже при очень высоких нагрузках.
Т.е. ОСРВ – это ОС, которая всё делает вовремя

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

Я, кажется, уже писал (в том давнем форуме), что на самом деле, говоря о реальном времени, надр говорить не столько о собственно ОС, сколько о системе управления вцелом - в том числе с учетом конкретного оборудования, на котором система работает.


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

Совершенно с вами согласен. Только я бы сказал, что не по более жестким правилам, а со многими упрощениями - такими как фиксированные уровни приоритетов процессов или упрощенное управление памятью.

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

Собственно, именно этот стиль "конструктора" и является, как мне кажется, принципиальной отличительной чертой ОС РВ. Сразу оговорюсь, что это не имеет абсолютно ничего общего с "open source"


Реальных же методов расчёта компьютерных систем работающих в реальном масштабе времени не существует. По крайней мере – известных мне.

Вы не одиноки во вселенной
Думаю, что ничего кроме теории систем массового обслуживания и иммитационного моделирования вам никто не предложит На практике и этот аппарат не сильно используется - лично мне не приходилось встречать чего-то более формального, чем общие "верхние" оценки (в смысле "наверняка успеет - не успеет") на основе личного опыта
--


На самом деле, вопрос всем: постановка задачи ОСРВ и диспетчера задач ОСРВ. Как они звучат?

Что-нибудь вроде: считая актуальность каждой из выполняемых задач суммой заранее известного веса и времени её простоя в состоянии готовности, распределить процессорное время между задачами таким образом, чтобы не позволить наиболее актуальной на данный момент задаче простаивать дольше некоего заранее декларированного периода времени?

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

А на практике поступают проще - приоритет пропорционален проценту времени, в течении которого процесс чего-то ждет. И опять же эта оценка делается статически из самых общих (т.е. среднепотолочных) соображений
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #8 : Июня 21, 2003, 08:40:00 pm »


Evgeniy пишет:
Я, кажется, уже писал (в том давнем форуме), что на самом деле, говоря о реальном времени, надр говорить не столько о собственно ОС, сколько о системе управления вцелом - в том числе с учетом конкретного оборудования, на котором система работает.


Безусловно. Система реального времени есть аппаратная платформа + ОС РВ, которая управляет этой платформой.
Честно говоря, я не очень согласен с самим переводом слова realtime. Для меня слова “реальное время” не звучат как одно целое, потому как время – суть абстракция. К тому же тогда придётся отнести все системы общего назначения к системам “нереального” времени, что будет уже абсолютным заблуждением. Все они способны соответствовать требованиям на ОСРВ в каких-то (может быть достаточно узких) рамках. Большая часть из них реализует части POSIX 1003.1, который, напомню, говорит: “Реальное время  в операционных системах – это способность операционной системы обеспечить требуемый уровень сервиса в заданный промежуток времени”.
Мой текстовый редактор, работающий в ОС Linux, вполне отвечает моим требованиями на время реакции на мои действия
Мне кажется, что realtime скорее можно перевести как “ОС постоянной  доступности”, или, может быть, готовности.
Evgeniy: как вообще перевести слово “realtime” в отрыве от данного контекста? И как (варианты) может звучать перевод? “ОС полной занятости”?

Для меня понятие ОСРВ (а, точнее, СРВ) включает:
надёжность (система достаточно надёжна, чтобы постоянно выполнять возложенные задачи, либо(??) обладает достаточным запасом резервирования и/или способностью к самовосстановлению (регенерации));
масштабируемость (или встраиваемость, т.е. компактность исполнения);
возможность работы со специфичным оборудованием (опять же – встраиваемость);
предсказуемость временных параметров даже в самых “дальних” ветвях дерева рисков;


Совершенно с вами согласен. Только я бы сказал, что не по более жестким правилам, а со многими упрощениями - такими как фиксированные уровни приоритетов процессов или упрощенное управление памятью.


Просто упрощения не приведут к предсказуемости системы. Ввод в ОС РВ фиксированных приоритетов (точнее, я бы сказал, статических, потому как фиксированные – это RMS!) - вполне сознательное требование, чтобы разработчик изначально распределил “веса” задач системы. Потому как только Разработчик СРВ может предвидеть последствия сбоя (т.е. пропуска своей “очереди”), система же понятия не имеет, сколько раз можно есть эти грибы.
Это уменьшение степени нечёткости системы, сл-но ужесточение правил управления ею. К тому же, я думаю, такие “упрощения” очень недёшево обходятся разработчикам ОСРВ.


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

Т.е. встраиваемость и масштабируемость. Это уже требования больше к встраиваемой (embedded) ОС. Хотя, безусловно, любая настоящая ОС РВ должна быть embedded. Пора строить дерево классификации ОС?


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

Тут слово “пользователь” следует использовать очень осторожно. У встраиваемых ОС РВ не бывает пользователей, в лучшем случае – операторы.
Есть разработчики, для них и документация. Опять же, дело не только в документации, а скорее, в возможности восприятия разработчиком общей идеи ОС, т.е. максимальной прозрачности механизмов ОС.


Собственно, именно этот стиль "конструктора" и является, как мне кажется, принципиальной отличительной чертой ОС РВ.

Одной из. Самой важной чертой является ответственность разработчиков ОСРВ за свою систему.


Сразу оговорюсь, что это не имеет абсолютно ничего общего с "open source"

М/у прочим, open source RTOS – очень интересная тема для обсуждения!
Не является ли уход в open source фактическим заявлением о прекращении существования ОСРВ как продукта?


Вы не одиноки во вселенной

Так я и знал


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


Ну есть же какие-то потуги в области разработки “deadline-driven scheduling” например. Это ведь действительная привязка к шкале живого времени. Вообще интересно было бы посмотреть на мат.аппарат, модель или чёткое описание чего-то такого.

Конечно, я понимаю, что лучшая ОСРВ – это однозадачная ОСРВ , т.е либо полное её отсутствие как вида, либо DOS and friends. Самое смешное, что если система не распределённая – это самый действенный способ устранения неопределённости временных характеристик системы. С другой стороны, установление связей м/у узлами распределённой системы – самое деструктивное действие. Потому как любой коммуникационный протокол может быть лишь условно предсказуем
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #9 : Июня 25, 2003, 11:21:00 pm »


Evgeniy пишет:
2 dmi
Дима! А нельзя ли в приватном порядке почитать этот черновик - помнится во времена зарождения форума (был тогда раздел "Теория ОСРВ") мы пытались обсуждать этот вопрос...


Кстати, с тех пор прошло ... ох как много времени: многое удалось "пощупать руками", новые материалы попадались. Интересный subj - если кому-то ещё интересно - можно поделиться свежими соображениями. В этой теме ... или заведите какую новую.
Записан
dmi
QOR.Admin
*****
Offline Offline

Сообщений: 469



Просмотр профиля
« Ответ #10 : Июня 26, 2003, 01:00:00 am »


Olej пишет:

Evgeniy пишет:
2 dmi
Дима! А нельзя ли в приватном порядке почитать этот черновик - помнится во времена зарождения форума (был тогда раздел "Теория ОСРВ") мы пытались обсуждать этот вопрос...


Кстати, с тех пор прошло ... ох как много времени: многое удалось "пощупать руками", новые материалы попадались. Интересный subj

У меня от этого слова зуб болит. передний.


- если кому-то ещё интересно - можно поделиться свежими соображениями. В этой теме ... или заведите какую новую.

Интересно. А почему бы и не здесь?
Записан
Evgeniy
Jr. Member
**
Offline Offline

Сообщений: 73


Просмотр профиля
« Ответ #11 : Июня 26, 2003, 04:20:00 am »


dmi пишет:

Evgeniy пишет:
Я, кажется, уже писал (в том давнем форуме), что на самом деле, говоря о реальном времени, надр говорить не столько о собственно ОС, сколько о системе управления вцелом - в том числе с учетом конкретного оборудования, на котором система работает.


Безусловно. Система реального времени есть аппаратная платформа + ОС РВ, которая управляет этой платформой.

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


Честно говоря, я не очень согласен с самим переводом слова realtime. Для меня слова “реальное время” не звучат как одно целое, потому как время – суть абстракция. К тому же тогда придётся отнести все системы общего назначения к системам “нереального” времени, что будет уже абсолютным заблуждением. Все они способны соответствовать требованиям на ОСРВ в каких-то (может быть достаточно узких) рамках. Большая часть из них реализует части POSIX 1003.1, который, напомню, говорит: “Реальное время  в операционных системах – это способность операционной системы обеспечить требуемый уровень сервиса в заданный промежуток времени”.

Давайте не будем углубляться в физику пространства-времени и тем более в философию
Однако на правах старого питона позволю себе один небольшой исторический экскурс.
Вероятно, впервые понятие real-time появилось с появлением первой управляющей цифровой машины - если не ошибаюсь это была какая-то модель HP (первая), известная в Союзе по ее клону М6000. В те времена (прямо как в какой-то сказке ) все цифровые машины были представлены мэйнфреймами с ПАКЕТНЫМ режимом работы. И, собственно, термин real-time использовался для противопоставления выполнения программ в пакетном режиме без синхронного взаимодействия с внешним миром, режиму, когда приложения "непосредственно" взаимодействуют с источниками/получателями информации. При этом под понятие real-time подпадали не только системы АСУТП, но и все интерактивные системы тоже. В частности первая глобальная информационная система New York Times, построенная на базе OS/360 тоже рассматривалась как система реального времени. В этот же класс попадали и системы резервирования билетов ("Сирена" вообще использовала управляющие минимашины СМ-2М) и все прочие on-line системы.


Мой текстовый редактор, работающий в ОС Linux, вполне отвечает моим требованиями на время реакции на мои действия
Мне кажется, что realtime скорее можно перевести как “ОС постоянной  доступности”, или, может быть, готовности.
Evgeniy: как вообще перевести слово “realtime” в отрыве от данного контекста? И как (варианты) может звучать перевод? “ОС полной занятости”?

Да буквально - реального времени, хотя это и не суть важно. Как я уже говорил выше, бессмысленно говорить о реальном времени в отрыве от приложений. Сам термин лишь подчеркивает отличие пакетного выполнения (фактически вне реального времени существования физических, материальных процессов - в модельном времени) от выполнения в процессе взаимодействия с реальными процессами в соответствии и темпом их развития в реальном мире. "Во как завернуто - заворочено! Ух, силен я бродяга!" (С)


Для меня понятие ОСРВ (а, точнее, СРВ) включает:
надёжность (система достаточно надёжна, чтобы постоянно выполнять возложенные задачи, либо(??) обладает достаточным запасом резервирования и/или способностью к самовосстановлению (регенерации));
масштабируемость (или встраиваемость, т.е. компактность исполнения);
возможность работы со специфичным оборудованием (опять же – встраиваемость);
предсказуемость временных параметров даже в самых “дальних” ветвях дерева рисков;

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



Совершенно с вами согласен. Только я бы сказал, что не по более жестким правилам, а со многими упрощениями - такими как фиксированные уровни приоритетов процессов или упрощенное управление памятью.


Просто упрощения не приведут к предсказуемости системы. Ввод в ОС РВ фиксированных приоритетов (точнее, я бы сказал, статических, потому как фиксированные – это RMS!) - вполне сознательное требование, чтобы разработчик изначально распределил “веса” задач системы. Потому как только Разработчик СРВ может предвидеть последствия сбоя (т.е. пропуска своей “очереди”), система же понятия не имеет, сколько раз можно есть эти грибы.
Это уменьшение степени нечёткости системы, сл-но ужесточение правил управления ею. К тому же, я думаю, такие “упрощения” очень недёшево обходятся разработчикам ОСРВ.

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




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

Т.е. встраиваемость и масштабируемость. Это уже требования больше к встраиваемой (embedded) ОС. Хотя, безусловно, любая настоящая ОС РВ должна быть embedded. Пора строить дерево классификации ОС?

Ну почему "встраиваемость и масштабируемость"? Представьте себе систему управления любым достаточно большим техпроцессом - там тысячи самых разных датчиков и исполнительных механизмов и для всех нужны драйвера. А всякий коструктор этого железа ничего знать не знает (да и не хочет знать!) о проблемах программистов и наровит придумать что-то свое исходя из каких-то своих соображений, весьма далеких от проблем АСУТП. И привязывать все это добро к системе управления приходится разработчику системы управления, а не поставщику ОС - никакая QSS, HP или НПО "Импульс" знать об этих железках не знает и знат не желает - и это правильно



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

Тут слово “пользователь” следует использовать очень осторожно. У встраиваемых ОС РВ не бывает пользователей, в лучшем случае – операторы.
Есть разработчики, для них и документация.

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



Собственно, именно этот стиль "конструктора" и является, как мне кажется, принципиальной отличительной чертой ОС РВ.

Одной из. Самой важной чертой является ответственность разработчиков ОСРВ за свою систему.

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



Сразу оговорюсь, что это не имеет абсолютно ничего общего с "open source"

М/у прочим, open source RTOS – очень интересная тема для обсуждения!
Не является ли уход в open source фактическим заявлением о прекращении существования ОСРВ как продукта?

А кто делает такие заявления об уходе в open source?


Конечно, я понимаю, что лучшая ОСРВ – это однозадачная ОСРВ , т.е либо полное её отсутствие как вида, либо DOS and friends. Самое смешное, что если система не распределённая – это самый действенный способ устранения неопределённости временных характеристик системы. С другой стороны, установление связей м/у узлами распределённой системы – самое деструктивное действие. Потому как любой коммуникационный протокол может быть лишь условно предсказуем

И видимо поэтому "DOS жил, DOS жив, DOS будет жить!" И вообще он "...живее всех живых!"

Видите ли, Дима... Любое взаимодействие с реальным оборудованием является "лищь условно предсказуемым" и коммуникации здесь не исключение. А кроме того, предсказуемость поведения системы подразумевает предсказуемость и в случае отказов...

[ Это Сообщение было отредактировано: Evgeniy в 2003-06-26 01:45 ]
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #12 : Июня 29, 2003, 05:01:00 pm »


 dmi пишет:
Конечно, я понимаю, что лучшая ОСРВ – это однозадачная ОСРВ , т.е либо полное её отсутствие как вида, либо DOS and friends. Самое смешное, что если система не распределённая – это самый действенный способ устранения неопределённости временных характеристик систе


Такое мнение, и мнение широко распространённое, мягко говоря - сильно преувеличено (IMHO;-)):

- ещё MS "купились" на него, и до DOS 3.30 система не предусматривала каких либо асинхронных ветвлений, но они же, самого начала на него и попались: для подсистемы печати пришлось сразу же "изобретать" совершенно загадочный способ "через задницу", который потом развился в более или менее универсальные механизмы: INT 2F - TSR - сохранение/ восстановление PSP ... etc. Так что  MS DOS, даже 2.0 - уже не была "однозадачная"... Ну и что? - сильно добавила им их "почти однозадачность" в смысле надёжности и предсказуемости?

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

- ни одна реальная, достаточно сложная система, подлежащая управлению ОСРВ - не детерминирована и не предсказуема в своём поведении, в смысле асинхронности её реакций в условиях функционирования, а значит "однолинейная" система управления рано или поздно окажется не в состоянии реагировать на сложность стимулов ... и окажется "непредсказуемой" т.е. "загнётся". Т.е., опять же: "реалтаймовость", предстказуемость, надёжность последовательностного ПО - это эффект только простоты класса задач, решаемых ... "в такой манере".

- давно уже и много сказано, написано объёмными примерами и т.д. "классиками", тем же Э.Дейкстрой, что даже казалось бы совершенно последовательностные вычислительные процессы (при сложности выше какой-то) часто оказывается гораздо проще (логичнее, понятнее, верифицированнее!;-)) описать большим числом параллельно (пусть даже совершенно "квазипараллелно") выполняющихся ветвей. А все эти качества (см.выше) - это, в конечном итоге - и есть гарантия предсказуемости поведения ПО и
отсутствия в нём "глухих углов" (вспомните тут же утверждение, к которому шли долгие годы, пока стало понятно: "Никаким, сколь угодно тщательным и спланированым тестированием нельзя достоверно доказать безошибочность функционирования программы").

P.S. Я сам иногда, в сердцах, сержусь по случаю, если не ладится что-то: вот как просто,  хорошо и понятно было в DOS... Но это всё не из области реалий, а из области "ностальгии": задачи там решались те, которые "под силу DOS", т.е. на голову проще - вот они и решались ... доступно и просто.
Записан
ed1k
QOR.Moderator
*****
Offline Offline

Сообщений: 739


Просмотр профиля WWW
« Ответ #13 : Июня 30, 2003, 04:37:00 am »


Olej пишет:
- ещё MS "купились" на него...

MS не покупалась, MS купила DOS. Шо купила, те i мала.

для подсистемы печати пришлось сразу же "изобретать" совершенно загадочный способ "через задницу", который потом развился в более или менее универсальные механизмы: INT 2F - TSR...

Это смотря как посмотреть. Им не пришлось "изобретать" подсистему печати, так как всегда можно было скопировать файл на LPT и подождать когда он распечатается. Просто немного подумав они добавили возможность фоновой печати (print) в систему, исходя из анализа требований основных покупателей системы на тот момент.

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

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

- ни одна реальная, достаточно сложная система, подлежащая управлению ОСРВ - не детерминирована и не предсказуема в своём поведении, в смысле асинхронности её реакций в условиях функционирования, а значит "однолинейная" система управления рано или поздно окажется не в состоянии реагировать на сложность стимулов ... и окажется "непредсказуемой" т.е. "загнётся". Т.е., опять же: "реалтаймовость", предстказуемость, надёжность последовательностного ПО - это эффект только простоты класса задач, решаемых ... "в такой манере".

Любая, сколь угодно сложная система, если она критическая, не зависимо управляется она ОСРВ или любой другой системой, является абсолютно детерминированной и предсказуемой. Детеменированность и предсказуемость определяется умениями разработчиков системы и её критичностью. Если в силу каких либо обстоятельств, система не полностью детерминирована рано или поздно произойдет сбой системы, не зависимо чем она управляется: DOS, RTOS или без какой-либо ОС. Про "сложность стимулов" вообще сильно сказано. Я не совсем понял, что вы имели ввиду Но смею вас заверить, любые сложности стимулов предусматриваются при разработке системы. Если система достаточно критическая - то ставится детектор сложности стимулов, и при превышении заданного порога сложности стимулов система обрабатывает ситуцию "Авария: превышение сложности стимулов" - это может быть останов системы, самоликвидация системы, переход на альтернативный алгоритм управления и т.д. Если разработчик чего-либо не предусмотрел, то происходит что-то плохое, опять же таки не зависимо, чем это всё управляется, ДОСом или QNXом, по одной простой причине - случилось не предвиденное.

В общем, ладно. Обломило меня писать больше. Не согласен я крепко. Разработка в ОСРВ зачастую бывает на порядки дешевле и быстрее, чем в DOS или вообще без ОС, так как часто необходимые компоненты уже есть. А надежность и предсказумость тут не причём. Разработка систем вообще без ОС или со своей ОС, дело кропотливое и дорогое, но списывать баги не на кого.
Записан
olej
QOR.Team
****
Offline Offline

Сообщений: 42



Просмотр профиля
« Ответ #14 : Июня 30, 2003, 06:36:00 am »


ed1k пишет:
Любая, сколь угодно сложная система, если она критическая, не зависимо управляется она ОСРВ или любой другой системой, является абсолютно детерминированной и предсказуемой. Детеменированность и предсказуемость определяется умениями разработчиков системы и её критичностью. Если в силу каких либо обстоятельств, система не полностью детерминирована рано или поздно произойдет сбой системы, не зависимо чем она управляется: DOS, RTOS или без какой-либо ОС. Про "сложность стимулов" вообще сильно сказано. Я не совсем понял, что вы имели ввиду Но смею вас заверить, любые сложности стимулов предусматриваются при разработке системы. Если система достаточно критическая - то ставится детектор сложности стимулов, и при превышении заданного порога сложности стимулов система обрабатывает ситуцию "Авария: превышение сложности стимулов" - это может быть останов системы, самоликвидация системы, переход на альтернативный алгоритм управления и т.д. Если разработчик чего-либо не предусмотрел, то происходит что-то плохое, опять же таки не зависимо, чем это всё управляется, ДОСом или QNXом, по одной простой причине - случилось не предвиденное.

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


В общем, ладно. Обломило меня писать больше. Не согласен я крепко.

- Не согласный я!
- А с кем: с Каутским или с Энгельсом?
- Да с обоими... (с)М.Булгаков


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

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



Записан
Страниц: [1] 2 3 ... 14
  Печать  
 
Перейти в: