Цитата(_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/polling3. Устройство ПО управляющих цифровых систем, как я понимаю, обычно строится по стандартной циклической схеме, используемой в тех же ПЛК, состоящей из трех процедур: "чтение входных данных" -> "обработка" -> "запись выходных данных"... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная.
Цитата(_Pasha @ Sep 30 2012, 22:51)

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

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

Я так понял, под "аларм-лист" предлагается заводить что-то типа списка чисел (а может, и еще чего-то), которые требуется загружать в компаратор после каждого прерывания... только я не понял, зачем так сложно? И почему разбросав этот "аларм-лист" по нескольким таймерам получится какой-то выигрыш? Прерывания будут следовать ровно с той же частотой, используете вы один таймер, или 100.
Предлагаю пред обсуждением по существу все-таки немного поговорить по терминологии, начав к примеру с круга решаемых задач и используемых аппаратных платформ.
Например, ограничиться Arduino и задачами "малой" автоматизации (управляющими алгоритмами, использующими исключительно периферию Arduino).
Цитата(Olej @ Oct 1 2012, 14:47)

Просто в разговоре, который "простёрся" на 24 стр. обсуждения и растянулся на 6 лет

смешались в кучу примеры и представления из совершенно разных областей применения :
Да, вполне возможно, в этом и проблема взаимонепонимания, надеюсь, проблема решается, когда мы сделаем необходимые уточнения по областям применения и используемым аппаратным платформам.
Цитата(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 ... и Рефлекс - куда склоняет разговор Зюбин В.Е.

- терминология реалтайм неприменима ни в каком смысле, ни в положительном, но в отрицательном. Это совершенно другие вещи. Здесь логика совершенно другая: идёт циклический поллинг 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 интерфейса), цель которой обеспечивать взаимное уживание приложений от сотен и тысяч разных разработчиков... дополнительный уровень абстракции, обеспечивающий строгую культуру "общежития" приложения (да и аппаратуры тоже).