Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Когда не нужна ОС РВ?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Страницы: 1, 2, 3, 4, 5, 6, 7, 8
Kopa
Что то изменилось, в понимании данного вопроса участниками дискуссии, по прошествию n-го времени и реалий текущего "бытия"?

P.S. Время самый "безжалостный" судья и палач.
Hmm
Kopa
Наконец до "всех дошло", что:
1. ООП - это тупиковое направление;
2. Все средства (ЯВУ, поддержка скриптов и т.п.) - для "ленивых";
3. Попытка стандартизовать методологию и средства реализации "изделия" служат для контроля работы ИТР и мерилом их средней квалификации/зарплаты.
Т.е. - всё это попытки обойти понимание предмета и лихо гнуть пальцы, вешая "начальству" терминологическую лапшу и прикрываясь поверхностной эрудицией.
Во всяком случае я вынес из прочтения топика похожее на это sm.gif
Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем. Пусть их продолжают исп-ть в китайских телефонах, а я воздержусь. Удачи!
Axel
Цитата(Hmm @ Sep 26 2012, 00:48) *
Kopa
Наконец до "всех дошло", что:

...в названии топика присутствует ошибка - не "Когда" а "Кому".
_Pasha
Цитата(Hmm @ Sep 26 2012, 00:48) *
Наконец до "всех дошло", что:

Проблема не в "тупиковых направлениях" а в путях развития. Если мейнстрим развивается так, что использовать его не представляется возможным, приходится ваять своё и видеть страшных сон о том, что делать, если придешь к тому, что без оных средств - никак, и как справляться со сторонними программами, экспоненциальным ростом писанины, вниканием в "чуждые" причуды типа MISRA итд.
Виктория
Цитата(Kopa @ Sep 25 2012, 23:20) *
Что то изменилось, в понимании данного вопроса участниками дискуссии, по прошествию n-го времени и реалий текущего "бытия"?

P.S. Время самый "безжалостный" судья и палач.


Для вновь прибывших, прочитайте весь топик, чтобы не возник "бесконечный цикл".

