Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Когда не нужна ОС РВ?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы
Страницы: 1, 2, 3, 4, 5, 6, 7, 8
Olej
Цитата(Владимир Е. Зюбин @ Oct 1 2012, 17:17) *
тяжело общаться, когда нет единого языка...

... и мне сложно понять, где тут "поставщики данных", а где "поллинг", синхронная это схема или асинхронная.


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

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

Цитата(Владимир Е. Зюбин @ Oct 1 2012, 17:17) *
Предлагаю пред обсуждением по существу все-таки немного поговорить по терминологии, начав к примеру с круга решаемых задач и используемых аппаратных платформ.
Например, ограничиться Arduino и задачами "малой" автоматизации (управляющими алгоритмами, использующими исключительно периферию Arduino).

...

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

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

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


Цитата(Владимир Е. Зюбин @ Oct 1 2012, 17:17) *
Согласен. Правда, при этом я за всю свою жизнь так ни разу и не встретил внятного определения, что же такое "реалтаймовость".


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

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

Для синхронных PLC это неактуально - "масло маслянное", поэтому и не воспринимается.
Для многозадачных конкурентных ОС с приоритетами - очень даже актуально.
Возьмите к рассмотрению, например, ситуацию инверсии приоритетов (на любом примитиве синхронизации ... на мютексе, к примеру) для 3-х разноприориетных процессов/потоков - здесь в традиционных WIndows, и даже Linux время реакции может затянуться ... и до бесконечности santa2.gif
Владимир Е. Зюбин
Цитата(Olej @ Oct 1 2012, 22:57) *
Уже несколько раз звучит это утверждение и от разных авторов.
Поллинг это:
- циклический (повторяющийся) программный опрос...
- идущий от POSIX poll() ... но, скорее, "срываемый" по истечению таймаута периода ожидания,
- т.е. "синхронный"(с).

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


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

Цитата(Olej @ Oct 1 2012, 22:57) *
В теме обсуждения нигде не было заявлено такого ключевого слова как Arduino bb-offtopic.gif
Да и на "малой" автоматизации"(с) никто особенно не акцентировался...

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


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

Цитата(Olej @ Oct 1 2012, 22:57) *
Ну здесь вы лукавите... я, как помнится, не на одном обсуждении с вами пересекался, и всё вы прекрасно встречали biggrin.gif
Тот же стандарт 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


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


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

Цитата(Olej @ Oct 1 2012, 22:57) *
Для синхронных PLC это неактуально - "масло маслянное", поэтому и не воспринимается.
Для многозадачных конкурентных ОС с приоритетами - очень даже актуально.
Возьмите к рассмотрению, например, ситуацию инверсии приоритетов (на любом примитиве синхронизации ... на мютексе, к примеру) для 3-х разноприориетных процессов/потоков - здесь в традиционных WIndows, и даже Linux время реакции может затянуться ... и до бесконечности santa2.gif


В общем-то согласен, неактуально, даже скажу почему: потому, что там нет никаких мьютексов, семафоров и приоритетов, а, значит, конструктивно исключены инверсии приоритетов, дед-локи и прочие мексиканские узлы... wink.gif
Olej
Цитата(Владимир Е. Зюбин @ Oct 1 2012, 22:22) *
Увы, я встречал только попытки дать определения... К слову, по Вашей ссылке никаких определений я не обнаружил... и вообще про "реальное время" там только Ваша загадочная (для меня) фраза:

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



Цитата(Владимир Е. Зюбин @ Oct 1 2012, 22:22) *
Как я понимаю, в этой ветке обсуждаются условия, при которых ОС использовать неэффективно. Вариант Arduino это одно из возможных условий... Чего-то я определенно не понимаю... например, о каких ключевых словах Вы говорите... где они вообще?

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

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

Владимир Е. Зюбин
Цитата(Olej @ Oct 2 2012, 04:02) *
По моей ссылке можно выйти на оригинальные тексты самих стандартов POSIX ... которые многие обсуждают, но мало кто видел в глаза.
Я давал ссылку только с этой целью.


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

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

И сразу к ответу приблизимся.
Olej
Цитата(Владимир Е. Зюбин @ Oct 2 2012, 17:27) *
Так. Раньше было "ОС РВ -- это QNX"(или что-то такое), теперь уже "ОС РВ -- это стандарты POSIX..."
В принципе, достаточно конструктивно, только я бы не концентрировался на POSIX.

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


