[Kabdim 0]

Так насчет вашего первого контраргумента что C код не совпадает с верифицируемым, вы признаете что его придумали?

[AlexandrY 3]

Так насчет вашего первого контраргумента что C код не совпадает с верифицируемым, вы признаете что его придумали?

Нет, конечно.

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

Да и для ARM они не указали платформу на которой прогоняли код. Это все симуляция.

По ходу это кажется я вам объясняю, как там все устроено.

 

[Kabdim 0]

По ходу это кажется я вам объясняю, как там все устроено.

Увольте, ваша фантазия конечно интересная , но я уже прочитал ту статью и многое из ссылок.

[syoma 1]

Народ все это интересно, но может стоит обсуждать в отдельной теме? Так как к моей теме я не вижу отношения.

[AlexandrY 3]

Народ все это интересно, но может стоит обсуждать в отдельной теме? Так как к моей теме я не вижу отношения.

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

Сами виноваты, теперь обсуждение переходит в правильное русло - верификацию операционных систем.

 

Увольте, ваша фантазия конечно интересная , но я уже прочитал ту статью и многое из ссылок.

Ага, теперь сами признайтесь, я прав?

[Студент заборстроительного 0]

А какие проблемы-то? (я к вопросу темы)

Фоновый поток не реалтайм, а приоритетные потоки - реалтайм.

Тут нет никакой проблемы.

А проблема в том, чтобы при наличии вытесняющей многозадачности низкоприоритетным потокам тоже гарантировать пусть и бОльшее, чем высокоприоритетным потокам, но ГАРАНТИРОВАННОЕ время реакции.

 

Это проблема хоть и сложней, но вполне решаема.

Я в разработанной мной RTOS её решил

 

[mantech 35]

А проблема в том, чтобы при наличии вытесняющей многозадачности низкоприоритетным потокам тоже гарантировать пусть и бОльшее, чем высокоприоритетным потокам, но ГАРАНТИРОВАННОЕ время реакции.

 

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

[AlexandrY 3]

А какие проблемы-то? (я к вопросу темы)

Фоновый поток не реалтайм, а приоритетные потоки - реалтайм.

Тут нет никакой проблемы.

А проблема в том, чтобы при наличии вытесняющей многозадачности низкоприоритетным потокам тоже гарантировать пусть и бОльшее, чем высокоприоритетным потокам, но ГАРАНТИРОВАННОЕ время реакции.

 

Это проблема хоть и сложней, но вполне решаема.

Я в разработанной мной RTOS её решил

С ваши подходом можно и Windows 10 считать RTOS.

У меня она еще ни разу не зависала, и гарантированно за час откликается на любое событие.

 

Чем гарантирует время реакции? Своим честным словом?

 

[mantech 35]

У меня она еще ни разу не зависала, и гарантированно за час откликается на любое событие.

 

Да вам везет, у меня винда хоть редко, да зависнет, или ФС слетит при некорректном завершении...

[AlexandrY 3]

Да вам везет, у меня винда хоть редко, да зависнет, или ФС слетит при некорректном завершении...

Это не зависания оси, это переход в сервисный режим.

Десктопная винда может себе это позволить, она ж работает под управлением пользователя.

А встроенная винда спокойно обошла бы этот момент.

 

[syoma 1]

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

Ну хотя бы доступ к ресурсам железа, не?

[Pavia 0]

Для AlexandrY

Это не зависания оси, это переход в сервисный режим.

Десктопная винда может себе это позволить, она ж работает под управлением пользователя.

А встроенная винда спокойно обошла бы этот момент.

И каким же образом она гарантирует реальное время? Неужели честным словом Билла Гейтса? - мне правда интересно.

Никогда с реальным временем не работал. А как другие гарантируют?

 

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

То что они приходят неизвестно когда и в не своё время. Хотя это можно отрегулировать выше стоящей системой. Как следствие состояние системы неизвестно и окромя как выставить собственный флаг в прерывание вы более ничего не можете. Затем вы должны выйти из прерывания. И если это ОС с вытесняющей многозадачностью, то она должна при первом возможном случае вернуться к обработке прерывания, но уже в определённом состоянии:

а) откладываем текущую и начинаем драйверную задачу.

б) дождаться APC и втиснуть прерывание.

с) синхронизироваться с основным циклом секвенсера.

 

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

Изменено 3 ноября, 2017 пользователем Pavia

[Студент заборстроительного 0]

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

Если поток прерываний слишком большой, он "забьёт" более низкоприоритетные, но все равно реал-таймовые задачи.

 

Я пошёл по пути гарантированного тайм-слота для задач с приоритетами класса 2

 

С ваши подходом можно и Windows 10 считать RTOS.

С цитированием по внимательней будьте.

Я так понял, это Вы к вот этому:

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

 

Если ртось УСПЕВАЕТ ВОВРЕМЯ среагировать и обработать евент за ДЕТЕРМИНИРОВАННОЕ время и это время устраивает заказчика, значит это ртось. Даже если время реакции сотни милисекунд

 

К примеру если цикл ПЛК 0.5 секунды то нафига успевать среагировать и обрабатывать евент за микросекунды?

А не к тому, что процитировали

 

Изучив десятки RTOS, теорию их построения и перепробовав различные варианты построения RTOS я в конце концов вообще я отказался от использования прерываний.

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

Точнее у меня работал только одно прерывание. Таймерное.

Все остальные прерывания работали по механизму поллинга их флагов.

Да получился большой оверхед. В том смысле, что процессор почти 70% времени проводил в таймерном прерывании.

 

Ну и что?

Проблему решил просто: взял проц с более высокой (на 500% выше чем нужно для моих задач) тактовой. И что? сейчас процессоры стоят дешевле грязи. А вот софт к ним стоит огого. Поэтому лучше купить проц подороже, но сэкономить на софте

 

Зато реализация RTOS получилась очень простой, красивой и надёжной. И жесткий реалтайм получился ГАРАНТИРОВАННЫМ при вытесняющей многозадачности

 

Более того.

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

Посколько классу низкоприоритетных потоков все равно гарантировался тайм-слот

 

Проблема дедлоков тоже была решена за счет выбора архитектуры построения RTOS

 

Таким образом у моей RTOS был только один "минус": 70% времени процессора занимал микродиспетчер, находившийся в таймерном прерывании. Т.е. на диспетчеризацию уходило 70% процессорного времени, а на выполнение "полезной работы" - всего 30%. Но с этим можно смириться. Выбрав более мощный проц

Изменено 3 ноября, 2017 пользователем Студент заборстроительного

[AlexandrY 3]

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

Посколько классу низкоприоритетных потоков все равно гарантировался тайм-слот

Это невозможно по логике. Подумайте еще раз над этой формулировкой. Время не резиновое.

 

[Студент заборстроительного 0]

Это невозможно по логике. Подумайте еще раз над этой формулировкой. Время не резиновое.

Возможно.

Я даже объяснил как.

Прочитайте несколько раз, что я написал.

Не всегда и не всем с первого раза доходит