Board.KolibriOS.org

tsdima критические участки и так писались так что бы занимать как можно меньше времени, кто наблюдал такие задерки в 5-50сек???

Ghost

Кажется это была одна из модификаций L4. QNX для этого уже слишком "толстая".

tsdima

Я не могу гарантировать что таких задержек нет. Но это не значит автоматически что они есть и будут вылезать всё время.

Serge угу, OKL4 от Open Kernel Labs. Называется по умному formally-proven bug-free microkernel - микроядро с математически доказанным отсутствием ошибок.

Ghost

В этом много лукавства. Микроядро L4 настолько ужато что все ошибки выдавливаются в user-mode. Вот безошибочная система...

2tsdima:
Достаточно не отсутствия таковых "фокусов", а согласия коллег преодолевать эти проблемы по мере поступления.
Согласен


2Ghost:
От те раз...
А я думал наоборот, что это про меня... Ну ладно, это лирика
Конкретно

1) Давайте понимать существование 3-х уровней
Первый - это функционирование ядра (пусть условно это команда KoOS)
Второй - это разработчик системы (настолько же условно - это я)
Третий - это пользователи системы (это оператор и сисадмин в каком-нибудь Урюпинске)

2) Если система работает под моим чутким наблюдением - тоже нет вопросов. Как справедливо отметил коллега ДедОк - сносим все лишнее, и при запуске сторонних приложений я все понимаю про количество потоков
И совершенно спокойно можно работать с гарантиями реактивности в 100 мсек (ну не будет у меня больше 10 активных не спящих потоков).
И ни про какую винду мы такого сказать не сможем
Это тот случай, про который можно сказать "Да, вы попали по назначению"
Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка

3) Другой разговор - в Урюпинске. Да, сегодня врядли народ найдет нечто ресурсоемкое да запуска на KoOS. Но это только сегодня, а мы же пытаемся говорить о нише применения. Там возможно абсолютно все, даже то, чего мы сегодня и не предполагаем.
Это закон природы такой, многократно практически проверенный
Вплоть до тупого многократного нажатия на иконку какой-нибудь проги (про которую я слыхом не слыхивал).
И ведь следов никаких не будет... Разовор будет: "А у нас ка-а-ак врезалось!!!!"
Вот тут-то и возникает цифра 2.56 (не путать с п.2, где мною все контролируется) - это количество потоков, которые физически сможет запузырить пользователь, хоть из трусов он выпрыгни.

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

Быстр, вынослив, и кормить не надо....
Всякие рюшечки, прозрачности, полутени, майонез - оператору не нужны. Не боярин чай. У нас, вон, ему и интернет отключили специально
Необходимый набор инструментов - достаточно ограничен.
А вот работоспособность - оператору нужна.
Если ради этого не придется переделывать брак - оператор простит абсолютно все. Даже ДОС может стерпеть (проверенно)
И попадает это прежде всего в руки все-таки подготовленного пользователя (разработчика некой системы)
Ну все в тему получается

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

5) Слушай, ну а чем не конкретная постановка в таком виде:
5.1) Появляется сис ф-я запроса параметра изохронности потока. Это одно целое - количество квантов, через которое гарантировано получение управления
5.2) Ось позволяет только один такой с системе. Новая сис. ф-я возвращает в результате успех или неуспех запроса
5.3) Ось крутит карусель штатным образом, пока не наступает время изохронного потока. Тут и происходит отклонение от штатного планирования понятным образом. При получении управления потоком - его счетчик устанавливается на ранее заданный максимум. На каждом временном кванте - счетчик уменьшается

Вроде и все...
Понятно, что конкретность - вещь субъективная. Ну давай уточним, делов-то
Может это и слишком упрощенная постановка...
Но в чем фокус: сделать этот стартовый шаг самостоятельно, сегодня, после 2-х месяцев знакомства с кодами - не хватает у меня еще наглости. Через полгодика - хватило бы, наверное...
А на продолжить, усложнить, экстремальные эксперименты - уже хватает
Но даже эта упрощенная постановка - дала бы мне средство для борьбы с шаловливыми ручками из Урюпинска
Может не для абсолютно любой задачи, но дала бы
Это же бы ли бы принципиально отличающиеся ситуации

Galkov

Наглость - второе счастье.
P.S. Вышел R300 Gallium3D так что я пока занят.

