Что необходимо знать о микроядре L4

[mandrykin]

Прежде всего необходимо знать историю микроядра L4Также необходимо иметь представление о L4 IPC. IPC - это аббревиатура от словосочетания Inter Process Communication. В переводе на русский это означает "Взаимодействие между процессами". Каким же образом осуществляется такое взаимодействие в системах, построенных на базе L4? Это взаимодействие

Comments

[_changer_]

По поводу времени ожидания при синхронизации с другой нитью. Не то что там что-то такое плохое, но проблема пока наверное нормально так и не решена в процах - т.е. высокоскоростной счётчик, который прибавляется с определённой частотой. Допустим 1 наносекунда. Просто то, что есть, насколько я понимаю базируется на команде проца подсчёта тактов. Т.е. в попугаях. Завтра вышел какой-нибудь проц тритиум 10ГГц(фантастика!) или какой-нибудь с изощрёной архитектурой(своровали у инопланетян), что тактов меньше нужно. И получается, что этот счётчик един и очень далеко едит. Я к чему, к тому, что бывают очень долго исполняющиеся сообщения. Это касается оборудования. Винт спит, потом раскрутил шпиндель, а потом спозицировался и считал, 3-4 секунды ушли. Ну просто, параметр будет всегда плавать в пределах среды исполнения. Дополнительно внося ошибки. Пока что-то я не в курсе, что в процах есть подобное. Опрашивать внешний высокоскоростной таймер, достаточно дорогая операция по времени. Всё же может стоит её ввести, чтобы код сверху не плавал? Ведь проходит несколько лет, и опять производительность поднялась, и перепиливать те места? Хм. Шикарно получается с одной стороны, но... я всё же за надёжность результатов исполнения - пускай хоть с тактом 100нс, но такт известен, и более-менее гарантирована адекватная реакция. Сказано там 15мс, и будет 15мс, может быть чуть побольше(тоже не всегда хорошо, желательно удержание параметров), но никак не меньше. Так весь мультимедийный процессинг поедет далеко... :-(

А так, в целом, то что ты создаёшь - это вещь! Мне очень симпатична твоя разработка. Дуплекс с сообщениями достаточно весёлая тема, красиво, ничего не скажешь. Надо бы своего Буратино как-нибудь на подобное подпилить, пока просто вероятность возникновения подобных ситуаций очень низка, там по мере поступления проблем можно трединг на эти рельсы переставить.

[mandrykin]

> Я к чему, к тому, что бывают очень долго исполняющиеся сообщения. Это касается оборудования.

Я обошёл эту проблему используя конечный автомат. Т.е. сервис файловой системы послал запрос винту, а головка находится на другом конце диска, при этом файловая система не ждёт ответа от винта, а ждёт любые сообщения. Это может быть как ответ винта, так и запрос от другого приложения. Кстати, пост про IPC написан пока только наполовину. Но я работаю над этим.

> А так, в целом, то что ты создаёшь - это вещь! Мне очень симпатична твоя разработка.

Большое спасибо! Я очень ценю твоё мнение, поскольку ты обладаешь значительными знаниями в этой области.
Чтобы быть честным, надо сказать что придумал это не я - основываюсь и использую идеи Jochen Liedtke и разработки университета Karlsrue.

[_changer_]

Ну конечный автомат это хорошо. Но... есть такие задачи, где нужен строгий интервал - мультимедиальный процессинг. Где время макс. время до следующего кадра 40мс или 33мс в NTSC. За это время надо обработать(всё равно что-либо между тредами кодеков и фильтров летает...), и синхронизироваться. Т.е. попугайные временные значения вообще не применимы. Просто стоит на больших интервалах опрашивать высокоскоростной счётчик. Коли на коротких результат близок к идеальному.

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

[mandrykin]

> Ну конечный автомат это хорошо. Но... есть такие задачи, где нужен строгий интервал - мультимедиальный процессинг. Где время макс. время до следующего кадра 40мс или 33мс в NTSC. За это время надо обработать(всё равно что-либо между тредами кодеков и фильтров летает...), и синхронизироваться. Т.е. попугайные временные значения вообще не применимы. Просто стоит на больших интервалах опрашивать высокоскоростной счётчик. Коли на коротких результат близок к идеальному.

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

Кстати, ты не мог бы помочь в одном деле? Получил письмо на немецком, а о чём - понять не могу. Но точно не спам.

[_changer_]

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

Хорошо, посылай мне на мыло: changer at deepsoft-labs dot com