Для меня лично всплыл такой важный момент, над которым стоит размышлять при принятии решения ЗА и ПРОТИВ при выборе инструментария. Это вопрос валидации/верификации программного обеспечения, обсуждаемый в наше неспокойное время и метрологами (http://vniim.ru/annot-slaev.html, http://metrologu.ru/index.php?showtopic=6429) и научной общественностью.

Тема оказалась многогранной. Мне тоже было бы интересно мнение прежних участников.


_Pasha
Верификация ПО методом анализа исходников - это как раз то направление, в котором мифотворчество прекрасно себя чувствует sm.gif
Виктория
Цитата(_Pasha @ Sep 26 2012, 15:15) *
Верификация ПО методом анализа исходников - это как раз то направление, в котором мифотворчество прекрасно себя чувствует sm.gif

Не ехидничайте, Паша. Метрологи как и психиатры - шутки не любят. biggrin.gif

Цитата(Виктория @ Sep 26 2012, 15:10) *
Тема оказалась многогранной. Мне тоже было бы интересно мнение прежних участников.


Владимир Евгеньевич теперь руководитель тематической группы, на интернет-общение времени, наверно, нет.
Olej вроде мелькал...
_Pasha
Цитата(Виктория @ Sep 26 2012, 15:33) *
Не ехидничайте, Паша. Метрологи как и психиатры - шутки не любят. biggrin.gif

Да какие уж шутки: законодательно обязать всех использовать MISRA образца 2004года - и будет не до шуток. В нашей глобальной палате номер 6 такое возможно. И что самое главное: MISRA - это самые известные из правил, которые не помогают избежать ошибок. sm.gif Т.е. результата не будет, зато статистика/отчетность - будет на высоте. sm.gif
PS выросло огромное кол-во людей, у которых реакция на "bare-metal" примерно такая же, как у налогового инспектора на слово "недоимка" sm.gif
juvf
Цитата(Hmm @ Sep 26 2012, 03:48) *
1. ООП - это тупиковое направление;
вообще странно подобные заявления слышать. наверно они делаются ради троля. тут где-то был спор по поводу с++ на мк. Почему-то сразу пошел срач про ООП, люди почему-то считают что с++, ООП, СТЛ, шаблоны, паттерны и т.п. - это всё одно и тоже, синонимы. Конечно в с++ есть over9000 способов выстрелить себе в ногу, но это не значит что ооп не оправдан. Где-то ООП даёт ++, а где-то его бездумно используют создавая оверинженеринг. Надо уметь его готовить и использовать.

Цитата
2. Все средства (ЯВУ, поддержка скриптов и т.п.) - для "ленивых";

"Лень - двигатель прогресса"
"Хороший программист - ленивый программист"

Цитата
Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем.
Каких проблем? Писать свой говновайл(1) планировщик - вот это проблема. Две оси использую - никаких проблем. Как может человек обсуждать вкус свинины, не разу не попробовав её. Или может он просто не умеет её готовить?
_Pasha
Цитата(juvf @ Sep 27 2012, 08:30) *
Две оси использую - никаких проблем. Как может человек обсуждать вкус свинины, не разу не попробовав её. Или может он просто не умеет её готовить?

Дык огласите (приближенно) список задач, которые мк обязан выполнять на Ваших устройствах.
juvf
Цитата(_Pasha @ Sep 27 2012, 11:41) *
Дык огласите (приближенно) список задач, которые мк обязан выполнять на Ваших устройствах.

ээээ..... ну например некий пульт:
одна задача занимается клавиатурой, другая гуи, третья обмен по уарт, четвертая модбус, пятая 2-я линия модбус, шестая контроль аккумулятора...., ну и основная рабочая - обработка сигнала.

и что с этого списка? конечно это всё прекрасно без оси будет работать. через свой for(;;). Но ос позволяет раздробить весь проект, выделить из него узкую задачу, например контроль модбус, и сфокусировавшись на этой задаче написать её раз и забыть про неё. Написав одну задачу по обслуживанию модбуса, запускаю два экземпляра этой задачи.
Но, приходилось мне чужие тяжелые проекты поддерживать, расширять функционал. Писали фатаны :\m/: . Сишные "Атцы", презирающие с++ и ооп. Ну и? шаг вправо шаг в лево - траблы. Выявляются баги в ихнех самописных вечновайловых планировщиках. Есть и ОС индусами писанные, там тоже можно подчерпнуть немало траблов, но допустим µC/OS там уж всё вычещенно. ММдддаааа платная и дорогая. Чем FreeRTOS не вариант? всем миром тестится на всех платформах и во всех режимах. Я пока в этих осях багов не нашол. Да и на форуме по FreeRTOS скука.... о че там тусить, если проблем с ней нет? (хотя мож ни кто не пользует?)

ps правильно где-то было сказано что после освоения ртос вы уже не захотите while(1) писать. И действительно..... понадобилось для простенького девайса на атмеге169 написать прогу - ткнул туда ос, а она возьми да влезь... да ещё и работает, и имею все прелести вытесняющей многозадачности и разделения ресурсов. что в этом плохова?

Конечно есть бюджетные проекты и задачи там простые, однозадачные скажем, там и проц ставят 8-ног 1 кб пзу. там тока с++ или вообще асм без всяких ос. но если чуть посложнее.... и бюджет позволяет..... таже атмега128 - там не плохо уживётся ртос, ну а если вместо меги за теже деньги заложить стм32 - так там вообще ос без проблем. Если при разработке, понимаешь что с ос на заложенном камне будет тесно.... ну заложи проц чуть подороже. Щас благо дело маленькое удорожание проца дает несоизмеримобольшое увеличение вычеслительных ресурсов.

Я не кого не собираюсь вербовать в ртосоводов и оопэшников. Каждый сам делает выбор для себя. Но заявления типа
Цитата
1. ООП - это тупиковое направление;
...
...ОС РВ ... это доп-й источник проблем.
мне не понятны laughing.gif
_Pasha
Цитата(juvf @ Sep 27 2012, 12:14) *
ээээ..... ну например некий пульт:

Хех! Вот-тоже самое, но вместо gui - "на закуску" GSM-модем, два лога и файловая система . У меня два дня голова пухла, когда весь функционал тупо не влезал с фриртосью из-за большого "сцепления" по данным.
Головняк по поводу организации межпроцессного обмена, когда каждый процесс должен часто подсматривать за другими и посылка сообщений просто съест всю память программ. Иначе - будет бардак, ввиду отстутствия в тексте "прикладного смысла".
Как только переделал под прототреды с глобальной "бордой" данных - всё сразу стало на свои места. И стека хватает sm.gif И не нужно обращать томный взор на более старший камешек.

И я тоже не понимаю, что такое планировщик вида while(1), зато хорошо понимаю атмосферу, в которой подобные "читки для приезжих" рождаются.

Нет, есть конечно вещи, которые могут перевесить: например, математики в треде много, или количество сторонних либ в проекте. Но с нуля, вещь в себе...bare metal рулит.
juvf
Цитата(_Pasha @ Sep 27 2012, 16:07) *
Как только переделал под прототреды с глобальной "бордой" данных - всё сразу стало на свои места.
Ну.... я же говорю - каждый делает выбор для себя.


Цитата
что такое планировщик вида while(1)

вечный вайл

Код
int main()
{
init();
while(1)
{
//какойто полезный код...... по сути аналог планировщика задач в ОС
}
}
ViKo
Пробовал Keil RTX в качестве развлечений-упражнений. Понравилось. Теперь в реальном проекте буду использовать. Смысл вижу в том, что на кнопки изделие будет реагировать с незаметной для пользователя задержкой, не дожидаясь окончания обработки чего-то там...
Мне вот не совсем понятно, зачем обязательно между задачами обмениваться сообщениями, семафорами. А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке?
_Pasha
Цитата(juvf @ Sep 27 2012, 13:32) *
вечный вайл

Есть предложение обходиться без тривиальностей, тем более, когда while(1) хоть один раз да присутствует.
Ага, вот она, ссылка полугодичной давности - Who-wins-when-Cortex-M-adds-RTOS-abstraction-layer
Цитата
An RTOS abstraction layer will, by its very nature, not add to the RTOS functionality, but will make the code bigger and the execution slower. The RTOS abstraction layer will always be a prime candidate for removal.


Я нахожу в этой цитате логическое продолжение тому, о чем тут говорится.
Т.е. невозможность стричь всё под одну гребёнку. Любая абстракция без изменения инструментария(языка программирования) - сталкивается с подобной проблемой: Bigger Code, Slower Time, Worse Things! - предлагаю слоган sm.gif В пику филипсовскому "Let's make things better!"

Цитата(ViKo @ Sep 27 2012, 14:08) *
Смысл вижу в том, что на кнопки изделие будет реагировать с незаметной для пользователя задержкой, не дожидаясь окончания обработки чего-то там...
Мне вот не совсем понятно, зачем обязательно между задачами обмениваться сообщениями, семафорами. А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке?

1. Странное утверждение, кнопки с задержкой до окончания обработки чего-то == неправильный подход к программированию.
2. Изоляция процессов - это как раз второй смысл РТОС.
А третий, имхо, смысл - по поводу ресурсов системы - сделать их максимально "резиновыми", как, например разница между локальной переменной и глобальной.
ViKo
Цитата(_Pasha @ Sep 27 2012, 14:29) *
Странное утверждение, кнопки с задержкой до окончания обработки чего-то == неправильный подход к программированию.

Ну, как же - суперцикл. Запоминается нажатие по прерыванию, а обработка - когда очередь дойдет. Пока доберешься до обработки кнопки... Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу.
А с РТОС могу сразу уйти на обработку кнопки, не беспокоясь о состоянии задачи обработки сигнала.
MrYuran
Цитата(ViKo @ Sep 27 2012, 15:08) *
Мне вот не совсем понятно, зачем обязательно между задачами обмениваться сообщениями, семафорами. А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке?

А семафор это и есть по сути флаг, означающий занятость какого-либо ресурса.
Например, если два потока одновременно пытаются вывести данные в один порт, не зная ничего друг о друге и работая совершенно асинхронно
_Pasha
Цитата(ViKo @ Sep 27 2012, 14:33) *
Ну, как же - суперцикл. Запоминается нажатие по прерыванию, а обработка - когда очередь дойдет. Пока доберешься до обработки кнопки... Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу.

Издеваетесь? А конечные автоматы на что? А распределение задач по тайм-слотам?
ViKo
Цитата(MrYuran @ Sep 27 2012, 14:35) *
А семафор это и есть по сути флаг, означающий занятость какого-либо ресурса.

Мне эти сущности понятны. Изучил и использовал. Но зачем? Типа, чисто терминологическая абстракция?
MrYuran
Цитата(ViKo @ Sep 27 2012, 15:33) *
Приходилось обработку сигнала дробить на части, только чтобы быстрее бегать по суперциклу.

Стандартный подход.
Можно ещё и приоритеты ввести, путем continue внутри цикла.
То есть, сверху - самые приоритетные задачи, снизу - самые низкоприоритетные.
После выполнения любой из задач выполняется continue, который возвращает к началу цикла и соответственно, проверяет флаги задач в порядке убывания приоритета.
Каждая из задач в этом случае - конечный автомат с внутренними состояниями, который как можно быстрее возвращает управление обратно.
ViKo
Цитата(_Pasha @ Sep 27 2012, 14:36) *
Издеваетесь? А конечные автоматы на что? А распределение задач по тайм-слотам?

Ну, вот и приплыли! К ОС. rolleyes.gif
Какая уже разница - городить собственный конечный автомат, с условиями переходов, если можно взять готовую ОС с переключениями задач по событиям?
MrYuran
Цитата(ViKo @ Sep 27 2012, 15:42) *
Ну, вот и приплыли! К ОС. rolleyes.gif

В общем-то, да.
И даже для апологетов автоматного проектирования на основе прерываний можно написать такую ось, которая будет в той или иной степени автоматизировать и систематизировать процесс.
_Pasha
Цитата(ViKo @ Sep 27 2012, 14:42) *
Ну, вот и приплыли! К ОС. rolleyes.gif

А, ну если от ТАКОГО берега отчалить, то таки да biggrin.gif
Насчет семафора - это не только стандартный подход, но и способ не вызывать ожидающую задачу.
Например, при give() - внутри этого give() можно спрятать код, который "разбудит" все ожидающие семафор треды , а при take() - процесс, который "наступил" на занятый семафор - будет удален из списка очереди выполнения. Таким образом, "наворот" этот исключает оверхед перебора задач и поллинга. Приплыли к оси? sm.gif
Виктория
Цитата(_Pasha @ Sep 27 2012, 15:01) *
А, ну если от ТАКОГО берега отчалить, то таки да biggrin.gif
Насчет семафора - это не только стандартный подход, но и способ не вызывать ожидающую задачу.
Например, при give() - внутри этого give() можно спрятать код, который "разбудит" все ожидающие семафор треды , а при take() - процесс, который "наступил" на занятый семафор - будет удален из списка очереди выполнения. Таким образом, "наворот" этот исключает оверхед перебора задач и поллинга. Приплыли к оси? sm.gif


_Pasha, хочется узнать - в противостоянии OC РВ vs bare-metal Вы к какой стороне ближе?
Согласна, развитие технологий виртуализации - это ещё один аргумент в поднятии старой темы
_Pasha
Цитата(Виктория @ Sep 27 2012, 15:32) *
_Pasha, хочется узнать - в противостоянии OC РВ vs bare-metal Вы к какой стороне ближе?
Согласна, виртуалазация - это ещё один аргумент в поднятии старой темы

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

Вот для чего мне, спрашивается, тратить ОЗУ на хранение контекстов, если весь этот контекст сводится к одному указателю, если процесс сам знает, когда ему отдать управление (кооперативная многозадачка), если при использовании примитивов синхронизации у меня есть планировщик, который перебирает очередь выполнения, если железные прерывания у меня обслуживаются точно так же, в общем - если я знаю, что мне нужно, и могу достаточно долго сидеть на одном самом дешевом и доступном камне, потому что ресурсов 100% хватит на всё. И если мне надо установить один бит, то я его таки установлю, а не буду обращаться к системному вызову, или создавать сообщение "установите мне такой-то флаг" или пользоваться какой-либо другой дурковатой обёрткой.
То же касается любого API - как известно, он никогда не может быть хорошим.
А то - подключил дефолтные сторонние либы - еще ничего не сделал - мама дорогая! Уже нету 20% флеша! Ну это вообще... А там просто всего лишь зависимостей много.
Olej
Цитата(Hmm @ Sep 26 2012, 00:48) *
Ну а ОС РВ мне ещё не была нужна, т.к. это доп-й источник проблем. Пусть их продолжают исп-ть в китайских телефонах, а я воздержусь. Удачи!


Ну так тогда может уместнее пойти со своими "аргументами" и "понималками" bb-offtopic.gif ... куда-то в другую тему?
Потому как здесь тему назвали то: "ОС РВ"...

Виктория
Olej, здравствуйте.

1) Нам нужно понять, что функции ОС РВ ни в коей мере не сводятся к реализации конечного автомата. Хотя это и является одним из критериев выбора инструментария для своего приложения

