Board.KolibriOS.org

Official KolibriOS board
It is currently Sat Dec 07, 2019 10:22 pm

All times are UTC+03:00




Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 14 5 6 7 813 Next
Author Message
PostPosted: Tue Feb 10, 2009 3:44 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Да запросто.
Процесс A кушает половину своего кванта и например начинает ожидать событие, система передает управление процессу C, ещё через пол кванта возникает прерывание таймера и система передает управление процессу D. При этом процесс C даже при желании не получает свой свой квант полностью. То что я писал "примерно половину" - несколько неверно, вернее поток получает меньше 10мсек, причем нормально то что если в системе запущены не числодробилки а обычные GUI приложения (которые обычно только и делают, что ждут событий), за один квант управление может получить и 3 и 4 и т.д. приложений.


Top
   
PostPosted: Tue Feb 10, 2009 3:48 pm 
Ghost
Если они только ждут события и ничего не происходит, то количество может быть на порядок большим чем 3, 4. Все зависит от тактовой частоты процессора.

Если грубо посчитать, то при частоте 3 ГГц в промежутке времени произойдет 30 миллионов тактов. Пожалуй даже два порядка, если не больше, но как только приходит событие все становится печальным с точки зрения любителей RTOS.


Last edited by Mario on Tue Feb 10, 2009 3:52 pm, edited 1 time in total.

Top
   
PostPosted: Tue Feb 10, 2009 3:52 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
за один квант управление может получить и 3 и 4 и т.д. приложений.


Top
   
PostPosted: Tue Feb 10, 2009 3:53 pm 
Я понял. Просто развил мысль. :-)


Top
   
PostPosted: Tue Feb 10, 2009 7:40 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Не, ну тогда уж вся жизнь - одна сплошная непрерывная печаль :lol:
Однако работаем, не умерли, да и за плечами чего-то есть (в смысле, не безрезультатно)...

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

Во!!! Прошу отнестись к этому не как к какалке: "памагите не магу без этого", НО!!! как запросу к колегам (который и раньше озвучивал): "не противоречит ли такая идея, концепции развития оси, которая как-то где-то в головах таки сидит???"
Словами diamond-а, тем самым "более осуществимым, но не сделанным вещам"


P.S. Кстати говоря, и еще раз: "любители RT", это просто-напросто те люди, у которых нет физической возможности (они не виноваты) поставить второй jmp по принципу: "а вдруг первый не сработает" :wink:

P.P.S. Парни, спасибо за указание на проблему, конечно же!


Top
   
PostPosted: Tue Feb 10, 2009 10:32 pm 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Да не в планировщике основная проблема. (Хотя и с ним, если серьёзно и последовательно преследовать подобные цели, поприкалываться придётся.)
Привожу конкретный пример. Вся работа со всеми жёсткими дисками сейчас охраняется одним глобальным мьютексом. Это значит, что пока какое-то приложение находится "внутри" 70-й (или 58-й) функции (для /hd* или /bd*), всем остальным, вызвавшим эту функцию (для любого /hd* и /bd*), придётся подождать. А теперь представьте, что есть сверхкрутое сверхважное реалтаймовое приложение со сверхвысоким приоритетом, которое при сигнале от устройства получает управление абсолютно мгновенно. И в процессе обработки пытается подгрузить что-нибудь с диска. Неважно, что - может быть, текст сообщения пользователю, а может быть, дополнительный модуль для обработки такого сигнала. И тут оказывается, что непосредственно перед сигналом kfar/kfm/eolite копировал какой-нибудь файл. Или оператор слушает музыку/смотрит фильм, и именно в этот момент ac97snd/kvid вздумалось подгрузить очередной кусок файла. И сверхкрутое приложение вынуждено ждать, когда же вышеупомянутые проги закончат свои дела. А это уже никакие не "2.56 секунд", а потенциально сколь угодно долгий срок. Особенно если учесть, что ждать придётся вовсе не до выхода из функции, а именно пока работающая с диском прога не перестанет выдавать запросы к 70-й (58-й) функции (потому что вероятность того, что прерывание таймера, обработчик которого и занимается переключением процессов, придёт ровно в момент между вызовами функций, довольно мала. А на то, чтобы в момент освобождения мьютекса и выхода из функции вызвать планировщик немедленно, интеллектуальности у Колибри сейчас не хватает. А переделать это не так уж и тривиально).
Что? Говорите, сверхкрутое реалтаймовое приложение не общается с жёстким диском и использует только рамдиск? А то и вообще грузит всё в память заранее? Поздравляю, с этой проблемой оно не столкнётся. Но это был всего лишь один пример. И никто не даст гарантий, что нет других подобных проблем.

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


