Olej 0 3 октября, 2012 Опубликовано 3 октября, 2012 · Жалоба с какого перепуга RT задача которая выполняется на одном процессоре должна заблокировать другую не пересекающуюся по ресурсам на другом процессоре ? это ва не DOS который вы считаете realtime os :1111493779: Я просто не рассчитывал на настолько тупых читателей, которых нужно предупреждать, что если у них N процессоров, то чтобы их заблокировать нужно N экземпляров RT задачи :1111493779: . В ванильном ядре все это есть, но он ""ни сном ни духом" рядом с RT не лежал..." - противоречие. Вас не учили в начальной школе разнице между необходимыми и достаточными условиями? Или вы решили грудью постоять за реалтаймовость "ванильного ядра" Linux? Явная деза, возможно даже сознательная. В Neutrino ~130 системных вызовов, в Linux и Windows (NT) - ~350 и ~450 соответственно. В Neutrino каком? А в QNX 4.25 их порядка 60. Ну и что? А отображение такое потому, что шедулер входит в состав микроядра, а менеджеры процессов и памяти - нет (хотя без них микроядро не работает). Ну так вы тем самым и подтверждаете именно то, что я и хотел сказать: процессы не имеют никакого касательства к шедулироваию. Ничего больше я и не имел в виду... ... и искренне благодарю вас за оказанную поддержку. :santa2: Может, так и надо? Раз GUI процесс имеет более низкий приоритет (а он имеет более низкий) чем процесс на SCHED_FIFO или SCHED_RR дисциплине, он и не должен получать процессорного времени данного CPU. Так именно и надо. В RT OS. А в GP OS (которыми и являются Windows, Linux, ...) его пользователи за такое удовольствие пошлют на хер разработчиков этой OS. И поэтому не желающие отправляться на хер, эти разработчики во всех этих (GP) OS вынуждены прибегать к использованию хитроумного шедулирования, с динамическими управлением приоритетами или квантами времени... Что, напротив, совершенно неприемлемо в RT OS. Вот такое вот кино получается... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 9 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Я просто не рассчитывал на настолько тупых читателей, которых нужно предупреждать, что если у них N процессоров, то чтобы их заблокировать нужно N экземпляров RT задачи :1111493779: . а мне кажется писатель сам об этом подумал только после того как написал диспетчирование реального времени не оставляет ни одного кванта задачам более низкого приоритета! - в Linux этого не происходит... ... P.S. Хотя ... возможно наблюдаемый эффект происходит оттого, что все тестовые прогоны сейчас (по нынешним временам, на современных процессорах) удаётся выполнять только на многопроцессорных архитектурах (2, 4 ядра) А в GP OS (которыми и являются Windows, Linux, ...) его пользователи за такое удовольствие пошлют на хер разработчиков этой OS. что и произошло с QNX, ггг. При наличии многоядерных процессоров недореалтайм + тормоза никому не нужны - разделение ресурсов на уровне гипервизора и вот вам тру реалтайм (хоть в виде bare metal хоть маленькая RTOS) + быстрая бесплатная GP OS + решение всех проблем с лицензиями типа GPL которые требуют открывать исходные коды. Вот такое вот кино получается... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Владимир Е. Зюбин 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Ну, этого явно недостаточно. К этому нужно добавить: - вытесняющий планировщик (не кооперативный)... ну, это зачастую выполняется, но была же такая многозадачная ОС как Windows 3.11? - приоритетное планирование ... и желательно этих приоритетов поболее: 64, а лучше 256 - не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: FIFO, RoundRobin, Sporadic, ... - из-за этого требования никогда ни Windows ни Linux не станут RT, сколько их не расширяй... - должны быть приняты меры в планировщике против инверсии приоритетов - на примитивах синхронизации: наследование приоритетов, или граничные приоритеты. Вот только тогда такая "многозадачная ОС"(с) может претендовать на RT. Вот я и говорю, что ни человек, то свое мнение по поводу ОС РВ... И как это во встраиваемых системах Виндовоз используют и Линукс... хоть кол им на голове чеши, не убедишь QNX изучить... Кстати, "многозадачные ОС" это широко распространенный термин. Разночтений не вызывающий. В отличие от РВ, например, именно попытка определить ОС РВ испортило напрочь впечатление от весьма неплохого текста http://citforum.ru/operating_systems/sos/glava_3.shtml Что же касается исходной темы, то как мне представляется, дело тут не в алгоритмах планирования (весьма неказистых, если судить по названиям: FIFO, RoundRobin и проч.), а именно в возможности поддерживать параллелизм на уровне задач, в наличии планировщика. 1. Вообще то, планирование в многозадачной ОС относится всегда к потокам, и никогда к процессам. Когда (для упрощения) говорят о планировании процессов, то неявно имеется в виду всё равно процесс планирования главного (и единственного - main) потока этого процесса. Имеется ввиду threads? какие еще потоки? thread в переводе с английского это нить, а не поток... единственно, что можно сказать по этому поводу, что англоязычная терминология не продумана, а русскоязычные пользователи при переводе еще больше запутали все дело... нет, чтобы просто сказать, main-thread (главная нить), как выделенная нить (thread)... так нет, вводятся какие-то процессы... а наши программисты thread еще как поток переводят... а как они "stream" переводят? Все это очень грустно... 2. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению. Это не вопрос эквивалентности, а вопрос последовательности при постановке проблемы. Ну, все-таки было бы логично сначала ответить на вопрос "а нужен ли планировщик вообще?"... и если вдруг окажется, что нужен, только тогда уже задаваться вопросом "а какой же планировщик тут нужен?"... С FIFO, RoundRobin-ом или с каким-нибудь действительно экзотическим алгоритмом планирования... Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Виктория 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Первоначальная постановка вопроса Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972 загубил на корню возможность обсуждения, я и открыла новую тему. Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала :) . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ... Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий? Приглашаю всех к дискуссии. :) и спор за 6 лет так и не утих и остался актуальным Что же касается исходной темы, то как мне представляется, дело тут не в алгоритмах планирования (весьма неказистых, если судить по названиям: FIFO, RoundRobin и проч.), а именно в возможности поддерживать параллелизм на уровне задач, в наличии планировщика. Может этот путь будет оптимальным? Цитата(Olej @ Oct 3 2012, 04:23) * 2. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению. Это не вопрос эквивалентности, а вопрос последовательности при постановке проблемы. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
juvf 10 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства.Так это ни о чём не говорит. Что там в этих системах управления - это тоже вопрос. Там этот windows может быть использовать чисто для GUI. Всё остальное аппаратно. Не думаю что в каком нибудь осциллографе винда считывает с ацп по одной выборке, складывает в ОЗУ, фильтрует, и выводит на экран. Наверняка захват и обработка сигнала аппаратно. винде остается тока считать кнопки, задать правильный режим аппаратуре и по готовности данных отобразить их на экране. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
_Pasha 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Первоначальная постановка вопроса Раз уж Виктория кулаком пО столу... :) Вот тут говорили про тысячи процессов и прочие далекие от реалий ситуёвины. Никто не мешает подходить к вопросу без фанатизма, - т.е. задача распадается на несколько процессов - минимум, т.к. это всё наклАдные сущности. А внутри каждого процесса- тысячи :) потоков с общим стеком и кооперативной многозадачностью. А тут расходы - мы знаем - sizeof(void *) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. По поводу "во встраиваемых системах" виндузей? Вкопирую прогноз фирмы IDC (http://rus-linux.net/forum/viewtopic.php?f=5&t=1856#p5226): И это в массовых "балалайках" на непритязательного обывателя Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства. По поводу мультимедии в ответственных управляющих системах - порадовало. Представилось: - сидит где-то на нововоронежской АЭС оператор в ночную смену... - и команду даёт голосом (мультимедиа!) для СУ: "Мурку давай"... - а та ему в ответ наигрывает (мультимедиа!) "Мурку", чтоб не так грустно было ночь коротать... Благостно. Лепота ... :santa2: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
sasamy 9 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба По поводу мультимедии в ответственных управляющих системах - порадовало. Представилось: - сидит где-то на нововоронежской АЭС оператор в ночную смену... - и команду даёт голосом (мультимедиа!) для СУ: "Мурку давай"... - а та ему в ответ наигрывает (мультимедиа!) "Мурку", чтоб не так грустно было ночь коротать... Благостно. Лепота ... :santa2: Какой сочный батхерт :) Был по смежным вопросам на ПС 500 кВ "Радуга" http://www.fsk-ees.ru/press_center/company...ELEMENT_ID=1046 так вот за визуальную часть мнемосхемы в составе SCADA там отвечала обычная Windows NT, какие еще ф-ции она выполняла не знаю - на тот момент система не была введена в эксплуатацию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Виктория 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба без фанатизма, - т.е. задача распадается на несколько процессов - минимум, т.к. это всё наклАдные сущности. А внутри каждого процесса- тысячи :) потоков с общим стеком и кооперативной многозадачностью. А тут расходы - мы знаем - sizeof(void *) А как в многопоточном случае решается проблема использования общего ресурса (процессорного времени, доступ к данным, измеренным на объекте, общая память, сеть, etc)? Сомневаюсь ещё, что для тысячи потоков достаточно стека в качестве механизма динамической памяти. И вообще то 1000 потоков - где же такую задачу по ЦОС и измерительным делам сыскать? Это такой же финт в сторону, как Olej о Мурке и sasamy: так вот за визуальную часть мнемосхемы в составе SCADA там отвечала обычная Windows NT, какие еще ф-ции она выполняла не знаю - на тот момент система не была введена в эксплуатацию. Проблема взаимодействия сложная система-оператор в наше неспокойное время бурного развития технологий решается зубрами науки в рамках эргодических систем, насколько я знаю. Потому что тут уже человеческий фактор, непредсказуемый. Я бы предложила исключить эти системы из рассмотрения, а то слишком универсальная постановка задачи утяжеляет её и найти пути решения становится невозможно. Ещё. По крайней мере, всегда при анализе вопроса при выборе OC всегда всплывал ещё один немаловажный качественный вопрос - требуется ли система жесткого реального времени или мягкого? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба А как в многопоточном случае решается проблема использования общего ресурса (процессорного времени, доступ к данным, измеренным на объекте, общая память, сеть, etc)? Сомневаюсь ещё, что для тысячи потоков достаточно стека в качестве механизма динамической памяти. - в API POSIX 1003.b (вида pthread_*()) каждый поток имеет свой собственный стек (да и страшно представить, что было бы с системой при сбое только одного потока)... - диспетчеризация делается на базисе потоков, а не процессов ... поэтому: что 1000 процессов, что 1000 потоков - в данном контексте это не важно - термин процесс в этом смысле вообще избыточный, его не нужно привлекать ... если вы не желаете дополнительной путаницы, или называйте это процессами, или тасками (в однопоточных системах) - это всё с точки зрения диспетчеризации одно и то же. И вообще то 1000 потоков - где же такую задачу по ЦОС и измерительным делам сыскать? Это такой же финт в сторону, как Olej о Мурке и sasamy: Ну почему же В технологии CUDA на GPU NVIDIA как-раз вполне может быть 1000 потоков, и как-раз на ЦОС (FFT). Я сам делал 1000 потоков - сначала в виде экспериментов, а затем и в одном из реальных проектов с железом ... до сих пор проект крутится. Ещё. По крайней мере, всегда при анализе вопроса при выборе OC всегда всплывал ещё один немаловажный качественный вопрос - требуется ли система жесткого реального времени или мягкого? А нет никакого "мягкого" реального времени ... как "не бывает осетрины 2-й свежести"(с). История вопроса: - термин мягкого реального времени был введен Microsoft - в то время, когда она изо всех сил тужилась сертифицировать Windows NT 3.51 (разрабатываемую системным отделом DEC) на (хоть куда, лишь бы сертифицировать!): а). POSIX-совместимость + б). на микроядерность + в). на риалтайм... - когда их послали и с а). и с б). и с в). - накал страстей несколько упал ... а спекулятивная терминология осталась. Есть такой мировой общепризнанный тестер - фирма Dedicated Systems (легко найдёте), так вот она выполняет изучение, и выпускает общедоступные объёмные отчёты... В их отчётах (по состоянию дел 2-5 лет назад, сейчас не знаю) такие RT системы, как pSOS, QNX, VxWorks ... что-то там из RT-клонов Linux ... Но никаких там "мягих" ... ни "микромягких", ни никаких других - там нет. Не допускают их в эту компанию. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vshemm 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Вас не учили в начальной школе разнице между необходимыми и достаточными условиями? Или вы решили грудью постоять за реалтаймовость "ванильного ядра" Linux? К сожалению, учили, поэтому парсер и ломается. Еще раз, на определение "ОС РВ -- это ОС с планировщиком задачи" вы сказали, что этого недостаточно, и выдвинули 4 требования, только после удовлетворения которых "Вот только тогда такая "многозадачная ОС"(с) может претендовать на RT." Ванильное ядро всем этим требованиям удовлетворяет, следовательно, оно может претендовать на RT (подчеркиваю, это не мое мнение, а прямое следствие ваших утверждений). Вот я и интересуюсь, как на самом деле, может ванильное ядро претендовать на RT или оно рядом не лежит и вообще никогда не станет RT? Или это нужно понимать как "претендовать-то оно может, но так как оно априори не RT, то неважно каким требованиям оно будет удовлетворять - никогда оно RT не станет и не приблизится"? В Neutrino каком? А в QNX 4.25 их порядка 60. Ну и что? Neutrino - это ядро шестерки, и от версии к версии их количество почти не менялось. И то, что 1) системных вызовов в Windows и Linux не тысячи и 2) количество системных вызовов никакокого отношения к шедулированию нитей а не процессов не имеет (во всех озвученных ОС шедулятся нити). Так именно и надо. В RT OS. А в GP OS (которыми и являются Windows, Linux, ...) его пользователи за такое удовольствие пошлют на хер разработчиков этой OS. И поэтому не желающие отправляться на хер, эти разработчики во всех этих (GP) OS вынуждены прибегать к использованию хитроумного шедулирования, с динамическими управлением приоритетами или квантами времени... Что, напротив, совершенно неприемлемо в RT OS. Вот такое вот кино получается... Опять парсер сломался. Вы утверждали, что linux (и windows) не обладают нужными дисциплинами планирования, а на резонное замечание про SCHED_FIFO & SCHED_RR предложили запустить FIFO/RR приложение и посмотреть как криво оно работает. Внезапно выясняется, что работает оно как надо, но т.к. linux является GP OS (видимо, априори), оно все равно работает не так как надо(?). Странное кино получается... Вопрос очень простой: удовлетворяют ли линуксовые SCHED_FIFO & SCHED_RR тому что имелось ввиду здесь: [не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: FIFO, RoundRobin, Sporadic Только, пожалуйста, без мифических разработчиков и не менее мифического динамического управления приоритетами и квантами времени - на данных дисциплинах его нет (если не считать inheritance, но наследование по определению основано на динамике). P.S. На самый интересный вопрос про 100млн. тестовых запусков так и не ответили.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Olej 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба К сожалению, учили, поэтому парсер и ломается. ... Или это нужно понимать как "претендовать-то оно может, но так как оно априори не RT, то неважно каким требованиям оно будет удовлетворять - никогда оно RT не станет и не приблизится"? ... Опять парсер сломался. ... P.S. На самый интересный вопрос про 100млн. тестовых запусков так и не ответили.... А дальше здесь начинается пустой словесный понос :1111493779: , и мне здесь более делать нечего :crying: Я вам своё мнение достаточно высказал, времени на вас много перевёл ... а теперь вы можете: надувать щёки и обсуждать - обсуждать - обсуждать... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vshemm 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба А дальше здесь начинается пустой словесный понос :1111493779: Т.е. по делу вам сказать нечего, что и требовалось доказать. И кого-то еще удивляет что данное "обсуждение" не утихает уже 6 лет. Что ж, продолжайте в том же духе, всего доброго. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Виктория 0 4 октября, 2012 Опубликовано 4 октября, 2012 · Жалоба Т.е. по делу вам сказать нечего, что и требовалось доказать. И кого-то еще удивляет что данное "обсуждение" не утихает уже 6 лет. Что ж, продолжайте в том же духе, всего доброго. До свидания, vshemm! :bb-offtopic: Я тоже думаю, что для парсинга нашей молодежи 25 страниц хватит за глаза и склоняюсь к закрытию темы. Проблемы решаются каждым участником этой дискуссии на своем рабочем месте, новые результаты находятся поисковиками легко, а всякие мужские замеры на таком форуме, мне думается, совсем неуместны. Рассуждения вслух: для проведения подобной дискуссии в рамках форума нужна программная поддержка, некоторые функции администрирования, ограничение мероприятия по времени, может быть и по количеству участников. Нельзя не заметить, что такая виртуальная форма дискуссии имеет некоторые преимущества перед реальной, поэтому и очень много шума, помех. При отсутствии контроля и средств поддержки все преимущества нивелируются. Хорошо бы иметь возможность ограничить шум для заинтересованных участников, которые к тому же не имеют лишнего времени из-за занятости по основному месту работы. С уважением ко всем реальным и потенциальным участникам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
