User interaction и Real Time

Предпринимались ли попытки строить архитектуру операционных систем для настольных компьютеров/рабочих станций исходя из того, что взаимодействие с пользователем — это задача мягкого реального времени?

Какие странные вещи порой называют «архитектурой ОС» - просто удивительно.

Очередные новости от tailgunner-а:

Теперь алгоритмы планирования потоков уже не часть архитектуры.

Мне кажется в моем телефоне кнопка просыпания риалтаимовпч

Теперь алгоритмы планирования потоков уже не часть архитектуры.

«Теперь»? А были когда-нибудь? Со времен появления sched_setscheduler - точно нет.

Более того, даже наследование приоритетов и client impersonation (то, о чем ты пытаешься сказать, но не знаешь как) не являются концепциями, вокруг которых строят архитектуру ОС.

Короче, как обычно: пришел tailgunner и начал писать терминологическую бессмыслицу.

«Теперь»? А были когда-нибудь? Со времен появления sched_setscheduler - точно нет.

Ага: и механизмы IPC адаптируются сами под новые условия, и приложения сами себя перепишут...

Тоже из разряда «я коммичу rsync-ом потому что гладиолус»?

Более того, даже наследование приоритетов

Наследование деадлайнов, тащемта.

client impersonation

Ноль релевантных ссылок в гугле. Первая ссылке ведёт на сайт винды, где «Impersonation is the ability of a thread to execute using different security information than the process that owns the thread», что в общем-то правильно. Слово impersonation наиболее логично понять именно в контексте контроля прав доступа. А вот где ты его откопал применительно к МВР...

(то, о чем ты пытаешься сказать, но не знаешь как)

Если бы знал, как сказать, я бы спрашивал не здесь, а в гугле. Правда, неожиданно?

не являются концепциями, вокруг которых строят архитектуру ОС.

Стесняюсь спросить, а вокруг чего строят архитектуру продукта, если не вокруг РЕШАЕМЫХ ЗАДАЧ?

Теперь алгоритмы планирования потоков уже не часть архитектуры.

«Теперь»? А были когда-нибудь? Со времен появления sched_setscheduler - точно нет.

Ага: и механизмы IPC адаптируются сами под новые условия

IPC будут доработаны или введены новые. На архитектуру ОС это повлияет не больше, чем введение AF_DBUS в Linux.

«я коммичу rsync-ом потому что гладиолус»?

Круто тебя переклинило.

наследование приоритетов

Наследование деадлайнов, тащемта.

Наследование информации планировщика, «тащемта».

А вот где ты его откопал применительно к МВР...

Видишь ли, я начал интересоваться ОС тогда, когда гугля еще не было. Впрочем, от определения impersonation, которое ты нашел, всего один шаг до того, что тебе нужно.

Стесняюсь спросить, а вокруг чего строят архитектуру продукта, если не вокруг РЕШАЕМЫХ ЗАДАЧ?

ОС решает много разных задач, планирование - их малая часть.

применять EDF scheduling для этих целей?

для каких целей? EDF ты можешь и у себя применить

Можно рассматривать устройства ввода как источники событий, требующих заданное время отклика

можно. возьми ОСРВ на свой вкус, выставь HMI наивысший приоритет и избавься от тормозов в его кишочках

Были ли практические реализации?

вытащить всё взаимодействие с пользователем в реальное время нельзя (или, скорее, бессмысленно). частично этот подход реализован практически везде (проигрывание музыки без запаздываний, телефонный звонок, etc)

для каких целей?

Для этих: «Можно рассматривать устройства ввода как источники событий, требующих заданное время отклика, а приложения — как сущности, наследующие значение deadline от обрабатываемых событий.»

SCHED_DEADLINE

Я не спрашивал, как из буханки хлеба сделать троллейбус в домашних условиях. Я спросил, были ли операционных систем для рабочих станций общего назначения (в противоположность узкоспециализирвоанным девайсам, АСУ и т.п.) с широким использованием принципов МРВ.

частично этот подход реализован практически везде (проигрывание музыки без запаздываний)

Выставлением повышенного приоритета потоку? Так это не решение, это костыль. Решение РВ — это когда есть гарантии отклика.

Я такой умный, но вам ничего не расскажу.

Отоночо, михалыч.

Если ты до сих пор не понял, что ОС с такой архитектурой нет, что исследования по ним закончились лет 15 назад, и что при желании всё это можно добавить в ОС традиционной архитектуры, кто ж тебе доктор...

А если к наследованию приоритетов и client impersonation добавить Send-Receive-Reply, то у тебя будет картина, достаточная и для ответа на вопрос «почему таких архитектур ОС нет», и для «практической реализации» %)

и что при желании всё это можно добавить в ОС традиционной архитектуры, кто ж тебе доктор...

См. сообщение выше про троллейбус.

