реал тайм осы

Первоначально опубликовано Sergey Sorokin Первоначально опубликовано Владимир Е. Зюбин Проблема fat-стандартов в том, что они непрактичны. Людям нужно работать, а не изучать талмудистскую литературу... Может из-за этого, в том же КНХ есть проблемы с ПОЗИКС... (об этом косвенно говорится в исследованиях дидикатед-системс) ] Ничего не могу сказать про проблемы КНХ, но мне трудно представить человека, который сразу начнет работать в области программирования ничего не изучая. Скажем начать программировать на С, не прочтя ни строчки из толстых книжек про то как это делать. Некоторые стандарты fat просто потому, что они не могут быть другими. Хотя возможно Вы знаете как описать несколько тысяч вызовов API ОС на 10 страницах.

Но. Где вы видели человека, который начинает изучать программирование на Си/C++ глядя в стандарт ? Более того, некоторые не могут переварить даже популярные книжки некоторых отцов-основателей.

Первоначально опубликовано Sergey Sorokin Первоначально опубликовано Владимир Е. Зюбин С моей точки зрения, своппинг нужно разрешать... если его не разрешить, а память требуется, то система грохнется... В этом смысле неверно сводить проблему к разрешению/неразрешению Д-С. Проблема гораздо шире - это динамические операции с ОЗУ, и их влияние на надежность... К слову, мы в своих системах динамические операции с ОЗУ исключаем конструктивно... Вот так. Как это не грустно слышать всем любителям calloc, malloc, а равно, рекурсий и ООП. Я не очень понял в чем Вы видите проблему. Во многих приложениях память распредляется статически при запуске, а во время выполнения динамически вообще не аллокируется. Если же какой либо программе от системы динамически требуется память, а у системы памяти больше нет, то система возврашает этой программе в ответ на ее запрос кукиш с маслом. Что с этим кукишем делать - проблемы разработчика программы, не вижу здесь фатализма с точки зрения "грохания системы".

Я собственно тоже большой проблемы с malloc & Co не вижу - всегда можно "родить свое". Но с другой стороны, при   переходе к программированию под протектед мод с виртуальной памятью некоторые ммм... гуру рекомендовали отказаться от проверки того, что возвращает malloc под предлогом того, что в случае нехватки памяти "система сама будет ругаться", т.е. потенциально кукиш до программы может и не дойти.

Первоначально опубликовано Draggan А не могли бы Вы дать ссылочку на какую-нибудь статью по earlier-deadline-first? Интерестно почитать и сравнить. Может мы в чем-то об одном и том же говорим?

Когда я писал статью у меня была коллекция ссылок. Но с тех пор (прошло более 5 лет) я этими вопросами не занимался и коллекция потерялась.

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

В жизни наряду с задачами ЖРВ обычно в системе есть задачи мягкого РВ, которые как правило можно свести к "желательному времени отклика" при превышении которого наступают допустимые неприятности и "обязательному времени отклика" после которого наступают недопустимые последствия. То есть EDF  со штрафами и с более чем одним дедлайном на процесс был бы по моему мнению более адекватен реальным условиям применения ОСРВ.  

Первоначально опубликовано Draggan Отдельное спасибо за разъяснение по пакетным запросам на ресурсы. Но ведь эта технология может быть реализована только в рамках ОС? Хотя... возможно и не только... Вы не могли-бы подсказать в каких ОС используется этот механизм?

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

Мне не известны операционные системы, где используется "пакетный захват" или тот же EDF  с несколькими дедлайнами.

С Уважением,

Сергей Сорокин

 

Первоначально опубликовано evgen Первоначально опубликовано Sergey Sorokin Ничего не могу сказать про проблемы КНХ, но мне трудно представить человека, который сразу начнет работать в области программирования ничего не изучая. Скажем начать программировать на С, не прочтя ни строчки из толстых книжек про то как это делать. Некоторые стандарты fat просто потому, что они не могут быть другими. Хотя возможно Вы знаете как описать несколько тысяч вызовов API ОС на 10 страницах. Но. Где вы видели человека, который начинает изучать программирование на Си/C++ глядя в стандарт ? Более того, некоторые не могут переварить даже популярные книжки некоторых отцов-основателей.

Я не призывал изучать программирование по ANSI/ISO стандарту на язык С. Обычно люди читают как минимум Руководство Пользователя конкретной системы программирования, которое в значительной части является, конечно вольным, но изложением стандарта. Скажем правила ПДД можно изучать по комментариям к ПДД или билетам (которые по размеру больше чем сами ПДД).

Я не очень понимаю как кто то сможет написать хотя бы программу "Hello world!" если он не возьмет в руки ТОЛСТУЮ книжку по стандартным библиотекам. Для написания такой программы совсем не обязательно переваривать всю книжку, но то что существует функция printf можно узнать только из этой ТОЛСТОЙ книжки (или что то же самое - из ТОЛСТОГО хэлп-файла).

Другими словами я не согласен только с тем что "толстый стандарт - это плохой стандарт только потому что он толстый".

