Comments 70
Чем не устраивает определение RTOS из википедии
Там кстати, ссылка на список RTOS есть.
Из которого следует, что Windows CE и Windows 10 IoT - это RTOS, а остальные виндоусы - не RTOS.
Все ясно и понятно.
Насколько я знаю, список в википедии можно подкорректировать при желании. Там же нет математически точного критерия по которому составлен этот список? Или я что то пропустил?
Ну подкорректируйте.
Интересно долго ли там останется висеть Windows 11 Home Edition.
Там же нет математически точного критерия по которому составлен этот список?Списки наполняются согласно требованиям, одним из которых является «Список должен основываться на авторитетных источниках».
Добавить вы, конечно, можете что угодно (хоть глокую куздру туда вписать) и это даже может провисеть неопределенное время, особенно, если статья малопопулярная (как и в любом проекте с добровольным участием, баг будет жить до тех пор, пока кто-то его не заметит и не пожелает исправить). Но тем самым вы лишь будете вводить читателей в заблуждение. Реальность же не изменится от того, что в Википедии кто-то навандалил, Windows 11 Home от этого в RTOS не превратится.
Кстати, очень интересно! Там упоминается (правда как то мельком) то что я называю разрешением по времени:
the variability is 'jitter' или it is called timing jitter как, практически: A key characteristic of an RTOS
Можно говорить, на буржуйский манер:
Тайминг житер - мера предсказуемости.
Так что все устраивает - хотел привлечь внимание к деталям!
Спасибо что заставили вчитаться.
Меня в детстве учили, что ядро РТОС должно гарантировать время ответа на событие, ну или по буржуйской ссылке
A key characteristic of an RTOS is the level of its consistency
concerning the amount of time it takes to accept and complete an
application's task;
Зачем выдумывать более сложные определения?
Можно добавить, что на x86 не может быть rtos с 80386 машины :)
Только с объяснением! )
smm
Посмотрел в Вики. Там есть такой абзац:
ОС Windows и ядро Linux устанавливают «SMI Timeout» — период времени, в который любая программа SMM должна вернуть управление операционной системе.
Поскольку smm более привилегирована по сравнению с ос, я правильно понимаю, что только благое пожелание со стороны ос, которое smm может проигнорировать?
С другой стороны, вход в smm происходит по прерыванию SMI, которое ведь можно и не генерировать ни аппаратно ни программно? Только для этого, наверное, материнская плата должна быть собственной разработки...
небольшое добавление, на практике главное качество системы реального времени это guaranteed response time, обычно это самое критичное (но не единственное) требование, причем это требование постепенно становилось более жестким, начиная с ранних систем имевших response time порядка десятков миллисекунд, до единиц и менее, т.е. само понятие систем реального времени изменялось, что касается термина "операционная система" (operating system) imho раннее использование термина восходит к проектированию sage, там все sw было разделено на две группы - то что крутилось в реальном времени называлось operating system, и все остальное (в огромном количестве) считалось технологическим, куда относились в том числе первые assembler, compiler и пр. , по времени это примерно середина 50х, эта терминология вошла в употребление, сначала через общение, затем в документации, статьях и книгах
Я бы все таки больше склонялся к такому определению -
an RTOS is an operating system designed to meet strict deadlines
Взято отсюда
Ключевое слово - designed
Потому что вот прямо сейчас у меня много дней Windows 11 работает в реальном времени. Очень жестко укладывается в 3 мс, все такты контролируются. Еще не было ни одного сбоя.
Но почему она не RTOS? Очевидно потому что производитель не делал ее как RTOS. Почему мы не можем проигнорить мнение производителя и использовать ее как RTOS? Потому что у нас нет ее сорсов и она слишком комплексна для выполнения полного профайлинга. Вот и все дела.
Если ось открыта, достаточно обозрима, у нее жесткая политика коммитов и верификаций, в ней нет сторонних драйверов, у нас на нее права, то мы любую ось можем сделать RTOS.
У всех осей есть планировщик, есть инструменты синхронизации, есть вытеснение, прерывания и все что нужно. Остается только провести тесты и выполнить профайлинг сервисов. Для сервисов с плохим детерминизмом либо переписать, либо не юзать в критических задачах.
Вот в Windows 11 мы такого сделать не можем. У нас нет на это прав и нам их не дадут. А в Windows CE мы такое могли. Там давали все сорсы. Я сам ее портировал на свое железо для realtime.
Так что в целом там джитер, не джитер - дело второстепенное. Главное - возможность полного аудита и профайлинга.
Очевидно потому что производитель не делал ее как RTOS Потому, что x86 не может быть rtos
Да ну? Половина ПЛК на базе Атомов и Целеронов...
Пример RTOS c поддержкой всего чего только можно https://en.wikipedia.org/wiki/VxWorks
У всех многозадачных ОС есть примитивы синхронизации и планировщик, но далеко не у всех они гарантируют, что ожидание на примитиве синхронизации не затянется на вечность, равно как и то, что готовый к запуску поток хоть когда-то получит управление. Что, например, не найдётся другой поток, который очень неудачно манипулируя системными вызовами не вызовет совершенно неожиданый эффект остановки первого потока. Вот о чём речь. Эффект вызванный применяемыми в ОС алгоритмами. Дело совершенно не в Java, сборщике мусора, x86, C++, непредсказуемом суперскалярном и спекулятивном выполнении программ, работе кеш-памяти, и не в чём-то таком ещё таком.
Дело в устройстве базовых механизмов самой ОС. Которую можно либо относительно просто сделать таковой, каковы есть типовые ОС общего назначения, либо путём достаточно сложных усилий превратить в ОСРВ, усложнив труд разработчиков прикладного уровня на порядок. Потому, что сами программы прикладного уровня тоже часто не готовы к работе в "реальном времени". Что никому попросту не нужно.
Эта проблема пронизывает все слои API, от прикладного до ядра ОС.
Чтобы что-то точно гарантировать во времени вам нужен:
очень древний простой процессор или микроконтроллер.
Простой предсказуемый язык программирования.
Простая операционная система.
Платформонезависимость ОС.
1 пункт. Современные процессоры уже недерминированы во времени. - промахи кэша, предсказтели переходов, конкуренция системных шин, многоядерность. Внезапно питоновский говнокод из юзерспейса может замедлять процессы в кернеле, потому что нагружают шину памяти, сам наблюдал.
2 пункт. С++ с созданием и разрушением объектов в памяти, Java со сборщиком мусора - всё это баловство. Только ассемблер и только Си. Я не очень в курсе модного Раста, но под подозрением сильное использование стека, динамической памяти.
3 пункт. Задачу можно доказать математически в случае простой понятной структуры и сильно ограниченного количества кода. Линукс содержит безумное количество кода и меняется от релиза к релизу. Что-то доказывать там просто невозможно. Тоже относится и к Винде. То есть Винда слишком сложная чтобы что-то гарантировать.
4. Линукс, к примеру, не является софтверно независимой системой для точного вычисления квантов времени. Значения таймеров там в попугаях и меняются там даже в пределах одного вендора. К примеру, наносекундный таймер не возвращает значение наносекунд, а тупо значение аппаратного таймера в попугаях.
У меня есть успешный опыт "превращения обычного Линукса в ОСРВ" - просто изолировав одно ядро под мои задачи, отключив вытесняюющую многозадачность. По замерам логического анализатора (сбор миллионов событий) - было похоже что время реакции моего драйвера на GPIO, скажем, для некоторого процессора лучше чем 30 мкс. Но является ли это ОСРВ? - сильно вряд ли. Никто не может гарантировать что что-то пойдет не так.
Итого, моё авторское определение - ОСРВ это то что написано на ассемблере или Си размером в пару килобайт. А если больше, то это должны быть не досужие домыслы, а толстый том с документацией почему это так, а также соответствующие сертификаты.
> Итого, моё авторское определение - ОСРВ это то что написано на ассемблере или Си размером в пару килобайт. А если больше, то это должны быть не досужие домыслы, а толстый том с документацией почему это так, а также соответствующие сертификаты.
Вы все правильно пишете, и определение симпатичное :)
Но насколько понимаю, автор статьи довольно широкие цели ставит типа написать вообще про системы реального времени, что трудно потому как все они разные.
Тоже есть опыт использования linux в real time embedded, чуть ли не с 2.2, когда montavista patch еще не была сделана, так что вполне Вас понимаю, до этого даже не помню точно сколько других систем реального времени, начиная с mainframes, но не в этом дело, если требуется, системы реального времени делались и будут делаться так как надо и на том что есть, включая необходимую сертификацию и пр. (тома документации точно как Вы говорите), просто дорогое это удовольствие, а для самых интересных проектов даже супер дорогое
ps
30 мкс вполне правдоподобно, хотя и много по нынешним временам
Яркий пример системы RTOS, это minix 3 в чипсетах :) До этого была ThreadX . Теперь с этой системой RTOS давайте попробуем запустить еще одну систему RTOS :)
"Если у вас кино записано с частотой, скажем, 25 (а бывает и 50, и 60) кадров в секунду, это значит у вас есть 1000/25 = 40 мс чтобы..."
-- нет, не 40мс. В мультимедиа системах всегда есть буферизация и буфер совершенно неприличного размера. Я работал в организации занимающейся телевизионными приставками (set top box) и там была платформа у которой буфер достигал почти что 9 (девяти!) секунд в определённых обстоятельствах. Это значит если смотришь футбол, то вначале слышишь вопли "Гооол!" от соседей, а потом только собственно гол у тебя. Обычно не так экстремально, но бытовой телевизор LG даёт несколько сотен миллисекунд, например. Без использования функций time shift и DVR. Буферизируется и сколько-то кадров видео, ну и звук само собой.
Лучшим примером были бы компьютерные игры. Где картинка от джойстика не может отставать более чем на несколько десятков мс, и звук соответственно тоже. Иначе у игрока будет ощущение "резинового" управления. На самом деле даже бывает единиц миллисекунд.
если вы постоянно тратите больше 40 милисекунд скажем 45, то через
9сек * 1000 / (45 - 40) = 1800 кадров / 25 кадров в секунду = 72 секунды
у вас буфер переполнится!
Поэтому не совсем понятно почему вы считаете что 9 секунд буфера это какое то запредельное значение.
И почему вы считаете что 9 секунд буфера решают все проблемы, не понятно.
Речь о том, что время реакции системы на событие может быть недетерминированным. И в 40мс не уложится. В каком-то одном конкретном случае. Но в среднем система успевает перелопатить на порядок большие объемы данных, само собой. Потому, что если она не успевает в среднем, то уже никакие RTOS ни чем не помогут.
А про компьютерные игры через интернет, это я согласен, это какая то не постижимая задача реального времени, да еще и распределенного времени. Учета задержек до разнесенных на сотни (может тысячи) километров локаций.
Но я думаю, в основе лежит какая то простая до очевидности идея, которая становится таковой после знакомства с этой идеей, как это обычно бывает - все гениальное просто.
Вы напрасно ввязались в дискуссию именно на этом примере, он ущербен по своей сути (последующее Ваше сообщение от этого свободно). Стриминг и кодирование/декодирование видео крайне редко являются реалтаймовыми задачами. Как и внутри-системная подкачка данных при всяческих играх и 3D-моделировании. Пропуск кадра или нескольких в подавляющем большинстве случаев не приводит к фатальным обще-системным последствиям. Так, просматривая киношку легко можно не заметить пропуска кадра, поскольку и среда передачи и универсализация средств воспроизведения (aka транслируемую киношку должно производить любое оборудование, независимо от его производительности) априори закладывают необходимость во встроенных средствах регенерации потока в условиях неизбежности потерь. Дублирование кадров и даже пропуск совершенно типичное явление, которое просто нежелательно, но никак не критическое.
Автор осознанно или неосознанно об этом и сам говорит, апеллируя к soft real-time системам. Науке и промышленности такие системы как минимум не интересны и как максимум вредны. Уже давно никто в здравом уме не заморачивается прикручиванием особых программных или аппаратных средств (плюс, соответствующего мат. аппарата для их анализа) для решения задач, в которых всем пИливать на собственно реалтаймовость (aka предсказуемость). Если можно взять банальный Linux для тех же задач, то накой городить огород? Лет так дцать назад бытовало мнение, что этот самый нестрогий реалтайм ввели в обиход из маркетологических соображений. Кто знает, может и так.
Обратный пример, когда эта задача может действительно стать реалтаймовой - добыча алмазов из сырой породы. На конвейере проносится сырая руда, которая посредством скоростной камеры (м.б. рентгеновской, х.з. не мой профиль) контролируется на предмет артефактов. Фактически тут есть и видео поток и недопустимость потерь = реалтаймовая обработка видео. Никакой soft real-time тут использовать нельзя. Только по жести и только по hard-у.
Где картинка от джойстика не может отставать более чем на несколько десятков мс, и звук соответственно тоже
Да может. Выкинули пару кадров и картинка догнала реальность. Вы когда музыку слушали - "карканье" встречали? Вот это оно самое - пропуск буфера, который не успел. В противном случае вы бы в этот момент слышали ра-а-астянутый по времени, но целостный по своей сути звук. И вот это был бы трушный реалтаймовый эксприенс (как нынче модно говорить). С рендерингом это продемонстрировать сложнее, но тоже можно.
Пропуск кадров в видео вообще обыденное дело. Ибо скорость их поступления из сети -- определяется тактовым генератором вещательного оборудования. А скорость воспроизведения -- локальным кварцевым резонатором, который имеет абсолютную составляющую погрешности в десятки миллионных долей -- запросто, если не сотни. В итоге видео и звук всегда проигрываются быстрей или медленей чем поступает из сети. На миллионные доли, но тем не менее. На интервалах в минуты это неизбежно приводит к необходимости повторять два раза или пропускать кадры.
Со звуком сложней. Там нельзя ничего пропустить, будет сразу заметно на слух (разрыв фазы, искажение частоты). В качественном ПО обычно для этого осуществляется передискретизация входного потока на фиксированную частоту воспроизведения и при этом можно манипулируя входной частотой квантизации можно добиться разной скорости воспроизведения без разрывов фазы и искажений частоты на выходе.
Но к сожалению, многим программистам вот этот факт объяснить практически невозможно. Поэтому существует полно некачественных проигрывателей в которых периодически, то видео со звуком рассинхронизируется, то возникают щелчки, то просто всё затыкается через полчаса просмотра. :-( Синхронизация должна осуществляться по звуку, звук требует передискретизации из-за мельчайшей разницы между скоростью поступления данных и воспроизведения, видео должно просто поспевать за звуком путём вставки/удаления кадров.
«Вы путаете Embedded OS и RTOS, между ними нет строгого знака равенства. Отсюда и весь посыл статьи заведомо ошибочен.»
Поскольку вас и EmBox-овцев (а иного объяснения, кроме как отождествления вас с ними я не вижу) уже почти 4 года не покидает обида от моего замечания, вылившегося в разъяснения еще и от других компетентных участников - придется принять вызов. Также не буду на первый раз останавливаться на неумелой попытке сходу оскорбить оппонента и незнакомого специалиста.
Хочется спросить, а вы на какие определения того и другого опираетесь, а вы уверены, что они придуманы не для того, чтобы их путать? Ведь если между ними нет строгого знака равенства, это значит между ними есть НЕ строгий знак равенства. А раз есть хоть какой-то знак равенства то почему же их не спутать? Получается заявление противоречит само себе: утверждает, что они очень похожи, но запрещает их путать. Заявление достойно какой то блондинки, а блондинки всегда у меня вызывают восхищение :) .
Классическое определение института Berkeley устроит?
A real-time system responds in a (timely) predictable way to (un)predictable external stimuli arrival. [Marco Di Natale. An Introduction to Real-Time Operating Systems and Schedulability Analysis - 2012]. Там есть дополнительные уточнения. В условиях исключения из мотивов воинствующей невежественности, сие должно быть как минимум интересно.
Вот другой вариант - дилетантское мнение какого-то там члена Institute of Electrical and Electronics Engineers (IEEE):
Real-time systems are computing systems that must react within precise time constraints to events in the environment. [Giorgio C. Buttazzo: Hard Real-Time Computing Systems: Predictable Scheduling Algorithms and Applications - 2005]
А теперь сравним с рафинированным определением Embedded систем (от каких-то там никому не известных Berkeley):
Although embedded systems have been in use since the 1970s, for most of their history they were seen simply as small computers ... Recently, the community has come to understand that the principal challenges in embedded systems stem from their interaction with physical processes, and not from their limited resources. The term cyber-physical systems (CPS) was coined by Helen Gill at the National Science Foundation in the U.S. to refer to the integration of computation with physical processes. In CPS, embedded computers and networks monitor and control the physical processes, usually with feedback loops where physical processes affect computations and vice versa. The design of such systems, therefore, requires understanding the joint dynamics of computers, software, networks, and physical processes. It is this study of joint dynamics that sets this discipline apart. [E.A. Lee, S. A. Seshia. Introduction to Embedded Systems - A Cyber-Physical Systems Approach - 2017]
Лелею искреннюю, но боюсь, что безосновательную, надежду на то, что перевести и проанализировать вы все-таки сможете без моей помощи. А вот на полное ознакомление хотя бы с этими материалами, увы, не надеюсь.
P.S. Я конечно же понимаю что каждый студент считает делом чести опровергать общеизвестные знания, но их безосновательное отторжение противоречит принципам компетентной дискуссии. Честно говоря, за давностью лет уже плохо помню курс аспирантской философии науки. Но ряд древних философов запрещал своим ученикам задавать вопросы, дабы не оскорбляли своим невежеством. Вполне гуманно в определенных случаях, не находите? Не напомните мне, кто это был - Платон, Аристотель, ...?
Предсказуемость не является характеристикой подлежащей численной оценке
Черт дернул читать дальше. Последние пол века (знаю работы 1973-го), может и более, человечество успешно искало и даже регулярно находило способы численной оценки именно этого параметра в различных сценариях. А, посоны-то и не знали, что это невозможно. Чё делать-то?
Последние пол века (знаю работы 1973-го), может и более, человечество
успешно искало и даже регулярно находило способы численной оценки именно
этого параметра в различных сценариях. А, посоны-то и не знали, что это
невозможно. Чё делать-то?
Не очень пониваю, что Вас смущает? То есть, более 50 лет человечество искало, (предлагало) различные способы оценки, в статье приводятся предлагается что то свое, может даже и ошибочное, а Вы вместо того чтобы аргументированно что то предложить, переводите все на личности? Не допускаете, что именно Вы неправильно интерпретировали доводы?
Недавно один паренек у нас на фирме попросил посмотреть его наработки по диссертации. Они с научником около года курили класс задач, где делаются снимки некоего дефекта металла на срезе с высоким разрешением и анализируют что было и что стало с его (металла) структурой. Не знаю что они там исследуют на практике, речь шла о методе выявления структурных изменений материи - построение сеток по сырой фотке. Хлопцы сочинили какой-то новый метод, но сравнивали его со своим же более ранним методом и получали 5-ти кратное улучшение. В итоге, исходный метод оказался кхе-кхе-вном => результирующий метод оказался лишь в 5ть раз более кхе-кхе-внистый, а не в 5ть раз лучше чего-то.
К чему это всй сказано:
> вместо того чтобы аргументированно что то предложить
Чтобы что-то предложить, авторский подход должен сравниваться не со своими фантазиями, а с реальными достижениями коллег, о которых есть хоть какие-то независимые сведения. И выполнить это должен автор, чтобы доказать, что на предложения по улучшению его подходов вообще стоит тратить время.
А так мы имеем - автор ничего не читал, но утверждает, что все инженеры, которые ранее эту задачу решали - дебилы. Ну ок, че! Но и общаться под таким соусом не о чем.
А так мы имеем - автор ничего не читал, но утверждает, что все инженеры, которые ранее эту задачу решали - дебилы.
один всем известный политик недавно выдал:
"Кто как обзывается, тот сам так называется"
И он даже обосновал как это связано с психологическим портретом того кто обзывается.
Мне кажется, Это Вы @Anger, Вы автор предыдущего поста, утверждаете что все кто с вами не согласен и кто посмел критиковать Ваши заявления - не вполне полноценные люди и поэтому их надо гнобить и, почему то мне кажется, что не мне одному так кажется.
Я допускаю, к сожалению, что такая Ваша тактика может приносить результат, люди могут боятся с вами связываться. В этом смысле она может быть эффективной, к сожалению.
А так мы имеем - автор ничего не читал, но утверждает, что все инженеры,
которые ранее эту задачу решали - дебилы. Ну ок, че! Но и общаться под
таким соусом не о чем.
Пока я вижу, что все остальные дебилы утверждаете только Вы!
Раз вы признаете авторство на заявление, вы бы просто на вопрос ответили: раз есть хоть какой-то знак равенства то почему же их не спутать?
По поводу, кто там у вас был Платон или Аристотель не могу вам напомнить, я предпочитаю работы Энштейна.
По поводу того что "каждый студент считает делом чести опровергать общеизвестные знания" то я, например, предпочитаю этим пользоваться, а не жаловаться на это.
Раз вы признаете авторство на заявление, вы бы просто на вопрос ответили: раз есть хоть какой-то знак равенства то почему же их не спутать?
Вы не мой студент, не мой подчиненный, чтобы иметь интерес заниматься вашим образованием. Не удосужились осмыслить приведенные определения, не удосужились корректно и вежливо дискутировать. И ответ на свой вопрос вы бы уже могли найти из предыдущего сообщения, если бы хотели. Зачем мне заниматься разжевыванием и изложением другими словами?
Вы не мой студент, не мой подчиненный, чтобы иметь интерес заниматься вашим образованием.
Так Вас то как раз никто и не просит заниматься образованием:)
И уж точно не давать какие то оценки, это не экзамен, хотите что то конструктивное сказать, скажите, а пытаться разговаривать как со студентами на экзамене не стоит!
Бог с вами, за вас тут сильно просят аж в нескольких ветках обсуждения.
Раз вы признаете авторство на заявление, вы бы просто на вопрос ответили: раз есть хоть какой-то знак равенства то почему же их не спутать?
Процитированный фрагмент я нигде не утверждал, это ваши домыслы. В точных науках есть только строгое терминологическое равенство, а "нет строгого равенства" есть лишь лингвистический оборот. Между этими видами систем не может быть никакого равенства вообще, так как существуют и не взаимоисключают друг друга:
- Real-Time Systems, которые не являются Embedded,
- Embedded Systems, которые не являются Real-Time,
- Real-Time Embedded Systems - которые являются и тем и другим.
Какими признаками обладают и те и другие можно понять, все-таки познакомившись с процитированными материалами. Последние встречаются достаточно часто и многие заблуждаются, считая, что это единственная данность. Если и так не понятно, то я прям совсем не знаю.
P.S. У системных программистов есть и другие типичные заблуждения: не все понимают что такое виртуальная память и что такое аппаратные исключения.
:)))))
> Поскольку .. EmBox-овцев .. уже почти 4 года не покидает обида от моего замечания, ...
Да, Вы правы, все четыре года спать не можем:)))) Пришел на экзамен и прямо так опозорился, даже определка не знаю:)
И поясните пожалуйста, на основании чего Вы сделали вывод об отождествлении?
P.S. Я конечно же понимаю, что каждый считает себя в праве оценивать других, но лучше привести аргументы, а то аргумент, ты дурак, потому что у меня мнение другое, а я то умнее, не очень подходит человеку знакомому с аспиранским курсом философии науки.
А по-другому статья, в которой через слово упоминается "благодарность Антону", восприниматься не может. В приличном обществе одним именем именуют либо близких знакомых, либо к родственников.
Опять субъективное суждение о том что нужно или не нужно делать в приличном обществе, точнее что называется этим термином.
Живите с этим знанием =). Культура определяется окружением и степенью развития. Для одних прилично одно, у других планка ниже и допустимо в первой же статье на ресурсе пытаться оскорбить оппонента и увековечивать корешей. Опять-таки, ну ок, в интернетах каких только не встретишь!
в первой же статье на ресурсе пытаться оскорбить оппонента и увековечивать корешей
Может не внимательно читал статью, но подскажите пожалуйста где конкретно Вас оскорбили? Под оппонентом Вы же себя имеете в виду?
Ну и еще раз, с автором мы не только не кореша мы даже не знакомы, Он мне в личку написали об этой статье, но на этом все. Если кто то увидел разумное зерно в моей статье и решил его развить. Не понимаю что тут плохого, кого это оскорбляет и кого увековечивает?
Классическое определение института Berkeley устроит?
Я же, вроде, ясно написал в статье что определения даются и используются с определенной целью. Поэтому это определение меня не устроит, потому что вы не предложили курса из научной школы этого института, который подводит к пониманию этого определения. А я занимаюсь разработкой такого курса на базе своего 25 летнего+ практического опыта.
Вы считаете что сотрудники некоторого подразделения Газпрома, например, не должны иметь собственного определения такого термина? Они должны строго ориентироваться на "Классическое определение института Berkeley" предложенное @anger32 , именно как класическое?
Я же, вроде
Я - это последняя буква в алфавите. И для выражения собственного мнения нужно обладать правом его продвигать. Первая ссылка ведет конкретно на курс Berkeley, прекращайте имитировать осведомленность.
Вы считаете что сотрудники некоторого подразделения Газпрома, например, не должны иметь собственного определения такого термина?
Вот с этого и нужно было начать. Так бы сразу и сказали, что попилом бабла занимаетесь =). С шарлатанами мне обсуждать нечего, сочувствую Газпрому.
А если это вдруг прочитают вменяемые участники Хабра, то наука, определения, алфавит наконец не может быть свой собственный у каждой компании и тем более у каждого подразделения. Только единое предстваление, стремящийся к объективному истинному соответствию реальности. Истин не может быть несколько, но ее понимание может эволюционировать - см. фальсифицируемость научного знания (по Попперу).
Все, что тут расписано прямо каноничное определение лженауки:
Отрицание классических трудов, да и любых трудов в принципе;
Отрицание существования предшествующего научного знания;
Выдумывание собственной терминологии - это прямо по учебнику. Когда в Союзе хотели липовых степеней известным явлениям давали новые имена, чтобы имитировать новизну;
Ну и конечно же, за плату наука у любой шараги должны быть своя! "Преемственность" научного знания в действии =).
прекращайте имитировать осведомленность
Спасибо за комплимент, хоть и выраженный в достаточно экстравагантной форме!
Но от человека который одновременно увлекается и Платоном, Аристотелем и... Попером и при этом видимо считает себя техническим специалистом, вряд ли можно ожидать чего то адекватного.
А про Газпром вы, наверно, зря так! Как бы к вам не пришли проверить, с какой целью вы распространяете информацию, которую не можете подтвердить, а если можете то где вы этого набрались
алфавит наконец не может быть свой собственный у каждой компании
Но каждая компания должна пользоваться алфавитом своей страны, а не чужой. Надеюсь это вы в состоянии понять.
"Так вот, можно в общем определенно сказать, что Операционная Система Реального Времени — это ОС, в которой существуют все необходимые операции по контролю и управлению временем."
-- не соглашусь. Речь скорей именно о предсказуемости. Выполнение любой операции в ядре ОС, или даже где-то на уровне библиотек, в операционной системе общего назначение может не закончится за какое-угодно большое время. Это наверное основная проблема. Речь не о том, что выполнение операций гарантируется за какое-либо конечное время, а о том, что в ОС общего назначения часто используются такие алгоритмы, которые сами по себе не могут гарантировать выполнение операций в определённой очерёдности, с учётом приоритетов, или в пределе выполнение операций за конечное время вообще.
Элементарные, базовые примеры:
спинлок в ядре ОС, в библиотеке, мьютекс в библиотеках или в програме прикладного уровня может не быть захвачен сколь-угодно долгое время только одним потоком потому, что реализуемый алгоритм мьютекса не предусматривает упорядоченности обработки запросов, а обрабатывается всегда первый попавшийся (см. статью Ticked lock), при этом число запросов велико (то же может касаться условных переменных и производных механизмов синхронизации);
в большинстве ОС общего назначения существует проблема инверсии приоритетов, существующие механизмы синхронизации не предусматривают приоритизацию -- следовательно, более низкоприоритетные задачи могут блокировать работу более высокоприоритетных неопределённо долгое время.
Это примеры могут распространяться на широкие слои API, т.к. ОС внутренне использует те же примитивы синхронизации. И в большинстве случаев, в среднем, это всё вовсе не является сколько-нибудь заметной проблемой, но неизбежно находятся критические случаи, когда оно становится заметно. И именно отсутствием таких случаев характеризуется ОСРВ.
PS: обычный мьютекс в линуксе не обеспечивает относительно честной вероятности его захвата для всех потоков. Т.е. в некоторых нетривиальных случаях возможна ситуация, когда критичный поток попросту "зависнет" на мьютексе на неопределённое долгое время. Когда мьютекс постоянно будет доставаться другим потокам. И это -- действительно проблема для систем "реального времени".
> Выполнение любой операции в ядре ОС, или даже где-то на уровне библиотек, в операционной системе общего назначение может не закончится за какое-угодно большое время. Это наверное основная проблема.
если посмотреть немного шире, основная проблема - код real time os трудно сделать полностью reentrant, можно но трудно, нужна аппаратная поддержка, поэтому приходится прерывания закрывать со всеми вытекающими последствиями
ps
то что в этой ветке называется институт Berkeley точнее назвать iCyPhy Center UC Berkeley, насколько понимаю организация созданная при университете калифорнии, они работают пока только с Denso, Siemens, Toyota, указанные presentations вероятно отражают именно их требования
Модель 1
int main() {
// code
}
Обычный код main вызывается при старте программы. ОС нужна для обслуживания типовых задач и возможности пускать более чем одну задачу.
Модель 2
void setup() {
// code
}
void loop() {
// code
}
При старте вызывается инициализация setup, а затем loop вызывается через равные промежутки времени (например 1000 раз в сек) постоянно. Вот тут требуется что бы код успевал выполняться за выделенное время и для обслуживания нужна уже ОС реального времени. Такого вида модель используется в PLC. (Вариация модели когда таких обработчиков много и некоторые из них вызываются по внешним событиям и имеют разные приоритеты)
Это называется time triggered architecture, и она очень любима в российской военной технике. За простоту видимо.
У такого подхода по сравнению с полноценной вытесняющей ОС есть очевидный недостаток: высокая латентность. Какое-либо входное событие не будет обработано до тех пор, пока цикл (loop) не прокрутится. Более того, часто одно событие порождает другие (которые обработаются только в следующем цикле), и так рекурсивно. Одно входное событие в реальной системе может вызвать лавину внутренних событий. И конкретная реакция на входное событие может последовать после обработки всей этой лавины событий.
Очевидная проблема, что каждое N+1 событие обрабатывается за время оборота цикла. А это время ещё не просто определяется необходимостью проверки всех событий, оно жёстко задано и это достаточно большая величина, чтоб точно все успели. В итоге система в целом весьма неповоротливая.
Можно цикл крутить не по таймеру, а безусловно. Тогда система будет ворочаться несколько живей, но потеряется детерминированность. Циклы будут исполняться с разной скоростью, в зависимости от логики программы. Такой подход не знаю как называется официально, но в embedded программировании часто носит название big loop. Ещё часто подобным образом строятся системы управляемые конечными автоматами, например, swtich-технология А. А. Шалыто (softcraft.ru).
Проблема такой системы в нарастании неповоротливости по мере разрастания самой системы. Если система оперирует двумя десятками событий и нет сложных внутренних связей то всё быстро. Но когда начинают обрабатываться сотни событий, когда обработка внешнего события порождает волну внутренних событий, система быстро становится крайне неповоротливой.
Очевидным улучшением такой системы будет являться исключение необходимости проверки факта наступления событий в цикле. Например, события могут помещаться в очередь, а в цикле мы можем считывать события из головы очереди и обрабатывать. Если событий, или проверяемых условий достаточно много -- такой подход даст заметное ускорение. Это типичный цикл обработки событий с очередью, что используется во многих GUI системах (Windows, X11), в играх.
Но у подхода с очередью есть фатальный недостаток: если одно обрабатываемое событие может порождать, условно, лавину вторичных событий, и так рекурсивно, очередь рискует попросту регулярно переполняться.
Другой существенной проблемой очереди является собственно обработка событий в порядке очереди, а не в порядке их важности или приоритета.
Очевидным решением может быть замена очереди на какую-либо другую структуру данных, хранящую только факт возникновения событий такого-то типа, но не хранящую каждое событие в отдельности. Сами события в отдельности, если они нужны, пусть хранятся в специфичных для данного события очередях или других структурах, если это вообще важно (часто не важно и достаточно факта, что хоть одно событие такого типа произошло). И эта новая структура может быть уже не просто очередью, а очередью с приоритетами, bucket queue или чем-то вроде того.
Такая система может уже обрабатывать события гораздо резвей чем построенная на time triggered принципе. Фактически, новое наиболее приоритетное событие обрабатывается не дольше, чем за максимальное время обработки одного события (а не множества всех возможных событий, как в time triggered варианте, или big loop, или не неопределённого числа событий находящихся в очереди, как в случае с очередью). И эта система всё ещё оперирует одним потоком исполнения.
А теперь мы можем всё вывернуть наизнанку, и сказать, что у нас нет одного большого цикла, в котором мы из некой структуры данных (очередь с приоритетами) извлекаем следующее событие для обработки, а есть множество потоков исполнения и в каждом свой цикл, в котором операция ожидания всегда ожидает только одно события какого-то одного типа. И эта операция -- это какой-либо примитив синхронизации, например, мьютекс или семафор. Получилаь типичная многозадачная операционная система. Такая система имеет ещё меньшее время реакции на входные воздействия: так как система умеет вытеснять и переключать потоки, то время реакции на событие определяется преимущественно только скоростью переключения контекстов!
Например, если в микропроцессро поступил входной сигнал, то он в прерывании генерирует внутреннее событие, на выходе из обработчика прерывания тут же срабатывает планировщик и с ожидания снимается поток обрабатывающий это событие и происходит переключение на него. По сравнению с остальными вариантами -- моментально! Вот поэтому-то RTOS, многозадачные, вытесняющие, важны и нужны. Они -- быстрей. Существенно. На многие порядки.
На практике конечно, нет огромного количества независимых задач, а зависимые требуют синхронизации между собой, которая быстро становится достаточно трудной задачей (это причина, почему из-за высокой связности практически все GUI-системы -- однопоточные). Поэтому практическая система скорей строится как комбинация двух механизмов. Многозадачной вытесняющей системы, где существует множество потоков обслуживающих относительно независимые задачи. И достаточно большое количество событий обслуживается в неком "цикле обработки событий" связанном с очередью или иной структурой (что-то вроде libevent или Boost.Asio). Этот цикл работает в одном из потоков. Так происходит в типовой ОС.
Но возможно существование и обратного варианта. Не когда цикл обработки событий исполняется внутри потока вытесняющей ОС, а когда планировщик вытесняющей ОС исполнятся в цикле обработки событий. Такой подход на мой взляд возможен, но пока исключительно умозрительный. Практической его реализации мне не известно.
Резюмируя: мы осмотрели основные принципы построения управляющих компьютерных систем. И пришли к заключению, что система с вытесняющей многозадачностью может обеспечивать лучшее время реакции.
У такого подхода по сравнению с полноценной вытесняющей ОС есть очевидный недостаток: высокая латентность.Это не у подхода, а у конкретной реализации.
Какое-либо входное событие не будет обработано до тех пор, пока цикл (loop) не прокрутится.Нет циклы могут выполнятся по прерыванию или отдельными исполнителями. При этом как раз такой цикл должен успевать сделать всю работу до следующего события. Такая архитектура используется в плис (например в vhdl есть блок process). MATLAB генерирует подобный код для моделей. PLC широко используют подобное.
Проблема такой системы в нарастании неповоротливости по мере разрастания самой системы.Это проблемы любой системы и они имеют совершенно другую природу.
события могут помещаться в очередь, а в цикле мы можем считывать события из головы очереди и обрабатывать.Это немного другая модель с акторами и очередями. И да вы должны контролировать потоки данных. Если у вас линия 100Мб, то что бы передать 10Гбит надо как минимум 100 таких линий, если провод на 1А, а вы подали 100А то результат предсказуем. Это значит что система должна быть спроектирована так что бы выдерживать типовые нагрузки.
пришли к заключению, что система с вытесняющей многозадачностью может обеспечивать лучшее время реакцииТакие заключение оснований делать нет.
Это не у подхода, а у конкретной реализации.
У любой реализации. Проблема вызывается алгоритмической сложностью алгоритма выбора следующего обрабатываемого события (полный перебор), и при росте числа событий в эту самую сложность и упирается. Для того, чтобы эту сложность побороть нужна какая-то форма планировщика, который будет принимать решение о запуске обработки того или иного события не за O(n), а за O(1) время, в идеале. Речь не обязательно о планировщике многозадачной ОС, в цикле обработки событий с очередью выбор тоже осуществляется за O(1).
Кроме того, проигнорирована вторая проблема, что обработка синтетических событий (порождённых обработкой других событий) неизбежно происходит в N+1 цикле. А если скорость выполнения циклов ограничена сверху таймером, то сколько-нибудь длинные цепочки событий неизбежно выполняются долго, дольше чем в других архитектурных решениях рассмотренных выше.
Нет циклы могут выполнятся по прерыванию или отдельными исполнителями
Речь была о time triggered архитектуре, с одним глобальным циклом, работа которого запускается по таймеру. А не о каких-то других архитектурах, где неожиданно появляются прерывания и другие потоки. В программной реализации появление потоков означает многозадачную ОС и планировщик -- см. выше.
Это проблемы любой системы и они имеют совершенно другую природу
Не любой системы. Обычый цикл обработки событий с очередью, из типовой GUI-системы способен при пустой очереди новое событие обработать сразу. А все варианты наподобии big loop -- пока цикл полностью не провернётся, т.к. он вынужден проворачиваться даже если событий нет -- просто чтоб проверить, что их нет, каждое событие проверить по-отдельности. В таких системах событием обычно можно назвать выполнение некоторых логических условий, которые просто проверяются и перепроверяются многократно, в каждом цикле.
Такие заключение оснований делать нет.
Повторяю ещё раз.
В многозадачной системе с приоритетами время реакции на событие ограничено временем переключения контекста.
Во всех системах с циклом -- временем оборачивания цикла. Время оборачивания цикла может зависеть от двух факторов:
2.1. для системы с очередью: временем обработки предыдущего события в очереди;2.2 для системы с ручной проверкой факта возникновения событий (big loop, time triggered loop): временем обработки всех событий обрабатываемых в предыдущем цикле, плюс временем проверки всех условий для каждого типа событий;
2.3. для time triggered цикла -- дополнительно, периодом запуска цикла.
Вариант 1 обычно значительно быстрей варианта 2.1, вариант 2.1 быстрей варианта 2.2, вариант 2.2 строго быстрей варианта 2.3.
Из преимуществ варианта 2.3 -- только детерминизм.
Повторяю ещё раз.Вы исходите из неверного посыла. Ограничение в системах реального времени приходит из вне, а не от реализации времени обработки события. И железо подбирается под задачу, а не наоборот. Задача инженера обеспечить эти интервалы и пропускные способности.
В многозадачной системе с приоритетами время реакции на событие ограничено временем переключения контекста.В современных процессорах это время может достигать миллиона тактов. За это время можно выполнить много полезных действий. Поэтому ваши утверждения про скорость разных моделей сомнительны. Более того в PLC количество сигналов ограничено и циклы имеют вполне предсказуемые времена выполнения.
… о запуске обработки того или иного события не за O(n)Можно и за n^2 сделать, если n не большое. Откуда такие оценки. Например таблица прерывание вполне себе за O(1) работает. Или даже банальный switch.
Вариант 1 обычно значительно быстрей варианта 2.1, вариант 2.1 быстрей варианта 2.2, вариант 2.2 строго быстрей варианта 2.3.Посмотрите OpenCL там как раз 2 модель, только не по времени, а по исполнителям (например для каждого пикселеа в полигоне, вызывается loop).
Обычый цикл обработки событий с очередью, из типовой GUI-системы...Ваша боль понятна. Все современные GUI системы до сих пор очень представляют жалкое зрелище.
> Ограничение в системах реального времени приходит из вне, а не от реализации времени обработки события. И железо подбирается под задачу, а не наоборот. Задача инженера обеспечить эти интервалы и пропускные способности.
совершенно верно, заметим что часто делается несколько рабочих циклов, для реакции на внешние события разного типа (опрос состояния+выработка управляющих сигналов), на всю эту механику также влияют требования redundancy и организации контрольных точек, все это должно учитываться при оценке времени реакции системы по худшему сценарию
Все современные GUI системы до сих пор очень представляют жалкое зрелище.
интересные вы заявления делаете. А вы знаете что такое WPF и как эта:
"платформа пользовательского интерфейса, которая не зависит от разрешения и использует векторный механизм визуализации, способна использовать все преимущества современного графического оборудования"?
Или вы из тех кто: "не читал, вникать не пытался, но осуждаю"?
все бы было хорошо с вашими рассуждениями, если бы вы привели в пример хоть одну более менее реальную задачу решениЯ которой рассмотренными вами методами подтверждают ваши выводы.
Например, если в микропроцессро поступил входной сигнал, то он в прерывании генерирует внутреннее событие, на выходе из обработчика прерывания тут же срабатывает планировщик и с ожидания снимается поток обрабатывающий это событие и происходит переключение на него. По сравнению с остальными вариантами -- моментально!
тут вы одну маленькую деталь пропустили (или не одну):
как планировщик находит поток который обрабатывает это событие?
А если есть несколько потоков которые должны реагировать на это событие то что?
А если во время обработки этого события придет другое событие которое также надо обработать, что делать с обработкой первого события, какое событие обрабатывать быстрее первое или второе? Может надо как то этим порядком управлять? Если просто применять приоритеты, например, то мы, назначив более высокий приоритет второму событию, просто задержим обработку первого события, насколько это допустимо?
Потом прерывание это и есть событие. Процедура обработки прерывания отправляет в планировщик это событие возможно с некоторыми параметрами прочитанными из регистров, а может и напрямую вызвать планировщик если он достаточно легковесный, это как раз определяется ответом на вопрос №1. .
Кажется этот текст только запутывает. Если мы добавляем функциональность в модуль ядра ОС, то наверно почти любая ОС становится реального времени. Так же нужно разделить задачи на:
Гарантированное предоставление процессорного времени программе, что в сущности решается установкой приоритетов процессов.
Гарантированное время реакции не больше заданного максимального.
Фиксированное гарантированное время реакции.
Грубо говоря задачи делятся на:
Когда нужно вовремя пополнять буфер устройств вывода, а так же успевать забирать данные из устройств ввода. Пример, декодирование видео для просмотра.
И те когда нет никакого буфера и есть фиксированный промежуток времени в течении которого надо обработать информацию и вывести. Например отслеживание сигнала радара и построение картинки на его основе.
Задачи первого рода решаются тем, что программа получит определённое количество процессорного времени в течении промежутка времени. То еть условно каждые 40 мс получит не менее определённого количества тактов процессора. Задачи второго рода, решаются тем, что при получении прерывания, от входного устройства или от встроенного хронометра (счётчика тактов), отключает все остальные прерывания и передаёт управление программе требующей "реального времени", на не менее чем определённое время, ну или пока программа сама не освободит занятое процессорное ядро.
Если уж говорить про реальное время, настоящее, реальное. Не удержался от тавтологии. То это процессор и работающая на нём программа, которая постоянно периодически опрашивает устройство ввода или в таком же режиме изменяет значение на устройстве вывода. Например каждые 250 тактов замеряет напряжение на входах и выдаёт их произведение на коэффициент в виде напряжения на выходе. Или же реализует при помощи оперативной памяти имитацию линии задержки, с которой сравнивает принимаемый сигнал, выдавая их разницу, ну и возможно заодно проводя типа подавление помех.
Это да! И на уровне ядра и на уровне драйверов приходится работать в реальном времени. Я бы даже обобщил что при работе с любыми аппаратными функциями приходится работать в реальном времени.
А по поводу деления задач, у меня есть интересный (надеюсь) пример :
вот мы каждые 250 тактов замеряем напряжение на входах и ВЫЧИСЛЯЕМ (выдаёт их произведение на коэффициент) в виде напряжения на выходе
При этом мы должны принимать запросы о состоянии в случайный момент времени и на них ОТВЕЧАТЬ в определенный таймаут иначе там решат что мы сломались и нас выключат.
То есть мы должны и ВЫЧИСЛЯТЬ и ОТВЕЧАТЬ с некоторой вероятностью одновременно,
Вы куда такую задачу отнесете?
Не знаю. Но это подмножество задач жёсткого реального времени.
Практическая же задача подобного зависит от реализации механизма прерываний на конкретном процессоре. Хорошо, если можно настроить прерывание на 250 тактов. Вопрос в величине таймаута. А так же в том какая вычислительная сложность у ответа. Если просто отсылать назад ответ "я не завис" с переданным ID запроса, одно дело. А если ещё вычислять какие то криптографические штуки, другое дело. Кроме того, важным является вопрос ввода и вывода этих запросов. Если это например программная реализация RS232, то при однопоточной работе жопа получается, при написании программы придётся считать такты. Уместив в один бесконечный цикл опрос и порционную обработку. Как думаю о таком, испытываю предчувствие боли и безысходности. Если же есть аппаратный контролер, да ещё и с буфером, а у процессора есть управление прерываниями (возможность временного отключения хотя бы), то задача уже менее сложная.
Если это например программная реализация RS232, то при однопоточной работе жопа получается, при написании программы придётся считать такты.
Да нет какая уж там програмная реализациа UART-а , аппаратная конечно, и с 250 тактов вы конечно загнули, а я просто скопировал. Вот 2500 тактов уже нормально, там у меня правда процессор 8-битный PIC был последний раз, c меньше чем пол-кило-байта ОЗУ (<512 байт), так что деление с умножением это уже приключение :) .
такты посчитать не когда не помешает - хотя бы приблизительно, но все равно надо померить в тиках в реальном тестовом прогоне, а то не в чем нельзя быть уверенным!
с 250 тактов вы конечно загнули
Как то читал, что нагрузкой на оперативную память, возможно модулировать радиосигнал который возможно принять и усилить не некотором достаточном для скрытности расстоянии. Следовательно можно и какой нибудь дешёвый микроконтроллер использовать для модуляции радиосигнала (переключением направления электрического тока в транзисторах подключенных к антенне), или же для модуляции сигнала на лидаре. Там могут потребоваться и меньшие периоды по отношению к тактовой частоте.
мы когда то сделали измерительный девайс который формировал управляющие фронты на ногах процессора (кажется на 6 из восьми) с точностью до периода тактовой частоты процессора то есть на 10 МГц -ах с точностью до 0.1 мкс от нуля до скольки то минут (оборудование надо было с такой точностью запускать, ноль означает старт системы и можно в этот момент задать фронт, на другой ноге можно задать фронт через 0.1мкс, на следующей через секунду, ...) пришлось программу написать которая генерирует соответствующий ассемблерный код.
На AtMega -х (тогда была просто АТ90-серия) все такты по инструкциям четко прописаны - все точно считается. Мне через полтора года мой схемотехник сказал что он догадался повесить мелкие конденсаторы прям на выводы микросхем и пропали последние редкие глюки с работой задатчика.
Так что можно и с точностью вообще до тика кое что делать.
А! Кстати я реализацию USB 1.0 разбирал на Атмеге там тоже с точностью, до двух-трех тактов ассемблер контролировал сигналы.
Если мы добавляем функциональность в модуль ядра ОС, то наверно почти любая ОС становится реального времени
Почему это? Вот есть ядро LInux, которое имеет все, о чем Вы пишете. А вот real-time patch для этого ядра. Что-то тут не сходится, не находите? Видимо, все-таки не любая ОС, а лишь те, которые проектируются под real-time.
Я конечно вопрос не изучал. Но предполагаю что этот патч является прежде всего фреймворком, упрощающим всякий перехват прерываний и управление планировщиком.
The RT-Preempt patch converts Linux into a fully preemptible kernel. The magic is done with:
Making in-kernel locking-primitives (using spinlocks) preemptible though reimplementation with rtmutexes.
Critical sections protected by i.e. spinlock_t and rwlock_t are now preemptible. The creation of non-preemptible sections (in kernel) is still possible with raw_spinlock_t (same APIs like spinlock_t).
Implementing priority inheritance for in-kernel spinlocks and semaphores. For more information on priority inversion and priority inheritance please consult Introduction to Priority Inversion.
Converting interrupt handlers into preemptible kernel threads: The RT-Preempt patch treats soft interrupt handlers in kernel thread context, which is represented by a task_struct like a common user space process. However it is also possible to register an IRQ in kernel context.
Converting the old Linux timer API into separate infrastructures for high resolution kernel timers plus one for timeouts, leading to user space POSIX timers with high resolution.
ps
imho, work in progress, penalty = throughput + недостаточно опыта использования
см
https://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions
введение, Sebastian Siewior, Linutronix (Oct, 2017):
А я такую сеть придумал, но уровень интеллекта местного населения не хватает что бы понять как она работает ))))))
RTOS или не RTOS вот в чем вопрос 2, или Windows тоже RTOS?