OSDev

Пусть так.Просто суть ipc в один квант уложить,а это задача ядра.Оповещение-для отладки.

Миникс не подходит. Медленное ipc, блин! Где взять мануал по L4 на русском!? Был-бы благодарен.

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

Да.Сообщ-я передают только упр.данные а ipc-перехлёст адр.простр.Блин на англонемецком не вариант)

После недельной реанимации модных комиксов по теории ос, являю Миру плоды беспечного отступнечества от коллизий традиционных заповедей осестроения.
Краткое отступление.
***Механизмы синхронизации разделённого доступа***
Семафоры, Мутексы, Мониторы, Сообщения, Перименные состояния и т.д.
Принцип: Единовременно в критической секции может находиться только один поток.
Решают проблемы: Состояние гонок, "Проблема читателей и писателей".
Создают проблемы: Взаимная блокировка, Инверсия приоритетов.

А вот, что предлогаю добавить в джентельменский набор юного осестроителя:
***Синхронизация фазы доступа***
Принцип: Фаза входа и выхода из критической секции протекает в пределах предоставленного кванта времени.
(Т.к. с точки зрения потока квантования "не существует", то даже если время находения в к/с меньше предоставленного кванта, поток "не знает" о времени истечения кванта, и поэтому не может синхронизировать фазу нахождения в к/с с рамками предоставленного кванта. Но он может оповестить об этом диспетчер, который, в случае прерывания предоставит потоку дополнительный смежный! квант. Таким образом время для потока становится не непрерывным, а гранулированным (или дискретным). Если поток не успевает выйти из к/с по истечению дополнительного кванта, то работа продолжается по традиционным принципам разделения времени (Привет Чижу:), а поток помечается как "Поток с непредсказуемым временем нахождения в К/С!", что может служить напутствием программисту на выпрямление рук. Размер дополнительного кванта выбирается при конфигурации системы и определяется исходя из средних значений скорости IPC и др.)
Решает проблемы: Состояние гонок, "Проблема обедающих философов"
и проблемы содаваемые "Механизмами синхронизации разделённого доступа". Повышает производительность системы за счёт исключения простоев в ожидании занятых объектов.
Создаёт проблемы: Противоречит принципам параллелизма, ???, ???.

***Синхронизация скорости потоков***
Проблема: Если группа потоков разделяет один объект, то по причине того, что скорости исполнения потоков различны (Разная периодичность вхождения в к/с), то "быстрые" потоки будут находиться бОльшую часть времени в сосоянии блокировки. А скорость группы будет равна скорости самого медленного потока.
Принцип: Быстрым потокам необходимо уменьшать квант времени (на разность собственной и средней групповой скорости), а медленым соответственно, увеличивать. Средяя скорость группы становится равна средней общей скорости потоков. Пропадает необходимость в изменении приоритетов.
Решает проблемы: "Проблема производителя и потребителя", повышает производительность системы за счёт выравнивания скоростей.
Создаёт проблемы: Противоречит принципам параллелизма, ???, ???.

Жду отзывов.

Что-то в этом есть.

Весь вопрос в том, что с этим делать?!!:)

Все эти расприкрасные механизмы, по идее, можно применять для различных типов IPC, но по-настоящему хороший результат должно показать использование этих механизмов в комплексе с быстрым и предсказуемым IPC. Под эту роль, как нельзя кстати, попадает разделяемая память. Она отвечает всем необходимым для этого требованиям: высокая скорость обмена данными, бОльшая по сравнению с сигналами информативность, высокая предсказуемость (нет лишних системных надстроек, поток работает с разд. памятью, как с собственным адресным пространством). Но одна беда: вся инициатива синхронизации принадлежит потокам, работающим с этой областью памяти. В случае использования разделяемой памяти, как основного
(а не дополнительного) типа IPC, такой подход не допустим. Вся инициатива синхронизации должна принадлежать ядру. Но как проследить обращение потока к странице(ам) РП, если они находятся в его адресном пространстве. Создавать виртуальную машину и контролировать каждое обращение к памяти - недостаточно по дзенски:) Да и теряется вся привлекательность разделяемой памяти. Я не нашёл ничего лучше, как использовать для этих целей страничное нарушение (исключение #14). Вот в чём смысл:
+После запроса потоков на создание РП, в памяти выделяется необходимое количество страниц и ядро включает эти страницы в адресные пространства потоков.
+За данной областью памяти закрепляется необходимый примитив синхронизации.
+Далее, ядро помечает страницы РП, как "отсутствующие в памяти":)
Любое обращение потока к таким страницам сгенерирует исключение, и управление получит оработчик данного исключения. А задача обработчика такова: закреплять мутекс (семафор) за потоком вызвавшем исключение. После этого обработчик устанавливает бит P в 1 и дальнейшие обращения потока к РП исключения не вызовут.
По истечению кванта времени диспетчер сбрасывает бит присутствия во всех разделяемых страницах. Теперь, когда второй поток обратится к РП, опять произойдёт страничное исключение и обработчик, увидев, что мутекс занят другим - заблокирует этот поток.
Получается, что обрабатывать исключение придётся ни каждый раз, как поток обращается к памяти (в случае с вирт.маш.), а один раз за весь квант времени, при обращении к РП.
Как зафиксировать выход потока из КС на уровне ядра я ещё не придумал. Пологаю поток должен позаботиться об этом сам: вышел из КС - сообщи ядру. Сообщить об этом можно послав соответствующий сигнал, или вызвав специальное программное прерывание.

Для IPC память нужна не всегда, передачу нескольких значений можно произвести через регистры или стек.
Разделяемая память используется для создания каналов передачи данных. Обычно это самостоятельный механизм, и в системах имеет своё название - fifo или pipe. Ты это относишь к IPC? В принципе, возможно.

Конечно, управляющие данные можно и через регистры передать, а через разделяемую память можно попробовать чёнить по-тяжелее. Например, РП, размером со страницу вполне подойдёт для передачи данных звукового и видеодрайверов, для буфера блочного уср-ва... А каналы, разумеется имеют свою прелесть. Вот на основе именованых каналов и хочу попробовать IPC замутить.