Цитата(Владимир Е. Зюбин @ Oct 2 2012, 17:27) *
Как Вам такое определение: "ОС РВ -- это ОС с планировщиком задачи", или просто "многозадачная ОС"?


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

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


Цитата(Владимир Е. Зюбин @ Oct 2 2012, 17:27) *
Тогда и тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет. Или, другими словами, в каких задачах нам нужен многозадачный параллелизм, а в каких многопоточный.

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


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

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

2. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению.
sasamy
Цитата(Olej @ Oct 3 2012, 02:23) *
У 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
Olej
Цитата(sasamy @ Oct 3 2012, 08:47) *
А Вы ничего не путаете ? man sched_setscheduler


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

Вы решили нас man-ом от Linux удивить? cranky.gif ... который "ни сном ни духом" рядом с 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: колхоз есть колхоз, и не нужно всё на веру принимать, что колхозом писано biggrin.gif ).
Цитата
не читайте большевистские газеты перед едой

laughing.gif
_Pasha
Цитата(Olej @ Oct 3 2012, 17:14) *
И не нужно о realtime познания черпать в man-ах, faq-ах и прочей Linux писанине
laughing.gif

Это точно. Линуксоиды - самая читающая нация в мире sm.gif блин, по нескольку сотен экранов мана за неделю - это неприятно даже с учетом того, что по диагонали.
sasamy
Цитата(Olej @ Oct 3 2012, 18:14) *
вот здесь "быстрый дистрибутив" возьмите за основу


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

Цитата
диспетчирование реального времени не оставляет ни одного кванта задачам более низкого приоритета!


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

Цитата
простейшая программа xxx типа:
Код:
while( 1 ) {};

- запущенная с одним из этих SCHED_* и повышенным относительно среднего (дефаултного) приоритетом:

# nice -n-19 xxx

- должна "забивать" терминал (или консоль) и его клавиатуру, т.е. делать систему непригодной


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

CODE

# 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 <--- консоль висит
vshemm
Цитата(Olej @ Oct 1 2012, 20:57) *
Вполне достаточно самой традиционной формулировки: детерминированное поведение - возможность обеспечения реакции в гарантированно заранее определённое максимальное время реакции... уложитесь ли вы в заказанный (завышенный) интервал, но с гарантией 100% из 100 млн. тестовых случаев.


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

Цитата(Olej @ Oct 3 2012, 02:23) *
Ну, этого явно недостаточно. К этому нужно добавить:
- вытесняющий планировщик (не кооперативный)... ну, это зачастую выполняется, но была же такая многозадачная ОС как Windows 3.11?
- приоритетное планирование ... и желательно этих приоритетов поболее: 64, а лучше 256 biggrin.gif
- не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: 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% в одном случае и завышение на порядок в других действительно показательно. А отображение такое потому, что шедулер входит в состав микроядра, а менеджеры процессов и памяти - нет (хотя без них микроядро не работает).

Цитата(Olej @ Oct 3 2012, 18:14) *
Нет, я как-раз абсолютно ничего не путаю.

Вы решили нас man-ом от Linux удивить? cranky.gif ... который "ни сном ни духом" рядом с 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: колхоз есть колхоз, и не нужно всё на веру принимать, что колхозом писано biggrin.gif ).


Учитывая что 70+% кода разрабатывается людьми из всяких Интелов, ИБМов, Редхетов и прочих Новелов на зарплате, неплохой колхоз получается sm.gif
Olej
Цитата(sasamy @ Oct 3 2012, 21:56) *
с какого перепуга RT задача которая выполняется на одном процессоре должна заблокировать другую не пересекающуюся по ресурсам на другом процессоре ? это ва не DOS который вы считаете realtime os 1111493779.gif


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


Цитата(vshemm @ Oct 3 2012, 23:13) *
В ванильном ядре все это есть, но он ""ни сном ни духом" рядом с RT не лежал..." - противоречие.


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

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

Цитата(vshemm @ Oct 3 2012, 23:13) *
Явная деза, возможно даже сознательная. В Neutrino ~130 системных вызовов, в Linux и Windows (NT) - ~350 и ~450 соответственно.

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