2) Появление тенденций к сертификации ПО (валидации, верификации, ...). Можно ли сейчас предугать, кто выиграет гонку стандартизации?
juvf
Цитата
А просто иметь глобальные переменные, с флагами и т.д.? Или это уже противоречит принципам разделения на задачи, которые нельзя будет отлаживать поодиночке?

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


например с ос-ным флагам задачу по гуи можно оформить в 1 строчку.

Код
void task()
{
for(;;)
    currentWindow->pressedKey(OSGetMessage(QUEUE_KEY, 0));
}

как бы это выглядело с глобальной переменной
Код
void task()
{
    for(;;)
    {
        if(keyCode != 0)
        {
            currentWindow->pressedKey(keyCode);
            keyCode = 0;
        }
        else
            OSTaskDelayMs(50);
    }
}

по мне, так гораздо кошерний первый вариант. по памяти программ и латентности тут оба варианта примерно одинаковы. А вот по памяти данных 2-й выгрывает. По реакции на нажатие клавиши, т.е. на обработку нажатия (можно сказать на скорость выполнения программы) 1 вариант выигрывает. Если у меня найдется свободное озу, я всегда использую 1 вариант.
Kopa
Sorry, не удержался от частичного офтопикаsm.gif но тема подходящая.
Проект призёр 2nd Prize! Philips ARM Design Contest 2005
noPC (сайт разработчика)
Проект на базе LPC2138/2148 автономного "компьютера".