Запуск "под моим чутким наблюдением" - это встроенная система, запуск в Урюпинске - это десктопная система? Раз опреатор может делать на ней все что угодно - то да. Если ты хочеш поставять свою систему в Урюпинск, то как вариант стартуеш свой процесс первым и просто не даеш возможности оператору запускать сторонние программы, это решаемая задача уже сейчас, в таком случае ты фактически получаеш систему запущенную "под моим чутким наблюдением".
Про изохронность. Для случая с только одним изохронным процссом задача легко решается грубыми методами, в виде правки core->shed.inc->irq0, добавляем туда условие и счетчик, первый запущенный процесс быдет иметь PID 1 (0 - система).
В таком виде для встройки решение оправдывается, для системы общего назначения нет.

Но согласитесь коллеги, это же не общий случай - это конкретная индивидуальная заточка

конкретное применение RTOS (HRT) это всегда заточка, я писал уже что для таких применений планирование просчитывается вручную потом применяется. (под "вручную" здесь понимается "зарание").

2Serge:
Это бесспорно... Но я привык таки сначала понимать полностью происходяще (хотя бы на этом экране) , а потом уже делать нечто.
Метод тыка - это не очень мое искусство... Да и глаз дурной...
Честное слово, пару месяцев, это не очень большой срок для такового... Ну не профессиональный программист я (ну разве что AVR-ки), не идет оно у меня так быстро. Тем более, что пришлось таки еще и Forth познать (были свои причины).
Так что, если кому интересно, могу свое понимание подробно изложить в соответствующем топике. Ибо с разговорчивостью у фортеров - как-то не очень
Не, ну и до наглости дело дойдет, куда оно денется.... Не, не завтра...

2Ghost:
Да оба дестопа, вообще-то. Как-то уже не очень ДОС-варианты продаются... Все уже избалованы дружественным интерфейсом
Да, захочется, в процессе резки разобраться и в файлах заказов, может посчитать чего, может отчет написать, или описание каких-нибудь проблем передать по смене...
Т.е., это все процессы не связанные напрямую с задачей
А где одна-две, там и много.... 21-й век на дворе.

А чем я отличаюсь?
Да тем, что если, к примеру, при копировании файла в KFAR, он у меня вдруг "пропал" (он же не занимается рисованием в процессе копирования), то я не буду запускать его еще сотню раз и повторять содеянное
Наконец у меня хватит ума и в CPU заглянуть.
((если совсем честно, то именно KFAR, и именно второй раз, и именно по этой причине - уже запускал))
А на разумность оператора из Урюпинска я профессинально рассчитывать просто не имею права, хотя и знаю, что по настоящему тупых не так уж и много...

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

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

Я согласен с тем что проблемы есть и они требуют решения, но:
1) Люди работают не за деньги, соответственно "пинать" их по какому либо поводу не имеет смысла.
2) Вытекает из п.1 - каждый реализует, то что считает интересным и нужным для себя, как справедливо заметил Сергей.

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

Сергей когда начал работать четко сказал, что он собирается делать и взялся за дело. За что ему большое спасибо. Если ты пойдешь тем же путем, то сложностей не возникнет, если нет... ну, думаю я уже достаточно написал.

2Galkov
Если есть внешнее устройство, то должен быть и драйвер для него. Твоё внешнее устройство подключается скорее всего к параллельному порту, а если это так, то твоё устройство всегда может генерировать прерывание от параллельного порта, хоть тыщу раз в секунду. Чтобы обработать прерывание придётся написать драйвер, но если твоё устройство только принимает данные, то это больше похоже на драйвер принтера (данные выдаются и стробируются драйвером и квитируются устройством). Если ты напишешь драйвер параллельного порта (принтера), который принимает от приложения большой кусок данных, а потом побайтно выдаёт через параллельный порт, тебе будут только благодарны. А если твоё устройство имеет более хитрый протокол обмена, то придётся писать более специфичный драйвер, только для себя. Но принцип тот же, так что заодно и драйвер принтера можешь состряпать

tsdima, если ты помнишь благодатные времена 98-й, то нафиг никакие драйверы не нужны были для обращения к портам. Работала бы она еще, до сих пор на ней сидел бы... Посмотри коды IoPorts.pas - делов-то.
И в KoOS драйверы тоже не нужны для обращения к портам, вроде
И это есть очень хорошо, между прочим
Ибо под XP, у меня среднее время обмена с портом около 5 мксек. А цикл ISA меньше микросекунды, вообще-то...