Если ты до сих пор не понял, что ОС с такой архитектурой нет, что исследования по ним закончились лет 15 назад, [...]

А если к наследованию приоритетов и client impersonation добавить Send-Receive-Reply, то у тебя будет картина, достаточная и для ответа на вопрос «почему таких архитектур ОС нет», и для «практической реализации» %)

Типичная картина:

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

Приходишь на форум, задаешь вопрос из теоретической или исследовательской области. Приходит ЫКСПЕРТ. Объясняет тебе, что ты нубло поганое, и что твой вопрос примитивен и, кроме того, имеет ответ «ненужно».

См. сообщение выше про троллейбус.

Троллейбус - это твоя воображаемая архитектура.

Приходит ЫКСПЕРТ. Объясняет тебе, что ты нубло поганое, и что твой вопрос примитивен и, кроме того, имеет ответ «ненужно».

Да, твой вопрос примитивен; да, ты нуб (но «нубло поганое» - это твои комплексы); да, требуемые тобой архитектурные изыски оказались не востребованы для решения практических задач - хватило грубых методов, описанных jtootf; и да, я дал тебе достаточно ключевых слов, чтобы гугл или поход в библиотеку восполнили пробелы в твоем образовании.

вытащить всё взаимодействие с пользователем в реальное время нельзя (или, скорее, бессмысленно). частично этот подход реализован практически везде (проигрывание музыки без запаздываний, телефонный звонок, etc)

Проигрывание музыки без запаздываний во всяких линуксах работает на честном слове. Типа «ну... буфер достаточно большой, чтобы все работало хорошо _почти_всегда_».

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

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

Многие вещи не делают не потому, что «это плохо», а потому, что «хватило грубых методов» и всем влом.

Проигрывание музыки без запаздываний во всяких линуксах работает на честном слове.

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

Насколько я помню, собственно проигрывание всегда в реальном времени, обеспечивается звуковой картой. Задача ЦП (ОС) предоставить данные для проигрывания.

Можно рассматривать устройства ввода как источники событий, требующих заданное время отклика

Время отклика всегда значительно меньше 0.1 секунды (что является границей восприятия), если временем отклика считать передачу сообщения приложению.

А дальше приложение должно обработать событие. На эту задачу смысла ставить ограничение нет, так как событие по нажатию на кнопку «Обновить систему», например, будет достаточно (и малопредсказуемо) долгим.

На уровне библиотеки GUI можно сделать гарантированный отклик элементов интерфейса. Тогда получим эффект как в HTML. Если cgi-скрипт повис/перегружен, то кнопки нажимаются (анимируется нажатие), но ничего не происходит. Лучше ли это с точки зрения пользователя — не уверен.

Туда же микроядро, клиент-серверная архитектура GUI, метаданные к файлам, основанная на образе рабочая среда пользователя, операционная система в ПЗУ...

Куда «туда же»? Часть упомянутого тобой живет и здравствует, или не нужно от слова «совсем» (основанная на образе среда).

взаимодействие с пользователем — это задача мягкого реального времени

Кстати, Windows NT. Билл Гейтс заявлял, что это ОС виснуть не будет — курсор мышки будет двигаться всегда :-)

Часть упомянутого тобой живет и здравствует

Взаимодействие с пользователем в реальном времени тоже «живет и здравствует» настолько же.

Время отклика всегда значительно меньше 0.1 секунды

А дальше приложение должно обработать событие. На эту задачу смысла ставить ограничение нет, так как событие по нажатию на кнопку «Обновить систему», например, будет достаточно (и малопредсказуемо) долгим.

На уровне библиотеки GUI можно сделать гарантированный отклик элементов интерфейса. Тогда получим эффект как в HTML. Если cgi-скрипт повис/перегружен, то кнопки нажимаются (анимируется нажатие), но ничего не происходит. Лучше ли это с точки зрения пользователя — не уверен.

Я бы предположил такую формулировку:

Если приложение, отвечающее на событие ввода, в принципе может закончить обработку за время t, то оно гарантировано её закончит. То есть: обработка отклика не может быть в произвольном порядке прервана задачей с бОльшим deadline (в частности, неинтерактивными задачами, такими как компиляция, архивирование данных и т.п.). Если приложение не откликнулось за время t, задача считается проваленой, и её deadline значительно сдвигается в будущее. (По принципу: если пользователь не дождался быстрого отклика, то пусть ждёт дальше, уже не критично.)

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

в частности, неинтерактивными задачами

Ткнул в «открыть файл» и музыка заикнулась, закачка отвалилась, запись DVD болванки запоролась...

Взаимодействие с пользователем в реальном времени тоже «живет и здравствует» настолько же.

Речь не о «взаимодействии в реальном мире», а о специальных средствах ОС для этого.

Ткнул в «открыть файл» и музыка заикнулась, закачка отвалилась, запись DVD болванки запоролась...

А головой подумать?

