реал тайм осы

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

Не "показывать не хочет" - а "не находит уместным это делать второпях и кой-как"...
Но в самом скором времени:
- проделаю на различных OS (хотя бы минимальном наборе);
- допишу текстовые разъяснения того, что написано и происходит;
- найду URL, где это сделать более уместно...

... и выложу - как и всегда это делаю.

Но я там столько исписал, и ... "на пальцах", и мимикой - уже столько рассказал в самых деталях, что воспроизвести это, если совсем невмоготу - дело плёвое...

Еще кое что, по поводу RMS, раз это интересует.
В журнале RealTime Magazine была статья
J. Zalewski, What Every Engineer Needs to Know About Rate-Monotonic Scheduling: A Tutorial, Real-Time Magazine, S. 6-24, 1/ 1995
В которой меньше математики но больше практических рекомендаций. :) Нашел я ее здесь
http://www-md.e-technik.uni-rostock.de/ma/gol/ebsys.htm
не пугайтесь не английскому языку страницы, ссылку на статью там найти легко. Даю специально всю страницу, т.к. для себя там нашел еще кое что интерестное :)

To: evgen
Ну суть проблемы инверсии приоритетов вы наверное знаете, она хорошо описана в знакомой вам статье Сергея Сорокина в журнале СТА. Примерно также, если опустить лирические отступления о паровом катке и числе Пи описал эту проблему Олег, и если Вы считаете ее не серьезной, то Вы сильно заблуждаетесь. Такое отношение погубило реал тайм расширения тогоже, так нелюбимого вами NT. Это проблема, практически на поддающаяся тестированию и исходники в ее понимании Вам ничем не помогут. Фактически все сводится к следующему. Для защиты данных от совместного изменения и искажения их надо блокировать. Если поток, заблокировавший данные вытеснен более приоритетным, данные так и остаются заблокированными. Это в свою очередь, блокирует высокоприоритетный поток нуждающийся в доступе к этим данным. Ну а если управление после этого не возвращается к низкоприоритетномк потоку, дабы он отпустил заблокированный ресурс имеем большую проблему.
Фактически все упирается в механизм блокировки данных (ресурса). В этом контексте термин наследование приоритета конечно идиотский. Он только все путает и ничего не разясняет. Кто наследует, от кого и главное зачем?
На практике же обстоит все следующим образом. При блокировании высокоприоритетного потока на доступе к некоторому блокированному ресурсу перед системой ставиться задача разблокирования этого ресурса и выполнения высокоприоритетного потока (deadline то приближается). Но как это сделать не потеряв данных? Просто вырвать из цепких лапок ресурс у низкоприоритетного потока нельзя. Значит он должен доделать максимально быстро свои дела, отпустить ресурс, после чего его можно спокойно задавить и пустить высокоприоритетный поток. А чтобы этому процессу никто не помешал для этого низкоприоритетному потоку надо дать (на время критической секции) высокий приоритет. ТАк что в какой-то степени некое странное наследование приоритета присутствует но в какой-то извращенной форме.
Вообще, по моему, термины, образованные из подстрочного перевода с английского это какой-то саботаж.
Ну думаю я ничего не напутал.
Как я уже писал это не единственный метод борьбы с инверсией, хотя возможно на сей день смый проверенный. Или я чего не знаю (опасное это слово - самый).
Но наследование тем не менее, не решает всех проблем инверсии, описанный мной случай с несколькими потоками и блокировками - это опасность о которой надо помнить и в ОС где есть наследование приоритетов, а опоздание в вашей системе приведет не к тому, что очередь возле банкомата соберется, а к тому что паровой каток взорвется :)

Чем мне понравился механизм Priority Ceiling Protocol
так это тем, что в ОС, где нет наследования приоритетов и защиты от инверсии, но приоритет потока можно менять в процессе его исполнения, этот протокол может быть реализован самим разработчиком. И таким образом возможность блокирования ресурса и потока его захватившего более приоритетым потоком, которому самому этот ресурс нужен исключается, хотя это и требует внимания и аккуратности.

Первоначально опубликовано Draggan а опоздание в вашей системе приведет не к тому, что очередь возле банкомата соберется, а к тому что паровой каток взорвется :)

В нашей системе чтоб не взорвалось согласно уставу, ГОСТам и здравому смыслу есть предохранительные клапана, плавкие предохранители и БОЛЬШАЯ КРАСНАЯ КНОПКА.

ЗЫ: остальное будем читать внимательнее в более спокойной обстановке.