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

mandrykin

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

Nov 22, 2007 01:56

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

Comments 8

_changer_ November 23 2007, 03:23:49 UTC

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

mandrykin November 23 2007, 11:28:36 UTC

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

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

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

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

_changer_ November 26 2007, 20:43:48 UTC

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

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

mandrykin November 28 2007, 23:10:44 UTC

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

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

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

Thread 5

_changer_ November 26 2007, 20:13:33 UTC

> Для передачи больших объёмов данных между различными адресными ( ... )

mandrykin November 28 2007, 23:17:14 UTC

> Я думаю, что этот момент стоит увести в сторону минимализма.

Минимализм на низком уровне. Каждый уровень обрастает новыми возможностями.

> Т.е. передавать указатель базового виртуального класса, по которому будет создан объект необходимого типа. А объект-приёмник всегда может привести этот указатель к тому, что ему надо. Т.е. отказаться от привязки на конкретные объекты.

Да да да! Совершенно согласен! Для одного адресного пространства наработки уже есть, а вот как реализовать нечто похожее на COM для разных адресных пространст - буксую.

_changer_ November 29 2007, 19:35:04 UTC

Тут будет большая стирка, при этом вероятно может появиться зависимость от компилятора, т.к. каждый хранит свою рантайм-инфу по своему. Меня вот где-то в феврале-апреле этого года сподвигло заняться этим вопросом... Далеко не ушёл, дебри там сумашедшие по объёму работы. Потом нашёл способ С++ свойствами как мне надо оперировать(поэтому ту разработку отменил), потребовалась довольно чёкнутая алгоритмика, которая большую часть вопросов закрыла красиво и надолго. Если есть вопросы, то спрашивай - помогу, если будет что дельного сказать, и спотыкался раньше об подобные грабли. :-)