P.S. В данном варианте, Форт операционная среда замещает функции операционной системы.

Цитата(juvf @ Sep 27 2012, 18:50) *
Вообще в любом коде глобальные переменные - это шаг назад. Но когда пишешь ПО для мк с ограниченными возможностями ресурсами, то это вполне оправданный шаг.


Очень ценное замечание! (В программах на Форт, в силу "широкого" использования стеков для неименованной передачи параметров их почти нетsm.gif
Author: Philip J. Koopman, Jr. WISC Technologies, Inc., Pittsburgh, PA © Copyright 1989
Stack Computers: the new wave, zip-архив, online web version
Philip Koopman's Home Page

Olej
Цитата(Kopa @ Sep 27 2012, 18:56) *
Очень ценное замечание! (В программах на Форт, в силу "широкого" использования стеков для неименованной передачи параметров их почти нетsm.gif
Author: Philip J. Koopman, Jr. WISC Technologies, Inc., Pittsburgh, PA © Copyright 1989
Stack Computers: the new wave, zip-архив, online web version


Forth был достаточно интересный проект... Но:
- к чему-либо, что имеет отношение к функциональности ОС РВ (см. имя темы) - он просто неуместен;
- он именно был, у него было мощное community ... но всё это в прошлом - книжка то показанная тоже 1989г. - 23 года, ... как-то напомнило даже из Иосифа Бродского:
Цитата
Двадцать лет это срок,
Что длиннее и глубже могилы.


Kopa
Цитата(Olej @ Sep 27 2012, 20:51) *
Forth был достаточно интересный проект... Но:
- к чему-либо, что имеет отношение к функциональности ОС РВ (см. имя темы) - он просто неуместен;
- он именно был, у него было мощное community ... но всё это в прошлом - книжка то показанная тоже 1989г. - 23 года, ... как-то напомнило даже из Иосифа Бродского:

- Форт и сейчас, достаточно интересный проектsm.gif
- Зачем "мощное" communty для "экспериментальных" разработок?

P.S. Многоядерные процессоры с низким энергопотреблением-Архитектура процессоров SEAforth Как в этом случае "трансформируется" понятие и функционал операционной системы? (сейчас у данных "процессоров" 144-ядра Процессоры GA144)
48-ядерный процессор Intel для "облачных" вычислений. ( 07.12.2009 новости уже около 3-х лет
и что далее?)
Olej
Цитата(Kopa @ Sep 28 2012, 17:44) *
- Форт и сейчас, достаточно интересный проектsm.gif

Цитата
Кому и кобыла - невеста.

Так, кажется, это звучало в первоисточнике? 1111493779.gif
Владимир Е. Зюбин
Доброго здравия всем присутствующим!

Цитата(ViKo @ Sep 27 2012, 17:42) *
Какая уже разница - городить собственный конечный автомат, с условиями переходов, если можно взять готовую ОС с переключениями задач по событиям?


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

И еще ладно, если задач всего с десяток... а если их тысяча?

В общем, "задача" это очень тяжеловесно. Поэтому разработчики просто вынуждены использовать более легковесные подходы и организовывать планирование на более низком уровне.
_Артём_
Цитата(Владимир Е. Зюбин @ Sep 29 2012, 17:16) *
И еще ладно, если задач всего с десяток... а если их тысяча?

Это вы в контексте МК говорите?
Так тысяча это мало, нужно тысяч 10 для начала...



Цитата(Владимир Е. Зюбин @ Sep 29 2012, 17:16) *
планировщик передает управление некоторой задаче, задача проверяет факт наступления события, а событие не наступает... даже если механизм переключения несколько более сложен, чем разделение по времени, суть не меняется: каждая процедура передачи управления это сохранение контекста и восстановление контекста задачи.

Зачем передавать управление, если событие не произошло?
Когда произойдёт тогда и нужно передавать (в соответствии с приоритетом).
_Pasha
Цитата(Владимир Е. Зюбин @ Sep 29 2012, 17:16) *
а это непроизводительные расходы: планировщик передает управление некоторой задаче, задача проверяет факт наступления события, а событие не наступает...

Здравствуйте!
Вы очень вовремя (как по мне) затронули этот вопрос. Хотел даже тему создать, но спрошу здесь, уже в данном контексте.
Все пользователи реалтаймовости рано или поздно приходят к тому, что надо бороться с любыми элементами поллинга, использовать синхронизацию потоков для того, чтобы лишний раз не трогать спящий поток, пробуждения по прерываниям, триггеры итп. Простой пример
Код
time = get_tick();
wait(process2->end_packet || (tick_diff(time) > TIMEOUT));

Такой вот примитив синхронизации. Процесс ждет какого-то там окончания либо таймаута, при этом, естественно, реализация этих действий поллингом, не вызывает никаких затруднений.
Если же процесс засыпает намертво, т.е. до соблюдения указанных условий его и вызывать- то никто не собирается, встает закономерный вопрос: А кто будет проверять эти условия, и самое главное - когда?
Если с несчастным process2->end_packet все ясно: можно обернуть все геттером или функцией process2->end_packet() внутри которой спрятать добавление "вопрошающего" в список клиентов, которых надо будить при наступлении события end_packet,
то с таймерами дела обстоят похуже: поллинг никуда не девается, можно лишь уменьшить его накладные расходы.
Для этих целей все мы вынуждены порождать и использовать новые сущности. Но как быть, если при большом количестве подобных ожиданий событий код рискует оказаться либо распыленным по десятку файлов, либо стать нечитабельным, сильно затеняя "прикладной смысл", либо оказаться с неприменимо большой глубиной вложенности подпрограмм?
Вот и интересны мнения аудитории по данному кругу вопросов.
ViKo
Цитата(Владимир Е. Зюбин @ Sep 29 2012, 17:16) *
В планировщике есть: очень сложно настроить планировщик на переключение по произвольным событиям, так как это требует передачи планировщику информации о контексте задачи (управляющего алгоритма)... поэтому часто используется одно событие -- прерывание от таймера... а это непроизводительные расходы: планировщик передает управление некоторой задаче, задача проверяет факт наступления события, а событие не наступает... даже если механизм переключения несколько более сложен, чем разделение по времени, суть не меняется: каждая процедура передачи управления это сохранение контекста и восстановление контекста задачи.

Плохо понял. У задачи есть переменная, назовем "регистр событий". События, которых задача ожидает, задаются в самой задаче, а устанавливаются в других задачах, которым требуется запустить на выполнение первую. Проверяются же события самой ОС. Если заданное событие наступило, планировщик запустит задачу, если нет более приоритетных.
Владимир Е. Зюбин
Цитата(_Артём_ @ Sep 29 2012, 20:53) *
Это вы в контексте МК говорите?
Так тысяча это мало, нужно тысяч 10 для начала...


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

Что касается десяти тысяч задач, то мне это представляется нереальным для ОС, как впрочем, и
тысяча...

Подскажите, где такое встречается, было бы интересно рассмотреть...

Цитата(_Артём_ @ Sep 29 2012, 20:53) *
Зачем передавать управление, если событие не произошло?
Когда произойдёт тогда и нужно передавать (в соответствии с приоритетом).


Один из подходов. Когда события отслеживаются выделенным модулем-супервизор и решение о реакции на событие возлагается на него же... на мой взгляд, это неплохо работает, когда все события поддержаны аппаратным прерыванием. Таких событий немного, они заранее известны и алгоритм их обработки более-менее понятен. А вот если у вас в алгоритме событий десятки тысяч, то вопрос их обработки в едином месте может вызвать проблемы (я, честно признаться, даже не представляю, как это сделать рационально)...

Например, у вас есть модуль на восемь логических входов... 16 примитивных событий (положительный фронт/отрицательный фронт)... казалось бы... но это же не все возможные события... а если эти входы взаимосвязаны (для простоты это 8-ми разрядный АЦП)... сразу же получаем 256*2 событий. А если на интересуют события типа "вход i-ый в нуле И положительный фронт j-го входа,состояние остальных входов не интересует"? начинается уже комбинаторика... А если вас интересуют временные интервалы и события типа "вход i-ый не сбросился по истечению трех секунд"? и т. д. При этом события, "интересные" с точки зрения конкретной задачи могут изменятся в зависимости от происходящего... это ведь тоже реалии жизни при создании управляющих алгоритмов.

В общем, если кратко: управление имеет смысл передавать, когда супервизор сам не в состоянии разобраться с событиями... как предельный случай -- полная ликвидация супервизора (планировщика ОС).
_Pasha
Цитата(Владимир Е. Зюбин @ Sep 30 2012, 16:05) *
А если на интересуют события типа "вход i-ый в нуле И положительный фронт j-й,состояние остальных входов не интересует"? начинается уже комбинаторика...


Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер.

Цитата
А если вас интересуют временные интервалы и события типа "вход i-ый не сбросился по истечению трех секунд"? и т. д.

А на сей счет уже лучше не придумаешь, чем на основе имеющихся свободных таймеров создавать "аларм-листы", с контролем равномерности загрузки этих таймеров, чтобы в прерывании, в к-ром происходят проверки, не задерживаться слишком надолго. Хотя, все зависит от точности временной задержки- можно ведь и уставки сортировать и загружать новые значения в таймер по мере их поступления из очереди.
Владимир Е. Зюбин
Цитата(_Pasha @ Sep 29 2012, 21:03) *
Все пользователи реалтаймовости рано или поздно приходят к тому, что надо бороться с любыми элементами поллинга <...> Простой пример
Код
time = get_tick();
wait(process2->end_packet || (tick_diff(time) > TIMEOUT));

Такой вот примитив синхронизации. Процесс ждет какого-то там окончания либо таймаута, при этом, естественно, реализация этих действий поллингом, не вызывает никаких затруднений.
Если же процесс засыпает намертво, т.е. до соблюдения указанных условий его и вызывать- то никто не собирается, встает закономерный вопрос: А кто будет проверять эти условия, и самое главное - когда?
<...>
Для этих целей все мы вынуждены порождать и использовать новые сущности. Но как быть, если при большом количестве подобных ожиданий событий код рискует оказаться либо распыленным по десятку файлов, либо стать нечитабельным, сильно затеняя "прикладной смысл", либо оказаться с неприменимо большой глубиной вложенности подпрограмм?


Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)...

Может, специалисты в "реалтаймовости" нам тут подскажут...
Владимир Е. Зюбин
Цитата(_Pasha @ Sep 30 2012, 20:00) *
Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер.


наверное это можно делать, даже если в системе не предусмотрены прерывания по изменению значений на входах... только в чем преимущества такого подхода и каков механизм? Каждый раз перед тем, как передать управление, задача сообщает планировщику о событии, по которому ее надо разбудить... причем, события же могут быть весьма нетривиальными, по сути произвольная последовательность суперпозиций элементарных событий в системе, как то: изменение значения логической переменной, окончание временного интервала после некоторого события, тот или иной результат выполнения некоторой задачи, и проч.

Не могли бы вы дать ссылку, чтобы можно было ознакомиться с таким подходом?

Цитата(_Pasha @ Sep 30 2012, 20:00) *
А на сей счет уже лучше не придумаешь, чем на основе имеющихся свободных таймеров создавать "аларм-листы", с контролем равномерности загрузки этих таймеров, чтобы в прерывании, в к-ром происходят проверки, не задерживаться слишком надолго. Хотя, все зависит от точности временной задержки- можно ведь и уставки сортировать и загружать новые значения в таймер по мере их поступления из очереди.


Я, честно признаться, не понял идеи. Особенно про контроль равномерности загрузки... Какой смысл отрывать проверку на событие от описание реакции на это событие, да еще и с, как мне показалось, дополнительными усложнениями?



Цитата(ViKo @ Sep 29 2012, 21:58) *
Плохо понял. У задачи есть переменная, назовем "регистр событий". События, которых задача ожидает, задаются в самой задаче, а устанавливаются в других задачах, которым требуется запустить на выполнение первую. Проверяются же события самой ОС. Если заданное событие наступило, планировщик запустит задачу, если нет более приоритетных.


Я тоже плохо понимаю ваш вопрос. "У задачи есть переменная..." это я понял, а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения...
Виктория
Цитата(_Pasha @ Sep 30 2012, 17:00) *
Мы можем пользоваться такими ср-вами, которые позволят осуществить проверку совокупности условий только один раз, когда один из термов меняется. При выполнении условий управление передается в поток, к-рый "заказал" триггер.
...


Эти средства встроены в операционную систему? Я тоже не знаю, было бы интересно узнать
_Артём_
Цитата(Владимир Е. Зюбин @ Sep 30 2012, 19:29) *
а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения...


Наверное имелось в виду что-то такое:

Код
void UART_RxC_Isr()
{
    NewByte.SignalISR(); // байт принят
}

void Task()
{
    while (1) {
        NewByte.Wait(); // событие которое ожидает задача
    }
}
_Pasha
Цитата(Владимир Е. Зюбин @ Sep 30 2012, 19:16) *
Не могли бы вы дать ссылку, чтобы можно было ознакомиться с таким подходом?


Ссылка - здесь и сейчас sm.gif Даже если я изобретаю "лисапед", обращаю Ваше внимание на такую вещь. Допустим, какой-либо процесс X ожидает комбинации условий (булевых переменных) (a==1)&&(b==0)&&(b_prev==1), что означает вход a в высоком уровне, вход b - переход 1->0, от других процессов. Вопрос детский: что мы можем сделать, чтобы уменьшить количество проверок, то бишь поллинг? Мы должны сообщить поставщику данных, чтобы он разбудил процесс Х именно при наступлении указанного условия, т.е. делегировать проверки тому процессу, который отвечает за прием a,b или сам процесс Х должен быть поставщиком для себя. Во втором случае проблема решена: никакого поллинга, но есть вопрос: а когда ему брать данные? Т.е. избавились от асинхронности-пришли к временным интервалам. И что лучше из трех вариантов - асинхронная обработка с поллингом, синхронная с семафором либо вообще слияние процессов - выбирать надо по месту.

Цитата
Я, честно признаться, не понял идеи. Особенно про контроль равномерносати загрузки... Какой смысл отрывать проверку на событие от описание реакции на это событие, да еще и с, как мне показалось, дополнительными усложнениями?


Это опять же диалектика проявляется: (проверка события+реакция в одном потоке) vs (отправитель - получатель). Если нам выгоднее вторая форма, т.е. отдельные потоки - значит есть другие более веские факторы. Например, поток обрабатывает пакеты какого-л интерфейса и нам лучше его оформить так, чтобы он был вещью в себе - и работал на нескольких разнотипных устройствах.

Про контроль равномерности. Например, у нас есть несколько свободных таймеров с функцией компаратора и соответствующего прерывания. Тогда проще разбросать аларм-лист по всем ресурсам равномерно, чем делать одну длиннющую очередь и довольно часто обслуживать ее, перезагружая компаратор в прерывании. Во втором случае, конечно, универсальнее - "безобразно, зато единообразно" sm.gif
i-mir
Как раз сейчас разбираюсь с работой ПЛИС и доказательством безопасности
сего устройства в условиях грозовых перенапряжений.

ИМХО задача поллинга превышающая разумные пределы для последовательных
контролеров должна быть устранена переходом на параллельную логику, те
же ПЛИС. Действиетльно последовательный контроллер больших систем уже
не вытягивает, т.к. он есть банальным воплощением машины Тьюринга, пусть
и мощной. Ваша система рано или поздно "наткнется" на ограничение, т.к.
все данные (а в реальности они все параллельные) нужно прокачать сквозь
узенькое игольное ушко - счетчик адреса контроллера. Это так называемый
функциональный предел. Дальше никуда.

Ядерщики первыми начали пользовать ПЛИСы для своих нужд - думаю на
сегодня это одно из наиболее перспективных решений по работе со сложными
системами.


juvf
Цитата(Владимир Е. Зюбин @ Sep 30 2012, 20:02) *
Цитата

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

Код
time = get_tick();
wait(process2->end_packet || (tick_diff(time) > TIMEOUT));

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

Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)...

