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

Если кто-то имеет в виду что-то другое, то называйте его по-другому.


В теме обсуждения нигде не было заявлено такого ключевого слова как Arduino
Да и на "малой" автоматизации"(с) никто особенно не акцентировался...

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




Ну здесь вы лукавите... я, как помнится, не на одном обсуждении с вами пересекался, и всё вы прекрасно встречали
Тот же стандарт POSIX даёт определения ... и его расширения POSIX 1003.b ... и ещё др. близкие расширения (см. http://rus-linux.net/forum/viewtopic.php?f=18&t=1542).

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

Для синхронных PLC это неактуально - "масло маслянное", поэтому и не воспринимается.
Для многозадачных конкурентных ОС с приоритетами - очень даже актуально.
Возьмите к рассмотрению, например, ситуацию инверсии приоритетов (на любом примитиве синхронизации ... на мютексе, к примеру) для 3-х разноприориетных процессов/потоков - здесь в традиционных WIndows, и даже Linux время реакции может затянуться ... и до бесконечности

Теперь стало понятно, что под поллингом подразумевается в POSIX, это вполне сочетается с моим пониманием, но проблема в том, что это не единственное определение поллинга. Поэтому, как мне представляется, это слово лучше вообще не употреблять.



Как я понимаю, в этой ветке обсуждаются условия, при которых ОС использовать неэффективно. Вариант Arduino это одно из возможных условий... Чего-то я определенно не понимаю... например, о каких ключевых словах Вы говорите... где они вообще?



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



То, о чем Вы говорите, называется определение WCET... погуглите по фразе "worst case execution time"...



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

По моей ссылке можно выйти на оригинальные тексты самих стандартов POSIX ... которые многие обсуждают, но мало кто видел в глаза.
Я давал ссылку только с этой целью.




Ну, в общем, да...
Даже более того: "условия, при которых ОС РВ использовать неэффективно" - такая вот инверсная формулировка.
Только областей, где использование РВ нецелесообразно, их очень много ... начиная с элементарной десктоп рабочей станции:
- запустите в Linux процесс с "реалтайм" диспетчеризацией
- и убедитесь, что это делает привычный Linux неудобным для работы.

P.S. вот здесь есть примеры (кода) того, как это сделать: параллельность + синхронизации (примеры).

Так. Раньше было "ОС РВ -- это QNX"(или что-то такое), теперь уже "ОС РВ -- это стандарты POSIX..."
В принципе, достаточно конструктивно, только я бы не концентрировался на POSIX.
Как Вам такое определение: "ОС РВ -- это ОС с планировщиком задачи", или просто "многозадачная ОС"?

Тогда и тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет. Или, другими словами, в каких задачах нам нужен многозадачный параллелизм, а в каких многопоточный.

И сразу к ответу приблизимся.

У POSIX есть несколько последовательных расширений реального времени: POSIX 1003.b, POSIX 1003.g и др. (это именно более поздние расширения, а не тело основного стандарта).
Именно в них закладываются требования.




Ну, этого явно недостаточно. К этому нужно добавить:
- вытесняющий планировщик (не кооперативный)... ну, это зачастую выполняется, но была же такая многозадачная ОС как Windows 3.11?
- приоритетное планирование ... и желательно этих приоритетов поболее: 64, а лучше 256
- не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: FIFO, RoundRobin, Sporadic, ... - из-за этого требования никогда ни Windows ни Linux не станут RT, сколько их не расширяй...
- должны быть приняты меры в планировщике против инверсии приоритетов - на примитивах синхронизации: наследование приоритетов, или граничные приоритеты.

Вот только тогда такая "многозадачная ОС"(с) может претендовать на RT.




1. Вообще то, планирование в многозадачной ОС относится всегда к потокам, и никогда к процессам. Когда (для упрощения) говорят о планировании процессов, то неявно имеется в виду всё равно процесс планирования главного (и единственного - main) потока этого процесса.

P.S. показательно в этом смысле то, что в микроядерных ОС (QNX), когда ядро имеет всего порядка 100 системных вызовов (вместо тысяч в WIndows или Linux), то все функции потоков вида pthread_*() - так или иначе отображаются в системные вызовы (int 21h), а всё, что относится к процессам - не отображается; т.е. в микроядре содержатся приоритетные очереди потоков, но относительно процессов микроядро вообще ничего не знает.

2. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению.

А Вы ничего не путаете ? man sched_setscheduler


ну и все остальные атрибуты описанные выше тоже присутствуют FAQ

Нет, я как-раз абсолютно ничего не путаю.

Вы решили нас man-ом от Linux удивить? ... который "ни сном ни духом" рядом с RT не лежал...

Так называемые "реалтайм" дисциплины SCHED_FIFO & SCHED_RR в Linux присутсвуют ... давно, но более RT они его от этого не делают.
SCHED_FIFO & SCHED_RR в Linux это только дисциплины, сделанные чтоб "похоже как у людей в realtime", но никакого отношения к самому realtime они не имеют.
Напишите и запустите FIFO/RR приложение в Linux и наблюдайте что из этого получится... (не хочется писать - вот здесь "быстрый дистрибутив" возьмите за основу) ... посмтрите как "умирают" другие процессы (GUI) в системе, потому что они никогда не получат процессорного времени, пока активны SCHED_FIFO & SCHED_RR.

Поэтому Linux - это Linux, а realtime - это realtime.
И не нужно о realtime познания черпать в man-ах, faq-ах и прочей Linux писанине (при всём уважении к Linux community: колхоз есть колхоз, и не нужно всё на веру принимать, что колхозом писано ).

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

тесты средней температуры по больнице если беретесь тестировать и публиковать результаты - огласите на чем тестируется



с какого перепуга RT задача которая выполняется на одном процессоре должна заблокировать другую не пересекающуюся по ресурсам на другом процессоре ? это ва не DOS который вы считаете realtime os



"вы не поверите !" (с)

Традиционная феерическая формулировка, да. Объясните, пожалуйста, почему именно 100млн. тестовых случаев дают 100% гарантию и детерминированность? Может, хватит 99млн? Или все-таки нужно 101млн?



В ванильном ядре все это есть, но он ""ни сном ни духом" рядом с RT не лежал..." - противоречие.



Явная деза, возможно даже сознательная. В Neutrino ~130 системных вызовов, в Linux и Windows (NT) - ~350 и ~450 соответственно. Занижение на 30% в одном случае и завышение на порядок в других действительно показательно. А отображение такое потому, что шедулер входит в состав микроядра, а менеджеры процессов и памяти - нет (хотя без них микроядро не работает).



Может, так и надо? Раз GUI процесс имеет более низкий приоритет (а он имеет более низкий) чем процесс на SCHED_FIFO или SCHED_RR дисциплине, он и не должен получать процессорного времени данного CPU. Ох, зря вы пренебрегаете манами и документацией...



Учитывая что 70+% кода разрабатывается людьми из всяких Интелов, ИБМов, Редхетов и прочих Новелов на зарплате, неплохой колхоз получается

Я просто не рассчитывал на настолько тупых читателей, которых нужно предупреждать, что если у них N процессоров, то чтобы их заблокировать нужно N экземпляров RT задачи .




Вас не учили в начальной школе разнице между необходимыми и достаточными условиями?

Или вы решили грудью постоять за реалтаймовость "ванильного ядра" Linux?


В Neutrino каком?
А в QNX 4.25 их порядка 60.
Ну и что?


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


Так именно и надо.
В RT OS.
А в GP OS (которыми и являются Windows, Linux, ...) его пользователи за такое удовольствие пошлют на хер разработчиков этой OS.
И поэтому не желающие отправляться на хер, эти разработчики во всех этих (GP) OS вынуждены прибегать к использованию хитроумного шедулирования, с динамическими управлением приоритетами или квантами времени...
Что, напротив, совершенно неприемлемо в RT OS.

Вот такое вот кино получается...

а мне кажется писатель сам об этом подумал только после того как написал





что и произошло с QNX, ггг. При наличии многоядерных процессоров недореалтайм + тормоза никому не нужны - разделение ресурсов на уровне гипервизора и вот вам тру реалтайм (хоть в виде bare metal хоть маленькая RTOS) + быстрая бесплатная GP OS + решение всех проблем с лицензиями типа GPL которые требуют открывать исходные коды.

Вот я и говорю, что ни человек, то свое мнение по поводу ОС РВ...

И как это во встраиваемых системах Виндовоз используют и Линукс... хоть кол им на голове чеши, не убедишь QNX изучить...

Кстати, "многозадачные ОС" это широко распространенный термин. Разночтений не вызывающий. В отличие от РВ, например, именно попытка определить ОС РВ испортило напрочь впечатление от весьма неплохого текста http://citforum.ru/operating_systems/sos/glava_3.shtml

Что же касается исходной темы, то как мне представляется, дело тут не в алгоритмах планирования (весьма неказистых, если судить по названиям: FIFO, RoundRobin и проч.), а именно в возможности поддерживать параллелизм на уровне задач, в наличии планировщика.



Имеется ввиду threads? какие еще потоки? thread в переводе с английского это нить, а не поток... единственно, что можно сказать по этому поводу, что англоязычная терминология не продумана, а русскоязычные пользователи при переводе еще больше запутали все дело... нет, чтобы просто сказать, main-thread (главная нить), как выделенная нить (thread)... так нет, вводятся какие-то процессы... а наши программисты thread еще как поток переводят... а как они "stream" переводят? Все это очень грустно...



Это не вопрос эквивалентности, а вопрос последовательности при постановке проблемы.

Ну, все-таки было бы логично сначала ответить на вопрос "а нужен ли планировщик вообще?"... и если вдруг окажется, что нужен, только тогда уже задаваться вопросом "а какой же планировщик тут нужен?"... С FIFO, RoundRobin-ом или с каким-нибудь действительно экзотическим алгоритмом планирования...

Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства.

Первоначальная постановка вопроса


и спор за 6 лет так и не утих и остался актуальным



Может этот путь будет оптимальным?

Так это ни о чём не говорит. Что там в этих системах управления - это тоже вопрос. Там этот windows может быть использовать чисто для GUI. Всё остальное аппаратно. Не думаю что в каком нибудь осциллографе винда считывает с ацп по одной выборке, складывает в ОЗУ, фильтрует, и выводит на экран. Наверняка захват и обработка сигнала аппаратно. винде остается тока считать кнопки, задать правильный режим аппаратуре и по готовности данных отобразить их на экране.

Раз уж Виктория кулаком пО столу...

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

По поводу "во встраиваемых системах" виндузей? Вкопирую прогноз фирмы IDC (http://rus-linux.net/forum/viewtopic.php?f=5&t=1856#p5226):

И это в массовых "балалайках" на непритязательного обывателя


По поводу мультимедии в ответственных управляющих системах - порадовало. Представилось:
- сидит где-то на нововоронежской АЭС оператор в ночную смену...
- и команду даёт голосом (мультимедиа!) для СУ: "Мурку давай"...
- а та ему в ответ наигрывает (мультимедиа!) "Мурку", чтоб не так грустно было ночь коротать...

Благостно. Лепота ...

Какой сочный батхерт Был по смежным вопросам на ПС 500 кВ "Радуга"
http://www.fsk-ees.ru/press_center/company...ELEMENT_ID=1046

так вот за визуальную часть мнемосхемы в составе SCADA там отвечала обычная Windows NT, какие еще ф-ции она выполняла не знаю - на тот момент система не была введена в эксплуатацию.

А как в многопоточном случае решается проблема использования общего ресурса (процессорного времени, доступ к данным, измеренным на объекте, общая память, сеть, etc)?
Сомневаюсь ещё, что для тысячи потоков достаточно стека в качестве механизма динамической памяти.

И вообще то 1000 потоков - где же такую задачу по ЦОС и измерительным делам сыскать? Это такой же финт в сторону, как Olej о Мурке и sasamy:


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

Ещё. По крайней мере, всегда при анализе вопроса при выборе OC всегда всплывал ещё один немаловажный качественный вопрос - требуется ли система жесткого реального времени или мягкого?

- в API POSIX 1003.b (вида pthread_*()) каждый поток имеет свой собственный стек (да и страшно представить, что было бы с системой при сбое только одного потока)...
- диспетчеризация делается на базисе потоков, а не процессов ... поэтому: что 1000 процессов, что 1000 потоков - в данном контексте это не важно
- термин процесс в этом смысле вообще избыточный, его не нужно привлекать ... если вы не желаете дополнительной путаницы, или называйте это процессами, или тасками (в однопоточных системах) - это всё с точки зрения диспетчеризации одно и то же.


Ну почему же
В технологии CUDA на GPU NVIDIA как-раз вполне может быть 1000 потоков, и как-раз на ЦОС (FFT).
Я сам делал 1000 потоков - сначала в виде экспериментов, а затем и в одном из реальных проектов с железом ... до сих пор проект крутится.


А нет никакого "мягкого" реального времени ... как "не бывает осетрины 2-й свежести"(с).
История вопроса:
- термин мягкого реального времени был введен Microsoft
- в то время, когда она изо всех сил тужилась сертифицировать Windows NT 3.51 (разрабатываемую системным отделом DEC) на (хоть куда, лишь бы сертифицировать!): а). POSIX-совместимость + б). на микроядерность + в). на риалтайм...
- когда их послали и с а). и с б). и с в). - накал страстей несколько упал ... а спекулятивная терминология осталась.