Цитата(vshemm @ Oct 3 2012, 23:13) *
А отображение такое потому, что шедулер входит в состав микроядра, а менеджеры процессов и памяти - нет (хотя без них микроядро не работает).

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

Цитата(vshemm @ Oct 3 2012, 23:13) *
Может, так и надо? Раз GUI процесс имеет более низкий приоритет (а он имеет более низкий) чем процесс на SCHED_FIFO или SCHED_RR дисциплине, он и не должен получать процессорного времени данного CPU.

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

Вот такое вот кино получается...
sasamy
Цитата(Olej @ Oct 4 2012, 02:32) *
Я просто не рассчитывал на настолько тупых читателей, которых нужно предупреждать, что если у них N процессоров, то чтобы их заблокировать нужно N экземпляров RT задачи 1111493779.gif .


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

Цитата
диспетчирование реального времени не оставляет ни одного кванта задачам более низкого приоритета!
- в Linux этого не происходит...
...
P.S. Хотя ... возможно наблюдаемый эффект происходит оттого, что все тестовые прогоны сейчас (по нынешним временам, на современных процессорах) удаётся выполнять только на многопроцессорных архитектурах (2, 4 ядра)


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


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

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

Владимир Е. Зюбин
Цитата(Olej @ Oct 3 2012, 04:23) *
Ну, этого явно недостаточно. К этому нужно добавить:
- вытесняющий планировщик (не кооперативный)... ну, это зачастую выполняется, но была же такая многозадачная ОС как Windows 3.11?
- приоритетное планирование ... и желательно этих приоритетов поболее: 64, а лучше 256 biggrin.gif
- не просто вытесняющее планирование, а планирование с реалтайм дисциплиной (алгоритмом) планирования: FIFO, RoundRobin, Sporadic, ... - из-за этого требования никогда ни Windows ни Linux не станут RT, сколько их не расширяй...
- должны быть приняты меры в планировщике против инверсии приоритетов - на примитивах синхронизации: наследование приоритетов, или граничные приоритеты.

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


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

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

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

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

Цитата(Olej @ Oct 3 2012, 04:23) *
1. Вообще то, планирование в многозадачной ОС относится всегда к потокам, и никогда к процессам. Когда (для упрощения) говорят о планировании процессов, то неявно имеется в виду всё равно процесс планирования главного (и единственного - main) потока этого процесса.


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

Цитата(Olej @ Oct 3 2012, 04:23) *
2. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению.


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

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

Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства.
Виктория
Первоначальная постановка вопроса
Цитата(Vic1 @ Mar 2 2006, 18:58) *
Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972
загубил на корню возможность обсуждения, я и открыла новую тему.

Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала sm.gif . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ...
Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?


Приглашаю всех к дискуссии. sm.gif


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

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


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

Цитата
Цитата(Olej @ Oct 3 2012, 04:23) *
2. Т.е. "тема станет более понятна: при каких условиях нужен планировщик задач, а в каких нет."(с) - это безусловно так, но это никак не эквивалентно следующему предложению.


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



juvf
Цитата
Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает. Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства.
Так это ни о чём не говорит. Что там в этих системах управления - это тоже вопрос. Там этот windows может быть использовать чисто для GUI. Всё остальное аппаратно. Не думаю что в каком нибудь осциллографе винда считывает с ацп по одной выборке, складывает в ОЗУ, фильтрует, и выводит на экран. Наверняка захват и обработка сигнала аппаратно. винде остается тока считать кнопки, задать правильный режим аппаратуре и по готовности данных отобразить их на экране.
_Pasha
Цитата(Виктория @ Oct 4 2012, 07:35) *
Первоначальная постановка вопроса

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

Вот тут говорили про тысячи процессов и прочие далекие от реалий ситуёвины. Никто не мешает подходить к вопросу без фанатизма, - т.е. задача распадается на несколько процессов - минимум, т.к. это всё наклАдные сущности. А внутри каждого процесса- тысячи sm.gif потоков с общим стеком и кооперативной многозадачностью. А тут расходы - мы знаем - sizeof(void *)
Olej
Цитата(Владимир Е. Зюбин @ Oct 4 2012, 06:36) *
Повсеместно в системах управления, во встраиваемых системах используют и Windows, и Linux. Никаких принципиальных проблем это не вызывает.

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

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