Первоначально опубликовано evgen Я собственно тоже большой проблемы с malloc & Co не вижу - всегда можно "родить свое". Но с другой стороны, при   переходе к программированию под протектед мод с виртуальной памятью некоторые ммм... гуру рекомендовали отказаться от проверки того, что возвращает malloc под предлогом того, что в случае нехватки памяти "система сама будет ругаться", т.е. потенциально кукиш до программы может и не дойти.

В нормальной системе приложение запрашивающее ресурс у системы всегда получает информацию об успехе или неуспехе своего запроса. 

Более того приложение может  поучаствовать в обработке системных исключительных ситуаций (скажем неудача в подкачке страницы из-за поломки диска).

Если же разработчика удовлетворяют такие действия пользователя как "в ответ на ругань системы - нажмите кнопку reset", то значит у него такая задача. Никто кроме самого разработчика его проблемы решать не будет. Та или иная ОС - это только инструмент.

С Уважением,

Сергей Сорокин

 

Первоначально опубликовано Владимир Е. Зюбин Я не предлагаю пути решения, а просто констатирую, что с такими стандартами (по 500-800 стр) невозможно работать на практике. В той же самой компании МС, известный факт, практически никто эМэС-Си не пользуется, предпочитают свои классы стругать... так быстрее, чем изучать...

А здесь не нужно ни предлагать пути решения, ни констатировать... Этим не "невозможно пользоваться", а тысячи и десятки тысяч программистов этим пользуются на
практике каждый день!

Более того. Я ещё раз повторю: в тех случаях, когда это от меня зависит - "программист без POSIX-а" просто не попадёт на работу.

И немного в разъяснение, потому, что я понимаю, почему MS-DOS / Windows / OS/2 ... программисты не улавливают "на слух" что такое стандарты POSIX - им просто не приходится работать с этими стандартами.

Что такое strlen()? Правильно, функция C API, длина char* строки... но одновременно это - функция из набора POSIX (а именно: POSIX 1 он же IEEE 1003.1 - внушительнее звучит? ;-) ).

А что такое pthread_create() или pthread_mutex_lock()? Это - гораздо менее знакомые "вообще программистам", но всё те же функции из API POSIX (но уже POSIX 4a он же IEEE 1003.1c).

Вот и всё! Разговор идёт об стандартизации всех возможных API. И как вы это предлагаете изложить на 15 стр.? на 150 стр.?? ....

Первоначально опубликовано evgen Не пользуются они этим! Они жмут F1 в 99%, в 0.9% ищут FAQ и в 0.1% лезут в книжку.

Ну откуда вы знаете?
И почему вы решили, что 0.1% (книжка) - это POSIX, а всё остальное - это ... F1?
В QNX, например, в составе OS есть превосходная HELP подсистема, в том числе и по POSIX API - несколько тысяч или десятков тысяч страниц...
В одном из редакторов (ws), например, да, жмём... Ctrl+Alt+H (и тут с F1 не угадал!) и попадаем в HELP систему... по POSIX.
И даже просто оттуда копируем примеры использования в свой код... Вот какое падение нравов!
Ну и что?
Что, POSIX он от формы носителя изменяется?

Первоначально опубликовано evgen Не смешите мои тапочки. От того, что они не кричат на каждом углу "Халва!", пардон - "POSIX" еще не следует, что не работают.

Мне, простите, до фени, что у вас там на ноги одето...
Но - не работают!
Потому, как Windows - OS/2 сознательно ушли от POSIX, чтоб "оторвать" свою группу пользователей.
Вот в AIX IBM действительно достаточно строго следует POSIX/IEEE.

Первоначально опубликовано evgen ага, а еще до вашего позикса оно было еще ANSI Си. Которая кстати никогда не называлась "C API", а нормальном онлайн хелпе для через запятую пишется с какими стандартами оно совместимо.

ага, ... ;-)
И более того - в POSIX и IEEE и OpenGroup (UNIX98) - вообще, как правило ничего не изобретали: только собирали наиболее удачные решения, которые рождались в различных UNIX, анализировали на избыточность, противоречивость и т.д.

Первоначально опубликовано evgen Осталось таки выяснить - оно уже работает или все еще через одно место -

Вот вы уже и выяснили - работает, как говорил Мюллер:
- Никому нельзя верить.
- А вам?
- Мне - можно.

Первоначально опубликовано evgen вот поэтому самому оно и менее знакомое, а "маргиналы от уникса" продолжают пользоваться форками.

Про маргиналов ... это вы с чем-то перепутали.
Это не ко мне - это в словарь русского языка Ожегова.
А вот про fork & thread, и как оно работает... почитайте здесь:
http://qnx.org.ru/article7.html
- это я как-то написал для ... "маргиналов от уникса", там всё просто, даже программисту Delphi и то ... со 2-го прочтения...

Первоначально опубликовано evgen Ого...Сами сказали про все возможные API... И что, в POSIXе есть стандарты для GUI'евого API ?

А вот "GUI'евого API" (как-то не очень прилично звучит этот ваш API...? ;-) ) - как-раз, в POSIX, по понятным причинам и нет: не может быть единого API для X-Window & Photon native QNX системы.