Есть такой мировой общепризнанный тестер - фирма Dedicated Systems (легко найдёте), так вот она выполняет изучение, и выпускает общедоступные объёмные отчёты...
В их отчётах (по состоянию дел 2-5 лет назад, сейчас не знаю) такие RT системы, как pSOS, QNX, VxWorks ... что-то там из RT-клонов Linux ...
Но никаких там "мягих" ... ни "микромягких", ни никаких других - там нет.
Не допускают их в эту компанию.

К сожалению, учили, поэтому парсер и ломается.
Еще раз, на определение "ОС РВ -- это ОС с планировщиком задачи" вы сказали, что этого недостаточно,
и выдвинули 4 требования, только после удовлетворения которых "Вот только тогда такая "многозадачная ОС"(с)
может претендовать на RT." Ванильное ядро всем этим требованиям удовлетворяет, следовательно, оно может
претендовать на RT (подчеркиваю, это не мое мнение, а прямое следствие ваших утверждений). Вот я и интересуюсь,
как на самом деле, может ванильное ядро претендовать на RT или оно рядом не лежит и вообще никогда не станет RT?
Или это нужно понимать как "претендовать-то оно может, но так как оно априори не RT, то неважно каким требованиям
оно будет удовлетворять - никогда оно RT не станет и не приблизится"?


