|
|
реал тайм осы |
Я спрашивал, а не утверждал. А теперь приведите ссылку хоть на одного эксперта, который был бы с вами согласен. |
|||
|
SY,
EK |
|||
 |
|||
Дело ваше - не хотите, чтоб кто-то другой посмотрел - не надо, только потом не обижайтесь, если вас будут "мордой тыкать" в ваши же ошибки. |
|||
|
SY,
EK |
|||
|
|||
|
evgen у Вас похоже странное представление о "нормальных людях". Почему все нормальные люди обязаны использовать микроконтроллеры? С писюком, как Вы выражаетесь, бывает и проще и дешевле и самое главное БЫСТРЕЕ. Не всегда, но иногда по другому просто нельзя.
И знаете, банкомат не ахти какая СРВ система, или мне так не везет :-(?! Еще один вопрос, из того что Вы привели я так и не увидел реализовано ли в OS/2 какая-либо защита от инверсии приоритетов, например наследование приоритетов. (Пожалуйста не путайте динамические приоритеты, наследование приоритета от пораждающего потока и наследование приоритетов как механизм защиты от инверсии) |
|||
|
Draggan
Kharkov, QNX Seminars |
|||
|
|||
Ну хотя бы потому, что и в писюке - микроконтроллеры - видео/аудио/сеть/HDD/порты-COM/USB etc. Так называемые платы расширения - тоже чем дальше, тем больше "умных" - с процессором и памятью. Про ADAMы и аналогичное я вообще промолчу. Проще - вопрос спорный - все зависит от задачи. Дешевле - тоже, особенно учитывая стоимость QNX. Знаете сколько сейчас стоят PIC'и и DSP ? Особенно в сравнении с пром-писюками. И наконец - БЫСТРЕЕ - Быстрее что ? "Принимай Родина, очередное поделие ?" Распределенная система - центральный компьютер и сеть микроконтроллеров однозначно быстрее работает, хотя бы потому, что процессоров не один. Разработка - может быть медленнее для случая использования микроконтроллеров. Но - по первому разу. После первого раза разработчики обычно уже другого подхода не представляют. Более того, использование микроконтроллеров позволяет как удешевить разработку (лишних проводов тащить не надо), так и решить некоторые проблемы - например, с наводками, с измерением в высоковольтных частях etc.
Согласен - не ахти какая, но СРВ
Видимо я все-таки путаюсь и, честно сказать, не понимаю актуальности этой проблемы. Oleg исходников показывать не хочет...без исходников его вывод в stdout мне совершенно не понятен - я такого тоже могу произвести в любом виде и последовательности. |
|||
|
SY,
EK |
|||
|
|||
|
Olej вы находили описание механизма защиты от инверсии приоритетов? Ведь наследование приоритетов это классическое решение, не лишенное ряда недостатков. Например: Если средне и низкоприоритетных потоков много, и они разделяют разные ресурсы с высокоприоритетным потоком, то возможна ситуация, (не обязательно как ошибка разработчика, это может быть просто функциональным условием) когда высокоприоритетный поток вытеснит все низкоприоритетные, как раз тогда, когда они захватили ресурсы, ему нужные :( Крайне маловероятная ситуация, но не невозможная. И в этой ситуации высокоприоритетный поток будет таки выполнен, но для каждого потока, заблокировавшего ресурсы, система будет вынуждена повышать приоритеты и последовательно пускать их на выполнение. И в итоге deadline высокоприоритетного потока может быть пропущен!
Или другая ситуация: Только два потока В - высокоприоритетный и Н - низкоприоритетный и два ресурса Р1 и Р2. Поток Н неспешно выполняя свою задачу захватывает ресурс Р1 и тут его вытесняет поток В. Поток В захватывает ресурс Р2 и одновременно ему нужен ресурс Р1. Но он заблокирован потоком Н. Система поднимает приоритет Н, блокирует В, и запускает Н, но вот здесь начинается самое смешное, Н нужен ресурс Р2 для отработки своей части и отпускания ресурса Р1. Конечно совсем не распространеная ситуация, но опять таки не невозможная. Это может бять и неправильное проектирование, и такую ошибку найти будет невероятно трудно. Одним из механизмов защиты от такой ситуации является технология Priority Ceiling Protocol. В соответствии с ней объекту синхронизации (семафору или мютексу не важно) присваивается некий приоритет, соответствущий самому высокому приоритету из списка потоков, к нему собирающихся обратиться. И когда не самый высокоприоритеный поток блокирует этот объект синхронизации его приоритет системой поднимается до значения, соответствующего приоритету обекта управления. Таким образом, поток, захвативший ресурс не может быть прерван внутри critical section более приоритетным потоком, нуждающимся в этом ресурсе. |
|||
|
Draggan
Kharkov, QNX Seminars |
|||
|
|||
Если бы каждую из систем можно было бы подвергнуть такому тестированию: - сгенерировать достаточно плотный временной ряд (например от случайного генератора) всех потенциально возможных возмущающих внешних воздействий... - и построить кросс-корреляционную функцию этого ряда с рядом выходных реакций, вызванных этими возмущениями (к вопросу: как коррелировать дискретные события - точно так, как это делается в знаковой корреляции клипированных сигналов - накоплением совпадений/антисовпадений)... Так вот вид этой кросс-корреляционная функция была бы достаточно характерной мерой соответствия системы realtime требованиям: для жёсткого realtime это было бы что-то, напоминающее дельта-функцию, а для систем, далёких от realtime - это было бы мягкое распределение типа гаусса, максвела... Естественно, что вид кросс-функции будет (должна) зависить от плотности возбуждающего потока, т.е. система, удовлетворительно realtime - не будет таковой для какого-то более интенсивного потока воздействий. Но, если уже не-realtime - то ему ничего не поможет. Кстати, в таком мысленном эксперименте хорошо просматривается и место термина soft-realtime: это ККФ некоторой произвольной ширины, величина которой... чисто "с потолка" определяется самим дающим определение, чисто исходя только из желания (и стремления) продать своё детище. Поэтому, с самим термином soft-realtime можно мириться только приняв оговорку, что такой realtime, тогда, может быть количественно - сколь угодно "soft": "мой realtime - soft, ... а мой - в 2.5 раз soft-ее". |
|||
|
|||
Блеск! "Процесс пошёл"(с) - теперь у нас есть: - hard realtime; - soft realtime; - realtime не ахти какая; ... Кто больше?! Ваши ставки, господа... |
|||
|
|||
1. это задачка совсем из другой области - это классический deadlock, только приукрашенный динамическим наследованием приоритетов на объекте синхронизации. 2. эта, другая, область (взаимные блокировки), может и не менее интересная, но расматривается... другими методами и т.д. 3. взаимные блокировки действительно практически всеми о них говорящими - относятся к неправильности проектирования приложения. 4. взаимную блокировку, описанную выше - найти будет не так и сложно: она статическая, т.е. зафиксируется после своего возникновения... навечно - анализируйте состояние OS! В случае инверсии - всё гораздо хуже: она может динамически возникать (на 1мс., как? ;-)) - и после этого - ликвидироваться... - вот здесь поискать придётся. 5. вообще, как-то принято считать, что то, что "инверсия приоритетов" - может возникать только при одновременном взаимодействии 3-х и более потоков выполнения. Всё, что менее - это другие эффекты. |
|||
|
|||
отматывание треда назад для повторого прочтения отличия ОСРВ от СРВ - по таксе. (с)r.o.c. |
|||
|
SY,
EK |
|||
|
|||
У вас это одинаково хорошо получается... - Вам что больше нравится: самогон или спирт? - Не знаю даже как и сказать: и то и другое - так вкусно... (с)С.Давлатов.
Я вам не ссылку, я вам цитату приведу, на "хоть на одного эксперта, который был бы с вами согласен", вот она:
|
|||
|
|||
Ответить 
|
Страница <1 2627282930 36> |
| Переход на форум | Права доступа на форуме  Вы не можете публиковать новые темы в этом форуме Вы не можете отвечать на сообщения в этом форуме Вы не можете удалять Ваши сообщения на этом форуме Вы не можете редактировать Ваши сообщения на этом форуме Вы не можете создавать голосования на этом форуме Вы не можете выражать своё мнение в голосованиях на этом форуме |
