_Pasha 0 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Ваша система рано или поздно "наткнется" на ограничение, т.к. все данные (а в реальности они все параллельные) нужно прокачать сквозь узенькое игольное ушко - счетчик адреса контроллера. Это так называемый функциональный предел. Дальше никуда. То Талллинна талекооо :) Тут игольных ушек и других хватает: интерфейсы\ протоколы связи с внешним железом Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Я тоже плохо понимаю ваш вопрос. "У задачи есть переменная..." это я понял, а вот "События, которых задача ожидает, задаются в самой задаче".. уже, увы, не понял... записывает в эту переменную код события? а дальше? в общем, теряюсь в догадках... В общем, прошу прощения... У меня нет вопроса. А ответ есть. На сайте Keil что-то не находится, придется выдать из личных запасов. Рекомендую проштудировать часть про RTX. rl_arm_gs___Building_Applications_with_RL_ARM.pdf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Ядерщики первыми начали пользовать ПЛИСы для своих нужд - думаю на сегодня это одно из наиболее перспективных решений по работе со сложными системами. А Windows 7 - сложная система? Каждому - свое. Лично я использую и то, и другое. Одновременно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Совершенно согласен с вашими рассуждениями... я тоже не представляю какого-то рационального решения при попытке переноса обработки событий на уровень ОС (я так понимаю, под "реалтаймовостью" подразумевается использование ОС)... Просто в разговоре, который "простёрся" на 24 стр. обсуждения и растянулся на 6 лет :rolleyes: смешались в кучу примеры и представления из совершенно разных областей применения : 1. До тех пор, пока не нужна приоритетная многозадачность ни о какой ОС РВ разговаривать нет смысла вообще ... нет конкурентной многозадачности - и всё само собой и так становится "реалтайм", в этом смысле можете считать MS-DOS ОС РВ, и будете в значительной степени правы. 2. Никакие абсолютные временные характеристики (латентность, времена переключения и т.п.) к реалтаймовости не имеют никакого минимального касательства - это вопросы масштаба времени. Возьмите процессор в 10 раз быстрее - и наслаждайтесь в 10 раз меньшей латентностью. Так что "реалтайм" - термин (не очень определённый) скорее из области надёжности и безотказности системы, а не из области временных характеристик. 3. К области логических автоматов в промышленных управляющих системах, к языкам МЭК 61131-3 ... и Рефлекс - куда склоняет разговор Зюбин В.Е. - терминология реалтайм неприменима ни в каком смысле, ни в положительном, но в отрицательном. Это совершенно другие вещи. Здесь логика совершенно другая: идёт циклический поллинг N входных воздействий + никакая другая конкурирующая задача не может возникнуть на процессоре, если у вас даже процесс управления занимает 5% потенциальной производительности процессора PLC (из-за ошибки или жадности проектировщика), то никакая другая задача не станет использовать остающиеся 95%. 4. Т.е. реалтаймовая терминология воообще применима только к системам общего применения с асинхронно возникающими задачами, или пиковыми всплесками потребности производительности... В том числе, достаточно часто эти пиковые всплески могут происходить как следствие активности человека-оператора. Или в серверных системах массового обслуживания, в тех, которые представляют максимально популярные сейчас "облачные" сервисы. И алгоритмика "разруливания" запросов конкурирующих процессов (дисциплина диспетчеризации) может быть для обеспечения реалтайм (RT OS) и весьма замысловатой (POSIX 1003.b: спорадическая, адаптивная, ...) и уж заведомо отличающейся от дисциплины диспетчеризации системы общего использования (GP OS) 5. Интересно, в смысле иллюстрации, в этом смысле современная (раньше было по-другому) структура сетевого стека Linux: - здесь ведь только 1-й пакет "сетевой пачки" принимается по IRQ ... - дальше модуль сетевого устройства переходит к программному поллингу всех последующих пакетов ... - до тех пор, пока интенсивность "сетевого всплеска" не упадёт, и можно снова уйти на ожидание по IRQ. Подробней см.: Модули ядра Linux. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Владимир Е. Зюбин 0 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Допустим, какой-либо процесс 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. Устройство ПО управляющих цифровых систем, как я понимаю, обычно строится по стандартной циклической схеме, используемой в тех же ПЛК, состоящей из трех процедур: "чтение входных данных" -> "обработка" -> "запись выходных данных"... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная. Это опять же диалектика проявляется: (проверка события+реакция в одном потоке) vs (отправитель - получатель). Если нам выгоднее вторая форма, т.е. отдельные потоки - значит есть другие более веские факторы. Например, поток обрабатывает пакеты какого-л интерфейса и нам лучше его оформить так, чтобы он был вещью в себе - и работал на нескольких разнотипных устройствах. А можно привести пример? Я с интерфейсами и разнотипными устройствами не понял. Вас можно так понять, что Вы пишете модули, которые абстрагируют UARTы и Ethernet-сокеты... Про контроль равномерности. Например, у нас есть несколько свободных таймеров с функцией компаратора и соответствующего прерывания. Тогда проще разбросать аларм-лист по всем ресурсам равномерно, чем делать одну длиннющую очередь и довольно часто обслуживать ее, перезагружая компаратор в прерывании. Во втором случае, конечно, универсальнее - "безобразно, зато единообразно" :) Я так понял, под "аларм-лист" предлагается заводить что-то типа списка чисел (а может, и еще чего-то), которые требуется загружать в компаратор после каждого прерывания... только я не понял, зачем так сложно? И почему разбросав этот "аларм-лист" по нескольким таймерам получится какой-то выигрыш? Прерывания будут следовать ровно с той же частотой, используете вы один таймер, или 100. Предлагаю пред обсуждением по существу все-таки немного поговорить по терминологии, начав к примеру с круга решаемых задач и используемых аппаратных платформ. Например, ограничиться Arduino и задачами "малой" автоматизации (управляющими алгоритмами, использующими исключительно периферию Arduino). Просто в разговоре, который "простёрся" на 24 стр. обсуждения и растянулся на 6 лет :rolleyes: смешались в кучу примеры и представления из совершенно разных областей применения : Да, вполне возможно, в этом и проблема взаимонепонимания, надеюсь, проблема решается, когда мы сделаем необходимые уточнения по областям применения и используемым аппаратным платформам. 1. До тех пор, пока не нужна приоритетная многозадачность ни о какой ОС РВ разговаривать нет смысла вообще ... нет конкурентной многозадачности - и всё само собой и так становится "реалтайм", в этом смысле можете считать MS-DOS ОС РВ, и будете в значительной степени правы. Мне кажется, что "приоритетная многозадачность" это просто некоторое средство для решения некоторой проблемы. Мне понятно, зачем она нужна под Windows 7, и вообще зачем нужна многозадачная ОС для компьютеров общего назначения, тоже понятно... но зачем она нужна, например, для платформы Arduino, мне понять уже трудно... 2. Никакие абсолютные временные характеристики (латентность, времена переключения и т.п.) к реалтаймовости не имеют никакого минимального касательства - это вопросы масштаба времени. Возьмите процессор в 10 раз быстрее - и наслаждайтесь в 10 раз меньшей латентностью. Так что "реалтайм" - термин (не очень определённый) скорее из области надёжности и безотказности системы, а не из области временных характеристик. Согласен. Правда, при этом я за всю свою жизнь так ни разу и не встретил внятного определения, что же такое "реалтаймовость". 3. К области логических автоматов в промышленных управляющих системах, к языкам МЭК 61131-3 ... и Рефлекс - куда склоняет разговор Зюбин В.Е. - терминология реалтайм неприменима ни в каком смысле, ни в положительном, но в отрицательном. Это совершенно другие вещи. Здесь логика совершенно другая: идёт циклический поллинг N входных воздействий + никакая другая конкурирующая задача не может возникнуть на процессоре, если у вас даже процесс управления занимает 5% потенциальной производительности процессора PLC (из-за ошибки или жадности проектировщика), то никакая другая задача не станет использовать остающиеся 95%. Ах, как сразу Вы меня вывели на чистую воду... :-) Точно! Правда, меня сейчас больше интересует ни ПЛК, а задачи "малой" автоматизации и встраиваемых систем, средствами дешевых открытых платформ, типа Arduino... Кстати, насчет 5% утилизации ресурсов Вы не совсем правы. Существует решение, исключающее простой в ожидании синхронизующего события от таймера. В каких-то случаях это может быть и полезно... не очень пока понятно в каких, правда... поскольку, чего мне пока не приходилось встречать на практике, так это нехватки ресурсов для обеспечения требуемого времени реакции системы на внешнее событие. 4. Т.е. реалтаймовая терминология воообще применима только к системам общего применения с асинхронно возникающими задачами, или пиковыми всплесками потребности производительности... В том числе, достаточно часто эти пиковые всплески могут происходить как следствие активности человека-оператора. Или в серверных системах массового обслуживания, в тех, которые представляют максимально популярные сейчас "облачные" сервисы. И алгоритмика "разруливания" запросов конкурирующих процессов (дисциплина диспетчеризации) может быть для обеспечения реалтайм (RT OS) и весьма замысловатой (POSIX 1003.b: спорадическая, адаптивная, ...) и уж заведомо отличающейся от дисциплины диспетчеризации системы общего использования (GP OS) Да, конечно, в системах массового обслуживания нужны ОС. Правда, при чем тут "реалтаймовость" так и непонятно... Я тут с удивлением узнал, что Widows 8 будет предоставлять возможность запускать Word в "облаке"... я до сих пор нахожусь в недоумении, не в силах представить работу с 100+ Мегабайтовыми docm-файлами... 5. Интересно, в смысле иллюстрации, в этом смысле современная (раньше было по-другому) структура сетевого стека Linux: - здесь ведь только 1-й пакет "сетевой пачки" принимается по IRQ ... - дальше модуль сетевого устройства переходит к программному поллингу всех последующих пакетов ... - до тех пор, пока интенсивность "сетевого всплеска" не упадёт, и можно снова уйти на ожидание по IRQ. Подробней см.: Модули ядра Linux. А почему бы и нет? Linux добротная операционная система (жаль только без продуманного WIMP интерфейса), цель которой обеспечивать взаимное уживание приложений от сотен и тысяч разных разработчиков... дополнительный уровень абстракции, обеспечивающий строгую культуру "общежития" приложения (да и аппаратуры тоже). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба тяжело общаться, когда нет единого языка... ... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная. Уже несколько раз звучит это утверждение и от разных авторов. Поллинг это: - циклический (повторяющийся) программный опрос... - идущий от POSIX poll() ... но, скорее, "срываемый" по истечению таймаута периода ожидания, - т.е. "синхронный"(с). Если кто-то имеет в виду что-то другое, то называйте его по-другому. :rolleyes: Предлагаю пред обсуждением по существу все-таки немного поговорить по терминологии, начав к примеру с круга решаемых задач и используемых аппаратных платформ. Например, ограничиться Arduino и задачами "малой" автоматизации (управляющими алгоритмами, использующими исключительно периферию Arduino). ... Мне кажется, что "приоритетная многозадачность" это просто некоторое средство для решения некоторой проблемы. Мне понятно, зачем она нужна под Windows 7, и вообще зачем нужна многозадачная ОС для компьютеров общего назначения, тоже понятно... но зачем она нужна, например, для платформы Arduino, мне понять уже трудно... В теме обсуждения нигде не было заявлено такого ключевого слова как Arduino :bb-offtopic: Да и на "малой" автоматизации"(с) никто особенно не акцентировался... Это может быть, но отдельная совсем, и более конкретная тема. Согласен. Правда, при этом я за всю свою жизнь так ни разу и не встретил внятного определения, что же такое "реалтаймовость". Ну здесь вы лукавите... я, как помнится, не на одном обсуждении с вами пересекался, и всё вы прекрасно встречали Тот же стандарт POSIX даёт определения ... и его расширения POSIX 1003.b ... и ещё др. близкие расширения (см. http://rus-linux.net/forum/viewtopic.php?f=18&t=1542). Вполне достаточно самой традиционной формулировки: детерминированное поведение - возможность обеспечения реакции в гарантированно заранее определённое максимальное время реакции... уложитесь ли вы в заказанный (завышенный) интервал, но с гарантией 100% из 100 млн. тестовых случаев. Для синхронных PLC это неактуально - "масло маслянное", поэтому и не воспринимается. Для многозадачных конкурентных ОС с приоритетами - очень даже актуально. Возьмите к рассмотрению, например, ситуацию инверсии приоритетов (на любом примитиве синхронизации ... на мютексе, к примеру) для 3-х разноприориетных процессов/потоков - здесь в традиционных WIndows, и даже Linux время реакции может затянуться ... и до бесконечности :santa2: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Владимир Е. Зюбин 0 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Уже несколько раз звучит это утверждение и от разных авторов. Поллинг это: - циклический (повторяющийся) программный опрос... - идущий от POSIX poll() ... но, скорее, "срываемый" по истечению таймаута периода ожидания, - т.е. "синхронный"(с). Если кто-то имеет в виду что-то другое, то называйте его по-другому. :rolleyes: Теперь стало понятно, что под поллингом подразумевается в POSIX, это вполне сочетается с моим пониманием, но проблема в том, что это не единственное определение поллинга. Поэтому, как мне представляется, это слово лучше вообще не употреблять. В теме обсуждения нигде не было заявлено такого ключевого слова как Arduino :bb-offtopic: Да и на "малой" автоматизации"(с) никто особенно не акцентировался... Это может быть, но отдельная совсем, и более конкретная тема. Как я понимаю, в этой ветке обсуждаются условия, при которых ОС использовать неэффективно. Вариант Arduino это одно из возможных условий... Чего-то я определенно не понимаю... например, о каких ключевых словах Вы говорите... где они вообще? Ну здесь вы лукавите... я, как помнится, не на одном обсуждении с вами пересекался, и всё вы прекрасно встречали Тот же стандарт POSIX даёт определения ... и его расширения POSIX 1003.b ... и ещё др. близкие расширения (см. http://rus-linux.net/forum/viewtopic.php?f=18&t=1542). Увы, я встречал только попытки дать определения... К слову, по Вашей ссылке никаких определений я не обнаружил... и вообще про "реальное время" там только Ваша загадочная (для меня) фраза: http://www.intuit.ru/department/se/posix2/ - а это расширения реального времени POSIX, и здесь вообще - "тёмный лес"... где это более-менее внятно реализовано - это только OS QNX 6.x Вполне достаточно самой традиционной формулировки: детерминированное поведение - возможность обеспечения реакции в гарантированно заранее определённое максимальное время реакции... уложитесь ли вы в заказанный (завышенный) интервал, но с гарантией 100% из 100 млн. тестовых случаев. То, о чем Вы говорите, называется определение WCET... погуглите по фразе "worst case execution time"... Для синхронных PLC это неактуально - "масло маслянное", поэтому и не воспринимается. Для многозадачных конкурентных ОС с приоритетами - очень даже актуально. Возьмите к рассмотрению, например, ситуацию инверсии приоритетов (на любом примитиве синхронизации ... на мютексе, к примеру) для 3-х разноприориетных процессов/потоков - здесь в традиционных WIndows, и даже Linux время реакции может затянуться ... и до бесконечности :santa2: В общем-то согласен, неактуально, даже скажу почему: потому, что там нет никаких мьютексов, семафоров и приоритетов, а, значит, конструктивно исключены инверсии приоритетов, дед-локи и прочие мексиканские узлы... ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 1 октября, 2012 Опубликовано 1 октября, 2012 · Жалоба Увы, я встречал только попытки дать определения... К слову, по Вашей ссылке никаких определений я не обнаружил... и вообще про "реальное время" там только Ваша загадочная (для меня) фраза: По моей ссылке можно выйти на оригинальные тексты самих стандартов POSIX ... которые многие обсуждают, но мало кто видел в глаза. Я давал ссылку только с этой целью. Как я понимаю, в этой ветке обсуждаются условия, при которых ОС использовать неэффективно. Вариант Arduino это одно из возможных условий... Чего-то я определенно не понимаю... например, о каких ключевых словах Вы говорите... где они вообще? Ну, в общем, да... Даже более того: "условия, при которых ОС РВ использовать неэффективно" - такая вот инверсная формулировка. Только областей, где использование РВ нецелесообразно, их очень много ... начиная с элементарной десктоп рабочей станции: - запустите в Linux процесс с "реалтайм" диспетчеризацией - и убедитесь, что это делает привычный Linux неудобным для работы. P.S. вот здесь есть примеры (кода) того, как это сделать: параллельность + синхронизации (примеры). Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Владимир Е. Зюбин 0 2 октября, 2012 Опубликовано 2 октября, 2012 · Жалоба По моей ссылке можно выйти на оригинальные тексты самих стандартов POSIX ... которые многие обсуждают, но мало кто видел в глаза. Я давал ссылку только с этой целью. Так. Раньше было "ОС РВ -- это QNX"(или что-то такое), теперь уже "ОС РВ -- это стандарты POSIX..." В принципе, достаточно конструктивно, только я бы не концентрировался на POSIX. Как Вам такое определение: "ОС РВ -- это ОС с планировщиком задачи", или просто "многозадачная ОС"? Тогда и тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет. Или, другими словами, в каких задачах нам нужен многозадачный параллелизм, а в каких многопоточный. И сразу к ответу приблизимся. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 2 октября, 2012 Опубликовано 2 октября, 2012 · Жалоба Так. Раньше было "ОС РВ -- это 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. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 9 3 октября, 2012 Опубликовано 3 октября, 2012 (изменено) · Жалоба У POSIX есть несколько последовательных расширений реального времени: POSIX 1003.b, POSIX 1003.g и др. (это именно более поздние расширения, а не тело основного стандарта). Именно в них закладываются требования. ... - не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: FIFO, RoundRobin, Sporadic, ... - из-за этого требования никогда ни Windows ни Linux не станут RT, сколько их не расширяй... А Вы ничего не путаете ? man sched_setscheduler The following "real-time" policies are also supported, for special time-critical applications that need precise control over the way in which runnable processes are selected for execution: SCHED_FIFO a first-in, first-out policy; and SCHED_RR a round-robin policy. ... Processes scheduled under one of the real-time policies (SCHED_FIFO, SCHED_RR) have a sched_priority value in the range 1 (low) to 99 (high). (As the numbers imply, real-time processes always have higher priority than normal processes.) Note well: POSIX.1-2001 only requires an implementation to support a minimum 32 distinct priority levels for the real-time policies ну и все остальные атрибуты описанные выше тоже присутствуют FAQ Изменено 3 октября, 2012 пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 3 октября, 2012 Опубликовано 3 октября, 2012 · Жалоба А Вы ничего не путаете ? man sched_setscheduler Нет, я как-раз абсолютно ничего не путаю. Вы решили нас man-ом от Linux удивить? :cranky: ... который "ни сном ни духом" рядом с 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: колхоз есть колхоз, и не нужно всё на веру принимать, что колхозом писано ). не читайте большевистские газеты перед едой :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 3 октября, 2012 Опубликовано 3 октября, 2012 · Жалоба И не нужно о realtime познания черпать в man-ах, faq-ах и прочей Linux писанине :laughing: Это точно. Линуксоиды - самая читающая нация в мире :) блин, по нескольку сотен экранов мана за неделю - это неприятно даже с учетом того, что по диагонали. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 9 3 октября, 2012 Опубликовано 3 октября, 2012 (изменено) · Жалоба вот здесь "быстрый дистрибутив" возьмите за основу тесты средней температуры по больнице :cranky: если беретесь тестировать и публиковать результаты - огласите на чем тестируется диспетчирование реального времени не оставляет ни одного кванта задачам более низкого приоритета! с какого перепуга RT задача которая выполняется на одном процессоре должна заблокировать другую не пересекающуюся по ресурсам на другом процессоре ? это ва не DOS который вы считаете realtime os :1111493779: простейшая программа xxx типа: Код: while( 1 ) {}; - запущенная с одним из этих SCHED_* и повышенным относительно среднего (дефаултного) приоритетом: # nice -n-19 xxx - должна "забивать" терминал (или консоль) и его клавиатуру, т.е. делать систему непригодной "вы не поверите !" (с) # uname -a Linux buildroot 3.2.30-rt45 #31 PREEMPT RT Wed Oct 3 22:39:53 MSK 2012 armv5tejl GNU/Linux # ./tst & # ps PID USER COMMAND 1 root init 2 root [kthreadd] 3 root [ksoftirqd/0] 4 root [kworker/0:0] 5 root [kworker/u:0] 6 root [posixcputmr/0] 7 root [khelper] 8 root [kdevtmpfs] 9 root [kworker/u:1] 169 root [sync_supers] 171 root [bdi-default] 172 root [kblockd] 174 root [irq/21-at_hdmac] 194 root [khubd] 290 root [rpciod] 291 root [kworker/0:1] 296 root [kswapd0] 297 root [fsnotify_mark] 298 root [nfsiod] 299 root [crypto] 307 root [irq/23-atmel_lc] 357 root [spi_gpio.3] 366 root [irq/25-eth%d] 381 root [irq/22-ehci_hcd] 385 root [irq/22-ohci_hcd] 393 root [kpsmoused] 396 root [irq/149-ads7846] 401 root [irq/1-at91_rtc] 408 root [irq/26-isi] 420 root [irq/24-AC97C] 434 root [irq/11-atmel_mc] 436 root [irq/127-mmc-det] 437 root [irq/29-atmel_mc] 438 root [kworker/u:2] 440 root [irq/140-mmc-det] 442 root [irq/1-ttyS0] 444 root [mmcqd/0] 451 root [flush-179:0] 459 root /sbin/syslogd -m 0 461 root /sbin/klogd 493 root -sh 502 root ./tst 503 root ps # chrt -pf 99 502 pid 502's <--- консоль висит Изменено 3 октября, 2012 пользователем sasamy Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vshemm 0 3 октября, 2012 Опубликовано 3 октября, 2012 · Жалоба Вполне достаточно самой традиционной формулировки: детерминированное поведение - возможность обеспечения реакции в гарантированно заранее определённое максимальное время реакции... уложитесь ли вы в заказанный (завышенный) интервал, но с гарантией 100% из 100 млн. тестовых случаев. Традиционная феерическая формулировка, да. Объясните, пожалуйста, почему именно 100млн. тестовых случаев дают 100% гарантию и детерминированность? Может, хватит 99млн? Или все-таки нужно 101млн? Ну, этого явно недостаточно. К этому нужно добавить: - вытесняющий планировщик (не кооперативный)... ну, это зачастую выполняется, но была же такая многозадачная ОС как Windows 3.11? - приоритетное планирование ... и желательно этих приоритетов поболее: 64, а лучше 256 - не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: FIFO, RoundRobin, Sporadic, ... - из-за этого требования никогда ни Windows ни Linux не станут RT, сколько их не расширяй... - должны быть приняты меры в планировщике против инверсии приоритетов - на примитивах синхронизации: наследование приоритетов, или граничные приоритеты. Вот только тогда такая "многозадачная ОС"(с) может претендовать на RT. В ванильном ядре все это есть, но он ""ни сном ни духом" рядом с RT не лежал..." - противоречие. P.S. показательно в этом смысле то, что в микроядерных ОС (QNX), когда ядро имеет всего порядка 100 системных вызовов (вместо тысяч в WIndows или Linux), то все функции потоков вида pthread_*() - так или иначе отображаются в системные вызовы (int 21h), а всё, что относится к процессам - не отображается; т.е. в микроядре содержатся приоритетные очереди потоков, но относительно процессов микроядро вообще ничего не знает. Явная деза, возможно даже сознательная. В Neutrino ~130 системных вызовов, в Linux и Windows (NT) - ~350 и ~450 соответственно. Занижение на 30% в одном случае и завышение на порядок в других действительно показательно. А отображение такое потому, что шедулер входит в состав микроядра, а менеджеры процессов и памяти - нет (хотя без них микроядро не работает). Нет, я как-раз абсолютно ничего не путаю. Вы решили нас man-ом от Linux удивить? :cranky: ... который "ни сном ни духом" рядом с RT не лежал... Так называемые "реалтайм" дисциплины SCHED_FIFO & SCHED_RR в Linux присутсвуют ... давно, но более RT они его от этого не делают. SCHED_FIFO & SCHED_RR в Linux это только дисциплины, сделанные чтоб "похоже как у людей в realtime", но никакого отношения к самому realtime они не имеют. Напишите и запустите FIFO/RR приложение в Linux и наблюдайте что из этого получится... (не хочется писать - вот здесь "быстрый дистрибутив" возьмите за основу) ... посмтрите как "умирают" другие процессы (GUI) в системе, потому что они никогда не получат процессорного времени, пока активны SCHED_FIFO & SCHED_RR. Может, так и надо? Раз GUI процесс имеет более низкий приоритет (а он имеет более низкий) чем процесс на SCHED_FIFO или SCHED_RR дисциплине, он и не должен получать процессорного времени данного CPU. Ох, зря вы пренебрегаете манами и документацией... Поэтому Linux - это Linux, а realtime - это realtime. И не нужно о realtime познания черпать в man-ах, faq-ах и прочей Linux писанине (при всём уважении к Linux community: колхоз есть колхоз, и не нужно всё на веру принимать, что колхозом писано ). Учитывая что 70+% кода разрабатывается людьми из всяких Интелов, ИБМов, Редхетов и прочих Новелов на зарплате, неплохой колхоз получается :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
