Board.KolibriOS.org

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

Ghost
Если они только ждут события и ничего не происходит, то количество может быть на порядок большим чем 3, 4. Все зависит от тактовой частоты процессора.

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

за один квант управление может получить и 3 и 4 и т.д. приложений.

Я понял. Просто развил мысль.

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

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

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


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

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

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

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

А согласен, возможно такое.
А если это сеть, так она еще и висеть может...
Разработчик должен понимать, что некоторые устройства входящие (точнее, которые он включил) в его систему (винт, к примеру), не обладают должными характеристиками. Или, как ими пользоваться для корректного выполнения задачи.
Это его работа, за которую он получает зарплату.

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

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

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

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

2Ghost
ну так и я про то же

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

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

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

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

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

Народ, я попозже продолжу... Пока взял таймаут в целях самообразования...

Вот в связи с этим и непонятка у меня, помогите:

;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

Мне пока кажется, что надо примерно так....

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

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

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

Офигеть
Ну нету такого в букварях (или буквари мои шибко устарели)

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

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

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