Top
   
PostPosted: Wed Feb 11, 2009 8:26 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
А согласен, возможно такое.
А если это сеть, так она еще и висеть может...
Разработчик должен понимать, что некоторые устройства входящие (точнее, которые он включил) в его систему (винт, к примеру), не обладают должными характеристиками. Или, как ими пользоваться для корректного выполнения задачи.
Это его работа, за которую он получает зарплату.

Но если действительно получится "Поздравляю, с этой проблемой оно не столкнётся" это уже кое-что...
И даже не кое-что, а не так уж и мало.
Скажем, по приведенной коллегой Ghost ссылке, подмечено, что RTOS имеют возможность отключить свопинг напрочь. С той же целью, надо полагать: чтобы задачи не пытались читать одной головкой из разных мест винта
И кому мы ближе, спрашивается :)

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


Top
   
PostPosted: Wed Feb 11, 2009 8:40 am 
Offline
Kernel Developer
User avatar

Joined: Mon Mar 20, 2006 10:44 am
Posts: 557
Quote:
подмечено, что RTOS имеют возможность отключить свопинг напрочь

У нас он и не включается никогда ))) Его просто нет.


Top
   
PostPosted: Wed Feb 11, 2009 9:37 am 
Offline

Joined: Sun Feb 18, 2007 8:34 pm
Posts: 158
Quote:
Это значит, что пока какое-то приложение находится "внутри" 70-й (или 58-й) функции (для /hd* или /bd*), всем остальным, вызвавшим эту функцию (для любого /hd* и /bd*), придётся подождать.

diamond, ты здесь затронул весьма серьезную проблему. Это уже не просто проблема RTOS, а скорее даже проблема, влияющая на вытесняющую многозадачность в целом. Блокировку нужно делать не для файловых операций, а при обращении к дисковому драйверу со стороны драйвера файловой системы, плюс отдельно блокировать основные объекты конкретной ФС с помощью специализированных блокировочных объектов (т.н. транзакционный подход). Дисковые драйверы при этом по структуре остаются близки к однозадачным. Всю нагрузку по многозадачности берут на себя VFS и частично драйверы файловых систем (последние в первую очередь отвечают за целостность структуры конкретной ФС на диске).


Top
   
PostPosted: Thu Feb 12, 2009 12:24 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
2Ghost
ну так и я про то же :!:

2diamond
Все таки вы обратили внимание на совершенно другую проблему.
Да это проблема. Но никакого отношения она не имеет к RTOS
И никакая ось самого наизреальнейшего времени не решает ее, да и не должна решать
Даже не в винте дело. Если кто-то работает с RamDrive, то другой кто-то тоже должен будет подождать
Обыкновенное дело, даже просто к области памяти нельзя "параллельно" обращаться с произвольным доступом (если этот доступ более одной команды проца)
Отсюда все ноги и растут

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

И наблюдаются ровно такие же сложности не только в осях на PC.
Можно подумать у меня на 8-битном контроллере (там-то уж точно ни на никаких разработчиков оси проблему не свалишь) нет таких прелестей
Несколько прерываний... Они готовят, предположим, многобайтные данные.
Основная программа пытается ими (предположим) воспользоваться - вот вам и конфликт данных.
Один из способов - закрыть прерывание. Это значит, что заставить обработчик подождать. Что сказывается на реактивности и детерминированности этого обработчика, ну и т.д..
Все то же самое, по большому счету-то...
И никаких средств, кроме собственной головы тут и придумать нельзя...
Чего-то мне так кажется.


Top
   
