Board.KolibriOS.org

Официальный форум KolibriOS
Текущее время: Сб сен 23, 2017 8:35 am

Часовой пояс: UTC+03:00




Начать новую тему  Ответить на тему  [ 182 сообщения ]  На страницу Пред. 19 10 11 12 13 След.
Автор Сообщение
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Вт июн 16, 2009 11:32 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Можно и так, только непонятно, нафига всё это - с практической точки зрения карусель прекрасно продолжает крутиться, причём приложение, активно работающее с диском, получает повышенный приоритет и шансы завершить операцию быстрее, а с теоретической точки зрения всё равно нифига не гарантируется. Ну и перехват iret вместо модификации кода выхода из v86 выглядит излишним переусложнением.

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Ср июн 17, 2009 12:10 am 
Не в сети

Зарегистрирован: Пт ноя 21, 2008 8:16 am
Сообщения: 180
Кстати говоря, до ревизии 1055 карусель возвращалась на старое место, после выхода из задачи v86.
Потому-что нарушалась синхронизация 3-х вышеупомянутых магических переменных.
Менялась только одна, а shed цеплялся за две неизменные...
Это я только недавно понял, после сравнительного анализа ревизий в ответ на "fixed V86 task switch on IRQ broken in rev. 1055" :)
Сегодня все правильно и синхронно, зато карусель сбоит. Не должна сбоить, даже теоретически.

Ну а некое повышение приоритета - не производит впечатления. Этими вопросам должен заниматься shed.
Точнее - вопрос дожен быть сконцентрирован в одном месте, а не размазан по всему репозиторию
Мне так думается.

Собственно я кажется все понял: в пункте в) надо не iret ловить, а факт открытия прерываний. Настоящие которые.
И все становится на свои места.
Это единственное стороннее использование do_change_task (которое было моей головной болью с самого начала) становится в один ряд с остальными прерываниями.
Которые должны быть короткими, чтобы у разработчика встроенных систем были "некие гарантии"

Да-да, я ничего не забыл, и супер-продвинутый RT-shed - за мной.
Просто без понимания вышеобсужденного - рановато, мне казалось.
И сейчас еще рановато. Но время придет


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Ср июн 17, 2009 8:44 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Чтобы у разработчика встроенных систем были "некие гарантии", необходимо тупо отключить работу через BIOS - иначе никаких гарантий не будет, а для встроенных систем с вполне предсказуемым железом достаточно реально написать все драйвера в конкретном случае.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Ср июн 17, 2009 9:35 am 
Не в сети

Зарегистрирован: Пт ноя 21, 2008 8:16 am
Сообщения: 180
Ну не знаю, неужели все так кошмарно...
В смысле, что биос может закрыть прерывания на не контролируемое время.
Неужели они там все без башки... Вряд ли, по-моему.

Даже в ДОС-овские времена существовали "резиденты", которые могли форматировать дискету в фоновом режиме

Главное-то в чем. Что бы появилась возможность создать реальную систему вовсе не надо гарантировать все и по любому поводу.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Ср июн 17, 2009 10:18 am 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
Насколько я понял, diamond говорит о необходимости глобальной перестройке ядра ОС, со сменой API, как следствие и GUI. Т.е. это означает, что придеться переписывать каждую программу. Режим V86, частный случай.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Ср июн 17, 2009 10:31 am 
Не в сети

Зарегистрирован: Пт ноя 21, 2008 8:16 am
Сообщения: 180
Ну в принципе - да, интересно бы уточнить
Зацепимся за конкретную фразу :)
diamond писал(а):
Если так определять абсолютные плюс и минус, то не в нашей власти выбирать, к какому из них двигаться - локальные изменения либо приведут к глобальным качественным, либо не приведут. Я склонен считать, что в данном конкретном случае - нет