Может, специалисты в "реалтаймовости" нам тут подскажут...


Что такое поллинг? Это ожидание одной задачей несколько событий?....
Вот как ВАШ простой пример выглядел бы в FreeRTOS
Код
if( xSemaphoreTake((process2_end_packet_Flag , TIMEOUT) == pdPASS )
{//дождались события
}
else
{//недождались события, вышел TIMEOUT
}

можно ждать и несколько событий.... пример на µС/OS
Код
uint8_t err;
OSFlagPend(statusFlags, P2_END_PACKET | P2_BREAK_PACKET, OS_FLAG_WAIT_SET_ALL, TIMEOUT, &err);
switch(err)
{
    case OS_NO_ERR:
        //были УСТАНОВЛЕНЫ флаги P2_END_PACKET и P2_BREAK_PACKET до таймаута TIMEOUT
        break;
    case OS_TIMEOUT:
    default:
        //сработал таймаут или какая-то др. ошибка
        break;
}

ОС у задачи заберёт процессор (задача уснёт на мертво) в момент обращения к методу OSFlagPend() или xSemaphoreTake(). Как толко наступит нужное(ые) событие(я) или пройдет TIMEOUT времени с момента засыпания, то ОС сразуже сама разбудит задачу и передаст ей управление (при условии что нет незаблокированных более приоритетных задач).
_Pasha
Цитата(i-mir @ Sep 30 2012, 22:05) *
Ваша система рано или поздно "наткнется" на ограничение, т.к.
все данные (а в реальности они все параллельные) нужно прокачать сквозь
узенькое игольное ушко - счетчик адреса контроллера. Это так называемый
функциональный предел. Дальше никуда.

Цитата
То Талллинна талекооо
sm.gif
Тут игольных ушек и других хватает: интерфейсы\ протоколы связи с внешним железом
ViKo
Цитата(Владимир Е. Зюбин @ Sep 30 2012, 19:29) *
Я тоже плохо понимаю ваш вопрос. "У задачи есть переменная..." это я понял, а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения...

У меня нет вопроса. А ответ есть. На сайте Keil что-то не находится, придется выдать из личных запасов. Рекомендую проштудировать часть про RTX.
ViKo
Цитата(i-mir @ Sep 30 2012, 22:05) *
Ядерщики первыми начали пользовать ПЛИСы для своих нужд - думаю на
сегодня это одно из наиболее перспективных решений по работе со сложными
системами.

А Windows 7 - сложная система? Каждому - свое. Лично я использую и то, и другое. Одновременно.
Olej
Цитата(Владимир Е. Зюбин @ Sep 30 2012, 17:02) *
Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)...


