Эт сильно упрощенный взгляд на вещи.
Во первых в RTOS не принято чтобы одна задача (она же поток, она же тред, здесь не путать с терминологией больших OS-ей, где это все разные вещи ) делала всю работу от начала до конца.
Обычно так: есть задача обработки входных сигналов, потом есть задача менеджер-демультиплексор входных данных в задачи приемники, потом собственно есть задачи с "бизнес логикой", те в свою очередь продукты своей жизнедеятельности могут отправлять обратно в некие сетевые стеки через цепочку задач или взаимодействовать с файловыми системами (которые тоже обслуживаются отдельными задачами) или системами HMI (humam-mashine interface).
При такой комплексности говорить об измерении и гарантировании каких-то микросекунд на реакцию на воздействие бессмысленно.
Решающую роль имеет только искусство профайлинга.
Только в RTOS этот профайлинг можно сделать за конечное время, а в неRTOS этим можно заниматься бесконечно. Профайлинг делают опытные спецы высшего пилотажа используя моделирование, для ламеров, конечно, RTOS не повод быть увереным что все получится realtime за отведенное на проект время.
Так вот, сложная структурированность на задачи реально позволяет в любой RTOS вытеснять уже начатый формироваться к отправке пакет более приоритетным пакетом. Точнее пакетом формируемым более приоритетным каналом. Канал здесь - это настроенная цепочка взаимодействия задач с соответствеющим образом тюнингированными свойствами планировщиков, очередей, мьютексов, семафоров и проч.
Непосредственно вытеснение пакетов на физической линии рассматривать не серьезно, поскольку оно принебрежимо мало по сравненю с переключение контекста большинства юзабельных осей.
Поскольку расчитывают на время реакции еще на порядок медленее чем переключение контекста, то
и вообще тема физики теряет смысл.
Остается только тема тюнинга логических каналов.
И вот тут-то и приходят решения типа CORBA где этот тюнинг уже выполнен.
Кстати в физ.линии CAN осуществляется не вытеснение пакетов, а только арбитраж пакетов одновременно готовых к передаче. Т.е. в СAN наличествуют те же коллизии что и в Ethernet.
Пакет не самого высокого приоритета непробившийся на передачу вынужден ждать неопределенно долго своей очереди.
А проблема планирования приоритетов в CAN для обеспечения жесткой константы времени реакции в многоузловых сетях практически никакими протоколами прикладного уровня не решена.
Цитата(ddiimmaa @ Dec 12 2008, 20:39)
Так давайте разберёмся! Во первых есть такая фишка, как вытеснение одного потока с меньшим приоритетом потоком с более высоким приоритетом. Вот блогадоря такой фишке можно как то сказать вот ребята я в своей ОС ГАРАНТИРУЮ что это вытиснение не будет НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ например не медленее чем за 20 мкс. И вот если ваша ещё высокоприоритетная задача будет обслуживать пришедшее событие (которое и послужило причиной вытеснения) в течении 40 мкс, то вот вам ребята и гарантия в 40+20=60 мкс.
Так вот теперь о сети. Тут два вопроса
1. Вытеснение обслуживания менее приоритетного пакета в сетевых функциях ОС над другим более приоритетным
2. Вытеснение пакета в самой сети.
По поводу первого скажу честно не встречал, хотя хотел бы увидеть. Везде пакет если уж приняли обрабатывать то обрабатывают до конца. Вот пока обработку этого пакета не завершили на более высоко приоритетный не переходят. То бишь вытесняющей многозадачности нет в этом смысле. Поэтому процесс анализа и давания каких-либо анализов сильно затрудняеться
Если кто подскажет где подругому с удовольствием погляжу.
Во вторых Из всего что известно мне вытеснение пакета одини другим есть только в сети CAN там адрес узла и есть приоритет больше адрес больше приоритет. Если передачу начинают два узла то менее приоритетный прекрашает передачу и без колизий ситуация разрешаеться.
А существуют ли в продаже сетевые вытесняющие RTOS ?, И где можно почитать об их устройстве?
Jul 1 2008, 20:20