Речь не о «взаимодействии в реальном мире», а о специальных средствах ОС для этого.

О каком «взаимодействии в реальном времени» может идти речь, например, на CFS, который решает задачу прямо обратную: не «чтобы отклик пришел за время t», а «чтобы множество равноправных задач равномерно шевелилось на сервере»?

Интересно ты рассуждаешь: взаимодействие можно сделать, но средств для этого не обязательно. Дай угадаю — МАГИЯ?

О каком «взаимодействии в реальном времени» может идти речь, например, на CFS

Уверен, что человек, которому я отвечал, говорил о CFS?

Интересно ты рассуждаешь: взаимодействие можно сделать, но средств для этого не обязательно.

Не приписывай мне результатов своего непонимания.

Уверен, что человек, которому я отвечал, говорил о CFS?

Я тебе говорю по CFS.

Я тебе говорю по CFS.

И при это цитируешь фрагменты разговора на другую тему.

Сидите вы себе удаленно, по ssh, и тут сетевые лаги... Никакая ОС с таким не справится а все остальное вроде уже давно проблем не вызывает.

А головой подумать?

А как ещё твой алгоритм трактовать?

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

Для интерактивных задач характерное время 0.1 секунды. Если программа требует время сильно меньше, то никакого реального времени не надо, за 0.1 секунды всё закончится и так. Значит на 0.1 секунды «обработка отклика не может быть в произвольном порядке прервана задачей с бОльшим deadline (в частности, неинтерактивными задачами ...)». Я и перечислил неинтерактивные задачи, которые от прерывания получат больше проблем, чем интерактивные.Или предлагаешь считать музыку и закачку файла интерактивными? Тогда запуск музыки будет вызывать просадку производительности всего остального.

А что касается «специальных средствах ОС», то никто не мешает на QNX написать GUI или проигрыватель как RT задачу. Там всё есть.

А как ещё твой алгоритм трактовать?

Вот об этом и подумать.

А что касается «специальных средствах ОС», то никто не мешает на QNX написать GUI или проигрыватель как RT задачу. Там всё есть.

Я и перечислил неинтерактивные задачи,

Ты неправильно прочитал текст. Там написано: «задачей с бОльшим deadline». А в скобках дан пример: «неинтерактивными задачами, такими как компиляция». Ты выкидываешь «задачей с бОльшим deadline», затем отрываешь «такими как» от слова «неинтерактивными» и это одиночное слово подставляешь в основное предложение. Естественно, получаешься чушь. Это всё равно, что во фразе «Такие люди как Вася всегда опаздывают» оторвать часть «такие ... как Вася» и оставить «люди всегда опаздывают».

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

Я и перечислил неинтерактивные задачи, которые от прерывания получат больше проблем, чем интерактивные.

Обработчики прерываний, естественно, имеют МЕНЬШИЙ деадлайн. Вопрос, однако, в том, как алгоритмически увязать прерывания и задачи типа «запись компакт-диска» и «проигрывание музыки». Легко представить соотношение деадлайнов: запись компакт диска < проигрывание музыки < отрисовка GUI. А вот придумать, как это будет на практике — сложнее. Почему: потому что у нас многопользовательская система общего назначения, а не ОСРВ в бурильной установке.

Тем не мерее, все меня тут отправляют RTFM по встраивамым ОСРВ. Во встраиваемых устройствах нет проблемы прав доступа, привелегий, 100500 приложений и т.п.

Тогда запуск музыки будет вызывать просадку производительности всего остального.

Логично, что, условно говоря, запуск музыки вызывает просадку производительности компиляции. Было бы странно, если бы было не так: ведь производительность аппаратуры фиксирована. В том и состоит применение МРВ в данном случае, чтобы «музыка» просаживала «компиляцию», но не наоборот.

А что касается «специальных средствах ОС», то никто не мешает на QNX написать GUI или проигрыватель как RT задачу. Там всё есть.

Ага, кроме самого QNX-ка в опенсорсе. Ну и, там, отсутствия драйверов и т.п. А, еще отсутствие программ.

Я в третий раз повторяю, тред не про то, как сделать из булки хлеба троллейбус, а про алгоритмы.

Я в третий раз повторяю, тред не про то, как сделать из булки хлеба троллейбус, а про алгоритмы.

Тогда опять непонятно чего ты хочешь. Алгоритмическая база есть в любой ОС реального времени. Приложения писать как приложения реального времени неудобно. Если для графического интерфейса как-то можно автоматизировать (но малоосмысленно), то какие приоритеты ставить на чтение с диска уже неясно. Если считать чтение с диска неинтерактивным, а проигрывание музыки РВ, то при недостатке ЦП нельзя будет даже запустить оболочку, чтобы убить процесс. Если считать загрузку файла выше приоритетом, чем проигрывание музыки, то ничего не поменяется по сравнению с нынешней ситуацией.