реал тайм осы

Первоначально опубликовано Sergey Sorokin

Первоначально опубликовано Sergey Sorokin

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

Мне кажется, что это слишком сильное утверждение... или требует более детальных разъяснений.

Но главное, из-за чего я решил ответить на этот постинг, вот он:

Первоначально опубликовано Sergey Sorokin

Это так же не связано с предсказуемостью. Наилучшая общая предсказуемость (не скорость) у одноприоритетных процессов с планировкой в стиле round-robin. Я бы советовал там, где можно, использовать не более 3 приоритетов (задачи «жесткого реального времени», «мягкого реального времени» и «фоновые» задачи). Иначе при большом количестве задач с приоритетами можно «перемудрить» и в результате какая нибудь нужная задача будет «поражена в правах».

Это насколько верное, по моему мнению, утверждение, и настолько не очевидно при "первом подходе", что мне захотелось на нём специально остановиться и дополнить.

Мне неоднократно приходилось быть руководителем проекта, или работать "играющим тренером" в команде разработчиков, а, поэтому, копаться и искать обоснования в чужих текстах. И у меня сложилось в результате отчётливое мнение:

- есть классы задач, которые невозможно или крайне сложно (по крайней мере ещё и эффективно) реализовать в рамках равноприоритетных ветвей выполнения;

- но таких случаев - исключительное меньшинство: единичные проценты...

- а что "первым просится", когда начинают проект?: набухать по максимуму приоритета ветвям, которые функционально критические, потом ещё поболее тем, которые кажутся важны... и так далее;

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

- только тогда, когда 100-кратный анализ 2-х ветвей не приводит к положительному решению по их равноприоритетной реализации, используя синхронизации IPC - так вот только тогда можно начинать подумывать о разносе приоритетов уровней.

- в классике параллелизмов (Дэйкстра, Хоар, мн.др.) предложено и аппробировано множество синхронизирующих примитивов: mutex, semaphore, condvar, rw-, spin-, sleepon- блокировки ... это только POSIX, да и то, наверное, не все (что вспомнил). Между разноприоритетными ветвями вы сразу же разрушаете логику работу всех тонких синхронизирующих механизмов, точнее, они просто не работают... Раздвигая приоритеты - вы принудительным силовым образом ломаете всю логику и возможности синхронизаций, поведение которых как-раз "прогнозируемо"! (обратите внимание, что в классической теории Дэйкстры - есть множество механизмов, но вообще нет какого-либо рассмотрения и даже упоминания приоритетности).

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

Но всё это, как ни странно, не противоречит требованиям большого числа уровней в RTOS:

- во-первых, я везде оговаривался - есть особые случаи, а OS должна обслуживать все, пусть даже самые редкие и экзотические ситуации;

- во-вторых, сами компоненты OS используют некоторое число приоритетных уровней (4-6-8). А приоритетные уровни, используемые прикладным проектом, желательно, чтобы не перекрывались (совпадали) с системными, во избежание их интерференции...

P.S. последнее замечание о числе уровней, используемых самой OS - никак не противоречит сказанному выше, и не должно толковаться как указание на низкую квалификацию её разработчиков: всё сказанное выше относится главным образом к прикладному программированию. Системное программирование, оперирующее с собственно осуществлением самих диспетчирующих процессов и т.п. - существенно отличается по характеру, и может требовать большего расщепления приоритетных уровней.