PostPosted: Thu Feb 12, 2009 12:50 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Мда. Похоже, комментарий в конце поста хотя и услышали, но не восприняли. Ну ладно, попробую ещё раз.
Есть много разных алгоритмов сортировки, в том числе быстрая (quicksort) и пирамидальная (heapsort). В среднем быстрая сортировка быстрее, но в худшем случае она ведёт себя просто ужасно. В ядре обычной системы имеет смысл использовать быструю сортировку вместо пирамидальной, потому что практически во всех случаях она быстрее. Но ядру RTOS быстрая сортировка категорически противопоказана, потому что теоретически вполне возможна ситуация "фатального невезения", когда быстрая сортировка будет выполняться слишком долго, а вот пирамидальная вполне подходит, хотя она в среднем и медленнее.
Один момент применительно к Колибри. Есть такая функция, как alloc_page - выделение физической страницы. Которая вызывается из кучи разных мест всеми подряд и выполняется с запрещёнными прерываниями. Она не использует под необходимые структуры много памяти (всего по одному биту на каждую существующую физическую страницу, занята/свободна, плюс две вспомогательные переменные) и в типичной ситуации (практически во всех ситуациях) находит свободную физическую страницу очень быстро. Но легко представить ситуацию, при которой этой функции понадобится несколько миллионов тактов, что даже на гигагерцовых процессорах приводит к запрещению прерываний на несколько миллисекунд, а на процессорах послабее соответственно увеличивает время до вполне ощутимых макроскопических величин. Кроме того, порядок величины указан исходя из того, что сейчас Колибри не знает ничего ни о PAE, ни о x64 и адресовать память больше 4 Гб в принципе не может, а потенциально эту величину следует ещё увеличить пропорционально объёму памяти, что опять-таки становится вполне ощутимым временем, даже если несколько миллисекунд ничего не решают. Но попытки переделать эту конкретную функцию уже могут натолкнуться на сопротивление, если окажется, что в типичной ситуации оно замедляет процесс (функция, между прочим, критичная для производительности системы) или существенно раздувает объём необходимой памяти, пусть и снижает гарантированное время работы - то, что хорошо для RTOS, вовсе необязательно хорошо для обычной системы.
На всякий случай уточняю, если кто не понял: если первый пример можно было обойти, просто не обращаясь к жёстким дискам, то в этом примере независимо от крутости обработчика он может просто не получить вовремя управления из-за других процессов в системе.
Повторяю ещё раз - это всего лишь пример блокировки, уже второй. Всего блокировок несколько сотен.

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


Top
   
PostPosted: Thu Feb 19, 2009 7:54 am 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Народ, я попозже продолжу... Пока взял таймаут в целях самообразования...

Вот в связи с этим и непонятка у меня, помогите:
Code:
;SVN\kernel\trunk\gui\event.inc
free_event:
           sub eax, [events]
           mov ecx, EVENT_SIZE
           mov ebx, event_map
           cdq
           div ecx

           pushfd
           cli
           bts [ebx], eax  ; не понял !!!????????????
           shr eax, 3
           and eax, not 3
           add eax, ebx
           cmp [event_start], eax
           ja @f
           popfd
           ret
@@:
           mov [event_start], eax
           popfd
           ret


Мне пока кажется, что надо примерно так....
Code:
free_event:
           sub eax, [events]
           mov ecx, EVENT_SIZE
           cdq
           div ecx
           mov cl, 32
           div ecx
           lea eax, [event_map + 4*eax]
           pushfd
           cli
           bts [eax], edx
           cmp eax, [event_start]
           jae @f
           mov [event_start], eax
@@:        popfd
           ret


:?:


Top
   
PostPosted: Thu Feb 19, 2009 10:35 am 
Offline
Kernel Developer
User avatar

Joined: Mon Nov 28, 2005 8:00 pm
Posts: 1601
Инструкция bts позволяет устанавливать нужный бит в большом массиве и в случае второго аргумента, превышающего 31.
http://wasm.ru/forum/viewtopic.php?id=31121
P.S. Деление на 32 командой div, мягко выражаясь, не самая удачная идея.

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


Top
   
PostPosted: Thu Feb 19, 2009 7:08 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Офигеть :shock:
Ну нету такого в букварях (или буквари мои шибко устарели) :)

Спасибо большое :!:

btw: если просто делить - и мысли такой бы не возникло... А раздербенить (если бы это на самом деле было надо) на два числа - не для слабонервных...
Может я и не очень прав, но я больше остерегаюсь работы с памятью (которая, в том числе, и длина кода) а не с регистрами...
Завтра "они" может выпустят проц (даже с той же частотой), который делит за "пол-такта", а вот с частотой внешней к камню шины - ничего они уже не сделают.
НО, это уже не более, чем не принципиальные мысли вслух


Top
   
PostPosted: Sat Feb 21, 2009 1:26 pm 
Offline

Joined: Fri Nov 21, 2008 8:16 am
Posts: 180
Кстати говоря, совершенно не понятно зачем вообще все эти пляски с бубном вокруг битового массива....
Достаточно иметь все "свободные" в виде связанного списка, на который указывает, скажем, event_start
Как минимум, никаких перборов при аллокации...


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 182 posts ]  Go to page Previous 14 5 6 7 813 Next

All times are UTC+03:00


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Limited