Ну во-первых, мне кажется, что в нашей... Типа, сила человеческой мысли - безгранична.
Во-вторых, diamond, какие глобальные изменения ты считаешь необходимыми, которые мы никогда не сможем достигнуть "локальными" изменениями :?:
Как-то, из твоего вышеизложенного списка, мне такой кошмар на глаза не попался... Ну или не понял.


Последний раз редактировалось Galkov Ср июн 17, 2009 11:04 am, всего редактировалось 1 раз.

Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Ср июн 17, 2009 11:02 am 
Не в сети
Kernel Optimizer
Аватара пользователя

Зарегистрирован: Пн янв 16, 2006 7:58 pm
Сообщения: 657
Я предлагаю API функции, которые присуствуют сейчас в ядре вынести в подключаемую библиотеку. Сгруппировать функции по функциональности, дублирующие функции убрать. Частично вынести некоторый код в драйвера, разработать API взаимодействия драйвера с ядром ОС.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Пт июн 19, 2009 10:49 am 
Не в сети

Зарегистрирован: Пт ноя 21, 2008 8:16 am
Сообщения: 180
Ну и ладно, будем цитировать из другого топика :D
diamond писал(а):
Мнэээ? Кто-то совсем недавно что-то говорил про гарантии, и мне казалось, что этот кто-то тоже подписывался ником Galkov. Ну а реальная система, которая вовсе не гарантирует всё и по любому поводу, - это и есть текущее состояние планировщика...

Неправда Ваша, дяденька
Никогда я не говорил, что надо гаранитровать ВСЕ, иначе типа полный кердык...
С самого начала (этого топика) я говорил, что нужно сделать ВСЕГО ЛИШЬ две небольшие вещи, чтобы совершить качественный скачок: "применимость KoOS для встроенных систем"
Это:
    а) планировщик, который гарантированно предоставляет "сигнал" приложению не медленнее, чем за заранее заказанное время
    б) не "вешать" исполнение приложения прерываниями, или иными мероприятиями, на время сравнимое с квантом переключения задач. Как минимум, чтобы была возможность подобрать железо (ну там частота проца, шины, и т.п.) для выполнения этого.
И все.
После этого, я смогу решать, как минимум, некоторые задачи.
И это качественный скачок - сегодня не могу.
Естественно, в своем понимание того, что такое реальная система.
А в чьем еще, если за конечный результат отвечать именно мне........

Первое - мне представляется вполне преодолимым. Несколько увеличившиеся за последнее время, мои познания в архитектуре KoOS - не отменяют пока этого.
Второе - преодолеваем по мере поступления. В первую очередь те вопросы, без которых не обойтись.
Например, сбой карусели "кем ни попадя" - это ТАКОЙ вопрос.
А вот ожидание мьютекса "потенциально неограниченное время" даже при конечном времени захвата - это уже НЕ такой вопрос.

Ответственность оси - только время доставки сигнала (каковым также является и факт принудительнго по int0 прерывания исполнения), и предоставление временного ресурса для его обработки. Хочешь RT-характеристики - работай с монопольным захватом ресурсов, вот и вся проблема.
Причем не проблема оси, а разработчика
Монопольное - в широком смысле: в моем проекте могут быть несколько RT-потоков, которые общаются с моим же "драйвером" железа. Но это - мои проблемы а не оси. Всякий захват мьютекса "драйвера" я сделаю конечным во времени. Планировку предоставления ресурса моим (и ни чьим более) ожидающим потокам - так я этим как раз сейчас и занимаюсь.
И если сигналы от мьютекса будут доходить клиентам за предсказуемое время - у меня все сварится.
В том смысле, что именно я смогу отвечать за работоспособность именно моей системы.

Да, общие системные ресурсы упоминались. Винт, Аллокатор памяти...
И что :?: Это вовсе не отменяет возможности создания RT-приложения.
Да, с винта загружу все в память. Подкачки страниц уже и так нет (как во всех уважающих себя RT-осях). Если возникнет необходимость подкачки данных, то сделаю это через не-RT-поток, с такими временными характеристиками, что по исчерпании половины которого, можно будет включить сирену в рабочем зале, чтобы оператор пришел и исправил положение. Без остановки технологического процесса. В конце концов, даже исполнение договора, в рамках которого и выполняется данный технологический процесс - это тоже процесс в реальном времени.
Если системным аллокатором пользуются "все", то отстегну себе один раз сотню метров, и буду пользоваться своим, в 3-м кольце (каковой имеется практически во всех ЯВУ).