Просто в разговоре, который "простёрся" на 24 стр. обсуждения и растянулся на 6 лет rolleyes.gif смешались в кучу примеры и представления из совершенно разных областей применения :

1. До тех пор, пока не нужна приоритетная многозадачность ни о какой ОС РВ разговаривать нет смысла вообще ... нет конкурентной многозадачности - и всё само собой и так становится "реалтайм", в этом смысле можете считать MS-DOS ОС РВ, и будете в значительной степени правы.

2. Никакие абсолютные временные характеристики (латентность, времена переключения и т.п.) к реалтаймовости не имеют никакого минимального касательства - это вопросы масштаба времени. Возьмите процессор в 10 раз быстрее - и наслаждайтесь в 10 раз меньшей латентностью. Так что "реалтайм" - термин (не очень определённый) скорее из области надёжности и безотказности системы, а не из области временных характеристик.

3. К области логических автоматов в промышленных управляющих системах, к языкам МЭК 61131-3 ... и Рефлекс - куда склоняет разговор Зюбин В.Е. biggrin.gif - терминология реалтайм неприменима ни в каком смысле, ни в положительном, но в отрицательном. Это совершенно другие вещи. Здесь логика совершенно другая: идёт циклический поллинг N входных воздействий + никакая другая конкурирующая задача не может возникнуть на процессоре, если у вас даже процесс управления занимает 5% потенциальной производительности процессора PLC (из-за ошибки или жадности проектировщика), то никакая другая задача не станет использовать остающиеся 95%.

