Действительно ли вам нужна ОС реального времени?

Первоначально опубликовано Olej Первоначально опубликовано evgen гм...анонимусов вы там запретили.. Не запретили, а запретили им писать в обсуждение - согласитесь, это 2 большие разницы, нет?

небольшие, особенно для чукчи-писателя ;-)

Первоначально опубликовано Olej Но за время с написания статьи: - она вызвала обсуждения и уточнения, которые, как мне кажется - интереснее самой статьи;

и поскольку мне в том обсуждении до сих пор не дают вставить пару слов -

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

Ага, я еще смотрел в код для Win и переделывал его под OS/2 по мере своего непонимания ;-).

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

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

Первоначально опубликовано Olej evgen - с Новым Годом ;) - хоть и с запозданием... но со Старым Новым Годом!

И вам того же.

Первоначально опубликовано Olej Здесь сразу 2 наших приятеля написали свои заметки об RTOS: http://qnxclub.net/files/articles/rtos/rtos.html http://qnxclub.net/files/articles/RemarksOnTheMargins/RemarksOnTheMargins.html Может кого ещё заинтересует?

За второе - спасибо, а первое вообще говоря не новое и вызывает возражение своим началом:

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

скорее идет конкуренция между promPC и generalPC (причем аргументация тут простейшая - цена и время восстановления),    Windows-based осами и всем остальным. Противопоставлять аппаратные решения на базе микроконтроллеров и PC - весьма проблематично, ибо голого PC без микроконтроллеров практически уже нет и разделять PC от платы расширения или внешнего устройства на COM/LPT/USB и т.д. смысла нет

Странно, что возникает вопрос о жестком реальном времени. Здесь все очень просто. Аппаратно-программные средства тут нипричем.

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

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

 

 

Первоначально опубликовано Olej Нет, странное само это замечание, т.к.: - "здесь всё очень просто" - это только для того, кто никогда с этим не сталкивался руками (кстати, здесь, что называется "сон в руку": вот свежее описание того, как "в нАтуре" возникает инверсия приоритетов, в чём это выражается, и о том, что для разработчиков NASA - это было совсем не так просто: http://zdnet.ru/?ID=312969 ). - "Аппаратно-программные средства тут нипричем" - а что же здесь "при чём" - промысел Божий? (ведь больше, кромме аппаратных и программных средств "здесь" ничего не используется).

Заметьте - основная инверсия приоритетов совсем не в программе...
Попутно добавлю - ну просто удивительно читать объяснения в стиле " По словам главы группы управления полетом Дженифер Троспер, ученые занимаются очисткой памяти "Спирита", переполнение которой, скорее всего, было причиной проблем." Можно подумать, что элементарного теста на создание пресловутых 1700 файлов, образовавшихся за время полета, выполнено не было