То же мне проблемы...
Проблема, это когда винда начинает менять размер файла подкачки, например :wink: Тут уже и "сирена" не поможет.
Более приземленно: железо сигнализирует о готовности, а у меня нет гарантия, что я узнаю об этом раньше чем завтра - вот это проблема.
Блин, народ ведь еще ДОС-ом пользоваться не прекратил, по всем этим причинам :)
Ну вот, моя простенькая задача и заключается в том, чтобы лишить его поледней аргументации к этому.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Вт июн 23, 2009 10:40 am 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пн ноя 28, 2005 8:00 pm
Сообщения: 1601
Что-то не видно глубоких отличий между этим "всего лишь" и глобальным "всё". Если не отвлекаться на общефилософские рассуждения, а брать применительно к BIOS: BIOS может запрещать прерывания; никто ничего не гарантирует насчёт времени этих запретов (на практике оно мало, но ведь мы говорим о теоретических гарантиях); следовательно, при включённой поддержке железа через BIOS нельзя ничего гарантировать о времени доставки прерывания.
Насчёт "Если системным аллокатором пользуются "все", то" - цитирую сам себя:
diamond писал(а):
На всякий случай уточняю, если кто не понял: если первый пример можно было обойти, просто не обращаясь к жёстким дискам, то в этом примере независимо от крутости обработчика он может просто не получить вовремя управления из-за других процессов в системе.
Повторяю ещё раз - это всего лишь пример блокировки, уже второй. Всего блокировок несколько сотен.

Полный пост всё ещё можно просмотреть здесь: viewtopic.php?p=22153#p22153.

_________________
Ушёл к умным, знающим и культурным людям.


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Чт авг 13, 2009 6:18 pm 
Не в сети

Зарегистрирован: Вс ноя 04, 2007 2:46 am
Сообщения: 390
diamond, ты озвучил достаточно фундаментальные мысли, которые раньше никто не осмеливался озвучивать. Но ты только описал ситуацию (хотя уже это радует), однако не стал делать выводов и каких либо предпосылок к каким бы то ни было решениям. ...?
Я ни в коем случае этого не требую)


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Вт окт 20, 2009 2:09 pm 
Не в сети
Kernel Developer
Аватара пользователя

Зарегистрирован: Пт авг 14, 2009 1:46 am
Сообщения: 1291
diamond писал(а):
Мда. Похоже, комментарий в конце поста хотя и услышали, но не восприняли. Ну ладно, попробую ещё раз.
Есть много разных алгоритмов сортировки, в том числе быстрая (quicksort) и пирамидальная (heapsort). В среднем быстрая сортировка быстрее, но в худшем случае она ведёт себя просто ужасно. В ядре обычной системы имеет смысл использовать быструю сортировку вместо пирамидальной, потому что практически во всех случаях она быстрее. Но ядру RTOS быстрая сортировка категорически противопоказана, потому что теоретически вполне возможна ситуация "фатального невезения", когда быстрая сортировка будет выполняться слишком долго, а вот пирамидальная вполне подходит, хотя она в среднем и медленнее.
Один момент применительно к Колибри. Есть такая функция, как alloc_page - выделение физической страницы. Которая вызывается из кучи разных мест всеми подряд и выполняется с запрещёнными прерываниями. Она не использует под необходимые структуры много памяти (всего по одному биту на каждую существующую физическую страницу, занята/свободна, плюс две вспомогательные переменные) и в типичной ситуации (практически во всех ситуациях) находит свободную физическую страницу очень быстро. Но легко представить ситуацию, при которой этой функции понадобится несколько миллионов тактов, что даже на гигагерцовых процессорах приводит к запрещению прерываний на несколько миллисекунд, а на процессорах послабее соответственно увеличивает время до вполне ощутимых макроскопических величин. Кроме того, порядок величины указан исходя из того, что сейчас Колибри не знает ничего ни о PAE, ни о x64 и адресовать память больше 4 Гб в принципе не может, а потенциально эту величину следует ещё увеличить пропорционально объёму памяти, что опять-таки становится вполне ощутимым временем, даже если несколько миллисекунд ничего не решают. Но попытки переделать эту конкретную функцию уже могут натолкнуться на сопротивление, если окажется, что в типичной ситуации оно замедляет процесс (функция, между прочим, критичная для производительности системы) или существенно раздувает объём необходимой памяти, пусть и снижает гарантированное время работы - то, что хорошо для RTOS, вовсе необязательно хорошо для обычной системы.
На всякий случай уточняю, если кто не понял: если первый пример можно было обойти, просто не обращаясь к жёстким дискам, то в этом примере независимо от крутости обработчика он может просто не получить вовремя управления из-за других процессов в системе.
Повторяю ещё раз - это всего лишь пример блокировки, уже второй. Всего блокировок несколько сотен.


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