4. Т.е. реалтаймовая терминология воообще применима только к системам общего применения с асинхронно возникающими задачами, или пиковыми всплесками потребности производительности... В том числе, достаточно часто эти пиковые всплески могут происходить как следствие активности человека-оператора. Или в серверных системах массового обслуживания, в тех, которые представляют максимально популярные сейчас "облачные" сервисы. И алгоритмика "разруливания" запросов конкурирующих процессов (дисциплина диспетчеризации) может быть для обеспечения реалтайм (RT OS) и весьма замысловатой (POSIX 1003.b: спорадическая, адаптивная, ...) и уж заведомо отличающейся от дисциплины диспетчеризации системы общего использования (GP OS)

5. Интересно, в смысле иллюстрации, в этом смысле современная (раньше было по-другому) структура сетевого стека Linux:
- здесь ведь только 1-й пакет "сетевой пачки" принимается по IRQ ...
- дальше модуль сетевого устройства переходит к программному поллингу всех последующих пакетов ...
- до тех пор, пока интенсивность "сетевого всплеска" не упадёт, и можно снова уйти на ожидание по IRQ.
Подробней см.: Модули ядра Linux.
Владимир Е. Зюбин
Цитата(_Pasha @ Sep 30 2012, 22:51) *
Допустим, какой-либо процесс X ожидает комбинации условий (булевых переменных) (a==1)&&(b==0)&&(b_prev==1), что означает вход a в высоком уровне, вход b - переход 1->0, от других процессов. Вопрос детский: что мы можем сделать, чтобы уменьшить количество проверок, то бишь поллинг? Мы должны сообщить поставщику данных, чтобы он разбудил процесс Х именно при наступлении указанного условия, т.е. делегировать проверки тому процессу, который отвечает за прием a,b или сам процесс Х должен быть поставщиком для себя. Во втором случае проблема решена: никакого поллинга, но есть вопрос: а когда ему брать данные? Т.е. избавились от асинхронности-пришли к временным интервалам. И что лучше из трех вариантов - асинхронная обработка с поллингом, синхронная с семафором либо вообще слияние процессов - выбирать надо по месту.


тяжело общаться, когда нет единого языка...

1. не понятно, что такое "поставщик данных"... я так понимаю, есть либо процедура считывания состояния входов, ну или процедура обработки прерывания, которые либо тупо считывают состояния входов и записывают их в ОЗУ, либо еще пытаются вычленять события (что, как мне кажется, проблематично в принципе, если события неэлементарны)

2. не понятно, что Вы имеете ввиду под "поллингом", "проверка состояния входа через непосредственное считывание"?
в словарях все как-то расплывчато: To check the status of an input line, sensor, or memory location to see if a particular external event has been registered. http://foldoc.org/polling

3. Устройство ПО управляющих цифровых систем, как я понимаю, обычно строится по стандартной циклической схеме, используемой в тех же ПЛК, состоящей из трех процедур: "чтение входных данных" -> "обработка" -> "запись выходных данных"... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная.