Neutrino - это ядро шестерки, и от версии к версии их количество почти не менялось.
И то, что 1) системных вызовов в Windows и Linux не тысячи и 2) количество системных вызовов никакокого отношения
к шедулированию нитей а не процессов не имеет (во всех озвученных ОС шедулятся нити).



Опять парсер сломался. Вы утверждали, что linux (и windows) не обладают нужными дисциплинами планирования, а на
резонное замечание про SCHED_FIFO & SCHED_RR предложили запустить FIFO/RR приложение и посмотреть как криво оно
работает. Внезапно выясняется, что работает оно как надо, но т.к. linux является GP OS (видимо, априори), оно
все равно работает не так как надо(?). Странное кино получается...
Вопрос очень простой: удовлетворяют ли линуксовые SCHED_FIFO & SCHED_RR тому что имелось ввиду здесь:

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

P.S. На самый интересный вопрос про 100млн. тестовых запусков так и не ответили....

А дальше здесь начинается пустой словесный понос , и мне здесь более делать нечего
Я вам своё мнение достаточно высказал, времени на вас много перевёл ... а теперь вы можете: надувать щёки и обсуждать - обсуждать - обсуждать...

Т.е. по делу вам сказать нечего, что и требовалось доказать. И кого-то еще удивляет что данное "обсуждение"
не утихает уже 6 лет. Что ж, продолжайте в том же духе, всего доброго.

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

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

С уважением ко всем реальным и потенциальным участникам.