Ну и ладно, будем цитировать из другого топика
diamond wrote:Мнэээ? Кто-то совсем недавно что-то говорил про гарантии, и мне казалось, что этот кто-то тоже подписывался ником Galkov. Ну а реальная система, которая вовсе не гарантирует всё и по любому поводу, - это и есть текущее состояние планировщика...
Неправда Ваша, дяденька
Никогда я не говорил, что надо гаранитровать ВСЕ, иначе типа полный кердык...
С самого начала (этого топика) я говорил, что нужно сделать ВСЕГО ЛИШЬ две небольшие вещи, чтобы совершить качественный скачок: "
применимость KoOS для встроенных систем"
Это:
- а) планировщик, который гарантированно предоставляет "сигнал" приложению не медленнее, чем за заранее заказанное время
б) не "вешать" исполнение приложения прерываниями, или иными мероприятиями, на время сравнимое с квантом переключения задач. Как минимум, чтобы была возможность подобрать железо (ну там частота проца, шины, и т.п.) для выполнения этого.
И все.
После этого, я смогу решать, как минимум, некоторые задачи.
И это
качественный скачок - сегодня не могу.
Естественно, в своем понимание того, что такое реальная система.
А в чьем еще, если за конечный результат отвечать именно мне........
Первое - мне представляется вполне преодолимым. Несколько увеличившиеся за последнее время, мои познания в архитектуре KoOS - не отменяют пока этого.
Второе - преодолеваем по мере поступления. В первую очередь те вопросы, без которых не обойтись.
Например, сбой карусели "кем ни попадя" - это ТАКОЙ вопрос.
А вот ожидание мьютекса "потенциально неограниченное время" даже при конечном времени захвата - это уже НЕ такой вопрос.
Ответственность оси - только время доставки сигнала (каковым также является и факт принудительнго по int0 прерывания исполнения), и предоставление временного ресурса для его обработки. Хочешь RT-характеристики - работай с монопольным захватом ресурсов, вот и вся проблема.
Причем не проблема оси, а разработчика
Монопольное - в широком смысле: в моем проекте могут быть несколько RT-потоков, которые общаются с моим же "драйвером" железа. Но это - мои проблемы а не оси. Всякий захват мьютекса "драйвера" я сделаю конечным во времени. Планировку предоставления ресурса моим (и ни чьим более) ожидающим потокам - так я этим как раз сейчас и занимаюсь.
И если сигналы от мьютекса будут доходить клиентам за предсказуемое время - у меня все сварится.
В том смысле, что именно я смогу отвечать за работоспособность именно моей системы.
Да, общие системные ресурсы упоминались. Винт, Аллокатор памяти...
И что
Это вовсе не отменяет возможности создания RT-приложения.
Да, с винта загружу все в память. Подкачки страниц уже и так нет (как во всех уважающих себя RT-осях). Если возникнет необходимость подкачки данных, то сделаю это через не-RT-поток, с такими временными характеристиками, что по исчерпании половины которого, можно будет включить сирену в рабочем зале, чтобы оператор пришел и исправил положение. Без остановки технологического процесса. В конце концов, даже исполнение договора, в рамках которого и выполняется данный технологический процесс - это тоже процесс в реальном времени.
Если системным аллокатором пользуются "все", то отстегну себе один раз сотню метров, и буду пользоваться своим, в 3-м кольце (каковой имеется практически во всех ЯВУ).
То же мне проблемы...
Проблема, это когда винда начинает менять размер файла подкачки, например
Тут уже и "сирена" не поможет.
Более приземленно: железо сигнализирует о готовности, а у меня нет гарантия, что я узнаю об этом раньше чем завтра - вот это проблема.
Блин, народ ведь еще ДОС-ом пользоваться не прекратил, по всем этим причинам
Ну вот, моя простенькая задача и заключается в том, чтобы лишить его поледней аргументации к этому.