Цитата(_Pasha @ Sep 30 2012, 22:51) *
Это опять же диалектика проявляется: (проверка события+реакция в одном потоке) vs (отправитель - получатель). Если нам выгоднее вторая форма, т.е. отдельные потоки - значит есть другие более веские факторы. Например, поток обрабатывает пакеты какого-л интерфейса и нам лучше его оформить так, чтобы он был вещью в себе - и работал на нескольких разнотипных устройствах.


А можно привести пример? Я с интерфейсами и разнотипными устройствами не понял. Вас можно так понять, что Вы пишете модули, которые абстрагируют UARTы и Ethernet-сокеты...

Цитата(_Pasha @ Sep 30 2012, 22:51) *
Про контроль равномерности. Например, у нас есть несколько свободных таймеров с функцией компаратора и соответствующего прерывания. Тогда проще разбросать аларм-лист по всем ресурсам равномерно, чем делать одну длиннющую очередь и довольно часто обслуживать ее, перезагружая компаратор в прерывании. Во втором случае, конечно, универсальнее - "безобразно, зато единообразно" sm.gif


Я так понял, под "аларм-лист" предлагается заводить что-то типа списка чисел (а может, и еще чего-то), которые требуется загружать в компаратор после каждого прерывания... только я не понял, зачем так сложно? И почему разбросав этот "аларм-лист" по нескольким таймерам получится какой-то выигрыш? Прерывания будут следовать ровно с той же частотой, используете вы один таймер, или 100.

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

Цитата(Olej @ Oct 1 2012, 14:47) *
Просто в разговоре, который "простёрся" на 24 стр. обсуждения и растянулся на 6 лет rolleyes.gif смешались в кучу примеры и представления из совершенно разных областей применения :


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

Цитата(Olej @ Oct 1 2012, 14:47) *
1. До тех пор, пока не нужна приоритетная многозадачность ни о какой ОС РВ разговаривать нет смысла вообще ... нет конкурентной многозадачности - и всё само собой и так становится "реалтайм", в этом смысле можете считать MS-DOS ОС РВ, и будете в значительной степени правы.


Мне кажется, что "приоритетная многозадачность" это просто некоторое средство для решения некоторой проблемы. Мне понятно, зачем она нужна под Windows 7, и вообще зачем нужна многозадачная ОС для компьютеров общего назначения, тоже понятно... но зачем она нужна, например, для платформы Arduino, мне понять уже трудно...

Цитата(Olej @ Oct 1 2012, 14:47) *
2. Никакие абсолютные временные характеристики (латентность, времена переключения и т.п.) к реалтаймовости не имеют никакого минимального касательства - это вопросы масштаба времени. Возьмите процессор в 10 раз быстрее - и наслаждайтесь в 10 раз меньшей латентностью. Так что "реалтайм" - термин (не очень определённый) скорее из области надёжности и безотказности системы, а не из области временных характеристик.


Согласен. Правда, при этом я за всю свою жизнь так ни разу и не встретил внятного определения, что же такое "реалтаймовость".

Цитата(Olej @ Oct 1 2012, 14:47) *
3. К области логических автоматов в промышленных управляющих системах, к языкам МЭК 61131-3 ... и Рефлекс - куда склоняет разговор Зюбин В.Е. biggrin.gif - терминология реалтайм неприменима ни в каком смысле, ни в положительном, но в отрицательном. Это совершенно другие вещи. Здесь логика совершенно другая: идёт циклический поллинг N входных воздействий + никакая другая конкурирующая задача не может возникнуть на процессоре, если у вас даже процесс управления занимает 5% потенциальной производительности процессора PLC (из-за ошибки или жадности проектировщика), то никакая другая задача не станет использовать остающиеся 95%.


Ах, как сразу Вы меня вывели на чистую воду... :-) Точно! Правда, меня сейчас больше интересует ни ПЛК, а задачи "малой" автоматизации и встраиваемых систем, средствами дешевых открытых платформ, типа Arduino...
Кстати, насчет 5% утилизации ресурсов Вы не совсем правы. Существует решение, исключающее простой в ожидании синхронизующего события от таймера. В каких-то случаях это может быть и полезно... не очень пока понятно в каких, правда... поскольку, чего мне пока не приходилось встречать на практике, так это нехватки ресурсов для обеспечения требуемого времени реакции системы на внешнее событие.

Цитата(Olej @ Oct 1 2012, 14:47) *
4. Т.е. реалтаймовая терминология воообще применима только к системам общего применения с асинхронно возникающими задачами, или пиковыми всплесками потребности производительности... В том числе, достаточно часто эти пиковые всплески могут происходить как следствие активности человека-оператора. Или в серверных системах массового обслуживания, в тех, которые представляют максимально популярные сейчас "облачные" сервисы. И алгоритмика "разруливания" запросов конкурирующих процессов (дисциплина диспетчеризации) может быть для обеспечения реалтайм (RT OS) и весьма замысловатой (POSIX 1003.b: спорадическая, адаптивная, ...) и уж заведомо отличающейся от дисциплины диспетчеризации системы общего использования (GP OS)


Да, конечно, в системах массового обслуживания нужны ОС. Правда, при чем тут "реалтаймовость" так и непонятно... Я тут с удивлением узнал, что Widows 8 будет предоставлять возможность запускать Word в "облаке"... я до сих пор нахожусь в недоумении, не в силах представить работу с 100+ Мегабайтовыми docm-файлами...

Цитата(Olej @ Oct 1 2012, 14:47) *
5. Интересно, в смысле иллюстрации, в этом смысле современная (раньше было по-другому) структура сетевого стека Linux:
- здесь ведь только 1-й пакет "сетевой пачки" принимается по IRQ ...
- дальше модуль сетевого устройства переходит к программному поллингу всех последующих пакетов ...
- до тех пор, пока интенсивность "сетевого всплеска" не упадёт, и можно снова уйти на ожидание по IRQ.
Подробней см.: Модули ядра Linux.


А почему бы и нет? Linux добротная операционная система (жаль только без продуманного WIMP интерфейса), цель которой обеспечивать взаимное уживание приложений от сотен и тысяч разных разработчиков... дополнительный уровень абстракции, обеспечивающий строгую культуру "общежития" приложения (да и аппаратуры тоже).
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.