Да, именно на ём (LPT) у меня камень и сидит. Но это больше от отсутствия образованности.
Все одно придется в USB врезаться рано или поздно
Правда сидит очень удачно: двунаправленный режим в LPT (т.е., не очень уже и LPT), по-байтный обмен с камнем, у камня на шине данных целиком PortB, на котором же и линии егойного программирования.
В общем, "брюки могут превратиться"... даже и без легкого движения руки

Получилась простенькая многофункциональная карта (вообще-то у меня сегодня в ней пока всего 3 функциональности: TWI для вышеупомянутой системы, программатор InCircuitProgramming для моей периферии, и некий "драйвер" для отладки на мегах). Все это дело (8-я mega + несколько резисторов/диодов) спокойно умешается в корпусе DB-25 (прямо тот, который в комп и втыкается)
Функциональности остальных ног камня - для меня так выше крыши... Там и АЦП 8 входов (т.е., проблем с принятием и буферизацией 10кГц-ого аналогового сигнала у меня вообще никаких), COM, I2C (у них это правда это называется TwoWireInterface), не считая просто цифровых входов/выходов...
Вот по последнему все мои "думатели" меж собой и общаются.
Опять же, не потому, что я его считаю самым продвинутым, а потому-что он уже есть встроенный, "сеть" многомастерная даже, 500 кбит/сек мне вполне хватает, из дополнительных деталей для создания "сети" - по ферритовому колечку на линию для "гальваноразвязки" по высоким частотам

Т.е, у меня настолько все дешево и сердито, что страшное слово Драйвер - даже и вспоминать не очень хочется
Ты же помнишь, что является наилучшим средством от перхоти.....

Хм... Прерывания....
Если помнишь, в нашей VICX.sys такой функциональности просто нет.
Поэтому я и обхожусь без этого.
И, сказать честно, не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7 (или 9 - не помню точно, сейчас дома на буке LPT уже отсутствует напрочь)
Есть, конечно, идеи расширения функциональности, при использовании такового...
tsdima, но ведь в KoOS сесть на INT - тоже ведь драйвер не нужен

А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно
В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно)

P.S. если я чего-то не совсем точно (или совсем не точно) понимаю - буду благодарен, если коллеги меня поправят.
Ну и прошу прощения за некоторый offtop....
((типа: открою кодекс на любой странице, и не могу - читаю до конца))

Galkov wrote:не очень пока (опять - дефицит образования) представляю, какому INT-у в защищенном режиме соответствует IRQ7

Ну, это как товарищи ядростроители настроят.

Galkov wrote:А вот консультация коллег НУЖНА была бы, как оно работает, синхронно, или асинхронно
В смысле: вектор int-а на 0-м кольце сразу (асинхронно) передает управление нужному потоку, или откладывает сие важное действо до времени срабатывания карусели (синхронно)

Насколько я понимаю, драйвер может работать внутри ядра не зависимо от того, какой процесс является текущим. После того, как твоё приложение передаст все данные (от начала и до конца) драйверу и он сохранит их в "ядрёной" памяти, ему (драйверу) уже будет по барабану, какой процесс выполнялся в тот момент, когда возникло прерывание (т.е. адресное пространство какого процесса лежит ниже границы 2Гб), т.к. сам драйвер не обращается к какому-либо процессу, а работает сам по себе. Как максимум, он может установить какой-нибудь семафор/мьютекс, которого, например, ждёт твоё приложение. А вот когда ОС даст поработать твоему приложению, тогда-то оно и обраружит это событие, и отреагирует соответственно. Т.е. драйвер работает по принципу: его попросили - он сделал, и поставил галочку. А сам он никуда кроме ядра не обращается.

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

Мне как-то понятнее использовать старшие 16 бит маски событий.
Если действительно перехватывать вектор драйвером, тогда (видимо) придется и с 59-м общаться - да видал я его в гробу в белых тапках.

2Ghost
Коллега, Вы не так давно намекали, что "с гарантиями" поток получает не 10 мсек, а примерно половину...
Не могли бы Вы подробнее остановиться на этом вопросе
открыть глаза, так сказать