Для менеджера памяти идеально подходит сортировка вставками в бинарное дерево. Поиск, сортировка и вставка в более-менее упорядоченном дереве в худшем случае занимают порядка log2N шагов. Чтобы добавить/удалить одну страницу памяти из тысячи, нужно не больше 10 шагов! Места для дерева требуется столько же, сколько и для двусвязного списка.

Правда, в отсутствие "садовника" деревья имеют тенденцию "дичать", выбрасывая длинные "черенки" без ветвления, что в самом худшем случае вырождает всю структуру в односвязный список, поэтому время от времени система должна их приводить в божеский вид. Переподвешивание бинарного дерева - несложная операция, занимающая ровно 2 N log2N шагов - столько же, сколько в среднем нужно для быстрой сортировки. Безусловные плюсы налицо:

1) аллокация памяти ускоряется в N раз и перестает быть RT-проблемой;

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

3) система может проводить упорядочивание дерева без блокировки прерываний;

4) можно объединить упорядочивание дерева с другой важной функцией - "сшивкой" смежных страниц памяти.

_________________
Узкий специалист подобен флюсу: полнота его - односторонняя.
Козьма Прутков


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Пт июл 22, 2011 1:51 am 
Не в сети
Аватара пользователя

Зарегистрирован: Вт авг 25, 2009 4:45 pm
Сообщения: 788
Для всех разработчиков (всех - это yogev_ezra и art_zh) - что думаете о статье о Колибри и Ко в самом крупном журнале индустрии? http://industrial-embedded.com/


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Пт июл 22, 2011 9:00 am 
Не в сети
Kernel Developer

Зарегистрирован: Ср мар 08, 2006 6:25 pm
Сообщения: 3928
А ссылка на статью есть ?


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Пт июл 22, 2011 9:21 am 
Не в сети

Зарегистрирован: Пн сен 24, 2007 11:11 am
Сообщения: 2814
А сама статья вообще в природе есть?


Вернуться к началу
 Заголовок сообщения: Re: Колибри для встроенных систем?
СообщениеДобавлено: Пт июл 22, 2011 11:18 am 
Не в сети
Public Relations
Аватара пользователя

Зарегистрирован: Пн июн 07, 2010 12:01 pm
Сообщения: 1879
Если я понял правильно, то он имел в виду, чтобы мы им предложили написать статью о Колибри. Ну предложить-то можно, только захотят ли они.


Вернуться к началу
Показать сообщения за:  Поле сортировки  
Начать новую тему  Ответить на тему  [ 182 сообщения ]  На страницу Пред. 19 10 11 12 13 След.

Часовой пояс: UTC+03:00


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 1 гость


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Limited
Русская поддержка phpBB