Цитата(Владимир Е. Зюбин @ Oct 4 2012, 06:36) *
Более того, есть серьезные основания предполагать, что использование этих ОС сокращает стоимость и время разработки... не говоря уже о таких нюансах как GUI и возможности интегрировать в систему мультимедиа-устройства.

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

Благостно. Лепота ... santa2.gif
sasamy
Цитата(Olej @ Oct 4 2012, 10:57) *
По поводу мультимедии в ответственных управляющих системах - порадовало. Представилось:
- сидит где-то на нововоронежской АЭС оператор в ночную смену...
- и команду даёт голосом (мультимедиа!) для СУ: "Мурку давай"...
- а та ему в ответ наигрывает (мультимедиа!) "Мурку", чтоб не так грустно было ночь коротать...

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


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

так вот за визуальную часть мнемосхемы в составе SCADA там отвечала обычная Windows NT, какие еще ф-ции она выполняла не знаю - на тот момент система не была введена в эксплуатацию.
Виктория
Цитата(_Pasha @ Oct 4 2012, 08:07) *
без фанатизма, - т.е. задача распадается на несколько процессов - минимум, т.к. это всё наклАдные сущности. А внутри каждого процесса- тысячи sm.gif потоков с общим стеком и кооперативной многозадачностью. А тут расходы - мы знаем - sizeof(void *)

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

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


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

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

Olej
Цитата(Виктория @ Oct 4 2012, 12:51) *
А как в многопоточном случае решается проблема использования общего ресурса (процессорного времени, доступ к данным, измеренным на объекте, общая память, сеть, etc)?
Сомневаюсь ещё, что для тысячи потоков достаточно стека в качестве механизма динамической памяти.


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

Цитата(Виктория @ Oct 4 2012, 12:51) *
И вообще то 1000 потоков - где же такую задачу по ЦОС и измерительным делам сыскать? Это такой же финт в сторону, как Olej о Мурке и sasamy:

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

Цитата(Виктория @ Oct 4 2012, 12:51) *
Ещё. По крайней мере, всегда при анализе вопроса при выборе OC всегда всплывал ещё один немаловажный качественный вопрос - требуется ли система жесткого реального времени или мягкого?

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

Есть такой мировой общепризнанный тестер - фирма Dedicated Systems (легко найдёте), так вот она выполняет изучение, и выпускает общедоступные объёмные отчёты...
В их отчётах (по состоянию дел 2-5 лет назад, сейчас не знаю) такие RT системы, как pSOS, QNX, VxWorks ... что-то там из RT-клонов Linux ...
Но никаких там "мягих" ... ни "микромягких", ни никаких других - там нет.
Не допускают их в эту компанию.
vshemm
Цитата(Olej @ Oct 4 2012, 02:32) *
Вас не учили в начальной школе разнице между необходимыми и достаточными условиями?

Или вы решили грудью постоять за реалтаймовость "ванильного ядра" 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
Цитата(vshemm @ Oct 4 2012, 15:22) *
К сожалению, учили, поэтому парсер и ломается.
...
Или это нужно понимать как "претендовать-то оно может, но так как оно априори не RT, то неважно каким требованиям
оно будет удовлетворять - никогда оно RT не станет и не приблизится"?
...
Опять парсер сломался.
...
P.S. На самый интересный вопрос про 100млн. тестовых запусков так и не ответили....


А дальше здесь начинается пустой словесный понос 1111493779.gif , и мне здесь более делать нечего crying.gif
Я вам своё мнение достаточно высказал, времени на вас много перевёл ... а теперь вы можете: надувать щёки и обсуждать - обсуждать - обсуждать...
vshemm
Цитата(Olej @ Oct 4 2012, 18:22) *
А дальше здесь начинается пустой словесный понос 1111493779.gif


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

Виктория
Цитата(vshemm @ Oct 4 2012, 18:14) *
Т.е. по делу вам сказать нечего, что и требовалось доказать. И кого-то еще удивляет что данное "обсуждение"
не утихает уже 6 лет. Что ж, продолжайте в том же духе, всего доброго.

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

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

С уважением ко всем реальным и потенциальным участникам.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.