Разработка концептуально новой ОС

[rcz]

Цитата

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

Если рассматривать прерывания - это все будет отдельно. Можно сделать отдельный объект обработки прерываний.


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

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

Цитата

Это нагружает ядро задачей упорядочивания сообщений. Более того, получим новую сущность: приоритет сообщения - в этой схеме это будет не совсем то же, что приоритет потока..

Можно сделать, что приоритет сообщения = приоритету потока. А можно просто ввести дополнительное поле в сообщении - приоритет создаваемого потока.
Да и это совсем не нагружает ядро. Это определяет само планирование задач и уже обсуждалось.

Цитата

Убрать его вообще - и не мучиться.

не писать ничего. и точно не мучиться .

Цитата

Чем?
Выглядит очень стройной.
Конечно, это лишние разновидности сообщений - зато они заменяют прерывания, межзадачные вызовы и порождение потоков.

Та схема, что я привел, тоже заменяет (или как раз определяет) все эти вызовы, прерывания и т.п.

И реализация мне кажется очень простой.
И очень хорошо накладывается на планирование задач, приоритеты (механизм тот же. Приоритет именно по сообщениям).

Сообщение отредактировано: rcz - 02.10.03, 18:02

[nvm]

Цитата rcz, 02.10.03, 22:00:59

Если рассматривать прерывания - это все будет отдельно. Можно сделать отдельный объект обработки прерываний.

..чем меньше сущностей - тем лучше.. а тут еще какие-то специальные обработчики прерываний..

Цитата

Та схема, что я привел, тоже заменяет (или как раз определяет) все эти вызовы, прерывания и т.п.
И реализация мне кажется очень простой.
И очень хорошо накладывается на планирование задач, приоритеты (механизм тот же. Приоритет именно по сообщениям).

Да.. доказать, что на самом деле красивее - невозможно..

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

Сообщение отредактировано: nvm - 02.10.03, 18:55

[rcz]

Цитата

- в каждой задаче, по сравнению с моей (точнее, KeyKOS) схемой, один лишний поток - всегда ровно на один поток больше;

В этом не вижу ничего страшного.

Цитата

- все бремя управления потоками ложится на приложение;

Интерфейс в потоке. Если он содержит подфункции - то это уже его проблема как обрабатывать.

Цитата

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

Что ж в этом плохого. В асинхронноых вызовах это всегда так будет, а синхронные - не важно кто будет тратить время.
И процессорного времени как понятия нет. Есть только время выполнения потока. Процессорное время - это время выполнения первого потока. Выполняются потоки, а не процессы. Процесс - только адресное пространство.

Цитата

То, что я предлагаю, гарантирует, что при таком обращении процесс получит результат ровно тогда же, как если бы он его вычислял сам.

Рассмотри поглубже, на уровне реализации. И увидешь, что тоже появится RPC, новые потоки.

Цитата

..чем меньше сущностей - тем лучше.. а тут еще какие-то специальные обработчики прерываний..

Правильно. Пока прерывания попадают под общее определение объекта интерфейса. Но т.к. прерывания сами по себе отдельная сущность, их придется рассмотреть отдельно (хотя бы в целях оптимизации)

Сообщение отредактировано: rcz - 03.10.03, 10:43

[nvm]

Цитата rcz, 03.10.03, 14:34:02

Интерфейс в потоке. Если он содержит подфункции - то это уже его проблема как обрабатывать.

При чем здесь подфункции?!
Вы зачем-то отождествляете интерфейс с потоком - хотя это принципиально разные сущности. Одну функцию можно вызвать несколько раз, причем параллельно. То есть один интерфейс может иметь любое число потоков (в т.ч. 0).

Цитата

И процессорного времени как понятия нет.

Это как??? Основного ресурса системы - и нет?

Цитата

Выполняются потоки, а не процессы. Процесс - только адресное пространство.

Не понял: мои же слова приведены мне же как возражение...

Квотироваться-то должны процессы!!
То есть если два процесса имеют одинаковый приоритет, то суммарное время, выделяемое на все потоки каждого процесса должно совпасть!
И важно, что если процесс запускает поток в чужом процессе, то он тратит на это собственный ресурс.
В пределах процесса потоки также могут иметь свой относительный приоритет.

Цитата

Рассмотри поглубже, на уровне реализации. И увидешь, что тоже появится RPC, новые потоки.

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

[nvm]

Похоже, обсуждение начинает упираться в личные предпочтения.
Или в интуитивные оценки, которые нельзя доказать, пока не напишешь под них реализацию VC++ и Office и не увидишь, где это проще..

Если какие-то варианты не удается согласовать, но, видимо, единственный вариант продолжения работы - включить их объединение.

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

И еще организационное предложение.
Если кто имеет принципиальные возражения против спецификации (несовместимые с общей идеологией интерфейса ядра), то прилагайте к ним свои ПОЛНЫЕ версии интерфейса (функций ядра). Потому что предложения имеют смысл только в контексте.

Желательно также оформлять такие предложения в структурированном виде (html). Тогда можно сделать сайт, на котором структурированно оформить все варианты с дискуссией - такая документация имела бы самостоятельную ценность, независимо от создания кода.

[rcz]

Цитата

То есть если два процесса имеют одинаковый приоритет, то суммарное время, выделяемое на все потоки каждого процесса должно совпасть!

В планировке и распределении процессорного времени учитываются только потоки. Только они исполняются и только они потребляют время.

А процессорное время - это время существования процесса в системе. Или суммарное время выполнения всех его потоков.

Цитата

Не понял: мои же слова приведены мне же как возражение...

Приведены, т.к. определяют, что сам процесс не исполняется и не планируется.

Цитата

То есть если два процесса имеют одинаковый приоритет, то суммарное время, выделяемое на все потоки каждого процесса должно совпасть!

Интересно откуда это взято.

Цитата

Вы зачем-то отождествляете интерфейс с потоком - хотя это принципиально разные сущности. Одну функцию можно вызвать несколько раз, причем параллельно. То есть один интерфейс может иметь любое число потоков (в т.ч. 0).

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

А подфункции - это если интерфейс еще что-то предоставляет (несколько функций). Тогда он создает другой поток, который возьмет основную работу, а сам вернет управление.

Сообщение отредактировано: rcz - 03.10.03, 14:24

[nvm]

Цитата rcz, 03.10.03, 18:22:34

Интересно откуда это взято.

Из требований стабильности и безопасности.
Если не квотировать время на весь процесс, то процесс, создавший 1000 потоков в 1000 раз замедлит остальные приложения.
В схеме, что я предлагаю, можно безболезненно запустить до 100000 потоков (если больше - могут начаться проблемы).

Цитата

Это позволяет просто перейти на другой RING процессора

Зачем такие сложности?!
Если процесс имееет право, он может сменить ring простым syscall-ом.

Цитата

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

Да уж.. понятно, что каждый предпочел бы писать ОС исключительно по своему проекту...

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

А альтернативных вариантов API ядра так пока и не представлено. Пока нет полной ясности с интерфейсом, нет смысла обсуждать реализацию.

Сообщение отредактировано: nvm - 03.10.03, 17:30

[rcz]

Цитата

Зачем такие сложности?!
Если процесс имееет право, он может сменить ring простым syscall-ом.

Это скорее упрощение. Нет лишних переключений контекста.

Цитата

Из требований стабильности и безопасности.
Если не квотировать время на весь процесс, то процесс, создавший 1000 потоков в 1000 раз замедлит остальные приложения.
В схеме, что я предлагаю, можно безболезненно запустить до 100000 потоков (если больше - могут начаться проблемы).

Стабильности это не прибавляет. Наоборот. Если процесс (допустим это сервер) больше всех использует потоков и притом очень большое количество. Зачем ему так все гадить.
(Хотя это и получится революционная идея. Ни в одной ОС такого не видел.)
Получится лишнее голодание потоков. И участится переключение контекстов- а это затормозит работу.

Цитата

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

Для начала, опишите ваши варианты обработки сообщений. Все очень подробно. (а то так их и нет, а только критика)

Сообщение отредактировано: rcz - 03.10.03, 18:46

[nvm]

Цитата rcz, 03.10.03, 22:43:49

Это скорее упрощение. Нет лишних переключений контекста.

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

Цитата

Стабильности это не прибавляет. Наоборот. Если процесс (допустим это сервер) больше всех использует потоков и притом очень большое количество. Зачем ему так все гадить.

Тут и работает вторая идея: обработку запросов сервер ведет в счет времени клиента (!). Поэтому сервер нисколько не замедляется.

Цитата

Для начала, опишите ваши варианты обработки сообщений. Все очень подробно. (а то так их и нет, а только критика)

Все вполне подробно описано в бюллетне, начиная с "Механизм сообщений".
Там все действительно компактно:
1) Для обработки send/fork всегда немедленно создается новый поток, который завершается по окончании обработки. Этот тип сообщений обрабатывается всегда.
2) Сообщения post/send незаметно для обработчика помещаются в буфер (если таковой есть), и обработчик их может считывать, когда пожелает (из любого своего потока).

То есть, обработчик ключа состоит из двух элементов: функция обработки (точка входа) и буфер (если создан). Все потоки объекта запускаются с одной точки.

Тут момент, конечно, получается нестандартный: приложение может быть активным, не имея вообще ни одного потока (даже приостановленного).

..Может, будут какие уточняющие вопросы? ..А то я уже повторяюсь..

..Насчет критики. Я ее никак не дождусь - Вы сразу предлагаете свои варианты, хотя вначале естественно было бы объяснить, что не нравится в уже предложенных.

[rcz]

Цитата

..Насчет критики. Я ее никак не дождусь - Вы сразу предлагаете свои варианты, хотя вначале естественно было бы объяснить, что не нравится в уже предложенных.

Не нравится только отсутствия уточнений. Все очень поверхностно и не определено.

Взять хотя бы это

Цитата

Там все действительно компактно:

Действительно компактно. Не подробно. Нет деталей.

Цитата

1) Для обработки send/fork всегда немедленно создается новый поток, который завершается по окончании обработки. Этот тип сообщений обрабатывается всегда.

Какой тип сообщений?

Цитата

2) Сообщения post/send незаметно для обработчика помещаются в буфер (если таковой есть), и обработчик их может считывать, когда пожелает (из любого своего потока).

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

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

Или вы предлагаете поток перекидывать из одного процесса в другой. Т.е. он сначала принадлижит одному, а потом другому процессу. - Это , сами понимаете, бред.

Т.е. без деталей все выглядит компактно, красиво. А когда начинаются уточнения - получаешь исправление архитектуры.

[nvm]

Цитата rcz, 04.10.03, 00:16:22

Действительно компактно. Не подробно. Нет деталей.
Какой тип сообщений?

Основных типов сообщений 4, и они разбиты на две группы:
1) для обработки которых создается поток,
2) которые помещаются в очередь и потом считываются в уже существовавшем потоке.
Если есть обработчик ("объект"), то первую группу сообщений он обрабатывает всегда.
А очереди он может и не иметь.

Цитата

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

Как нет.

Для отправки сообщения его нужно поместить в стек и сделать syscall. Всё, от клиента больше ничего не требуется.
В зависимости от типа сообщения, управление вернется либо сразу, либо по завершению обработки. Если предусмотрено - в стеке по возвращению будет лежать ответ (исходное сообщение оттуда удаляется).

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

Цитата

А не нравится, что для отправки сообщения должено создаваться отдельный поток. И так же при обработке сообщения - поток. (Ведб получатель должен обрабатывать несколько сообщений от разный источников сразу).

При отправке потока точно не создается. А при получении - зависит от типа сообщения.

Цитата

Или вы предлагаете поток перекидывать из одного процесса в другой. Т.е. он сначала принадлижит одному, а потом другому процессу. - Это , сами понимаете, бред.

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

Цитата

Т.е. без деталей все выглядит компактно, красиво. А когда начинаются уточнения - получаешь исправление архитектуры.

Основные детали уже описаны, согласно архитектуре.
Если что упустил - подскажите.

[nvm]

Любопытная ссылка:
http://mrlsd.narod.ru/os.html
Тоже предлагается приложениям дать доступ к портам, через БКВВ. Причем по  той же схеме: кто раньше попросил, тот и получил, а "опоздавшим" запрет.

[rcz]

ОК.
Согласен.
Но не с

Цитата

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

Как и кто будет копировать?  Т.е. кто занимается поддержкой очередей в этом случае?

Считаю от этого способа вполне можно отказаться. Он может быть реализован через 1-ый метод. Поток обработчика сам при надобности будет создавать очередь пришедших сообщений.

Цитата

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

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

Ну и стоит добавить, что обработку сообщений надо как-то упорядочить. В этом варианте единственный способ - приоритет создаваемого потока зависит от приоритета сообщения.

Сообщение отредактировано: rcz - 06.10.03, 14:52

[rcz]

Предлагаю еще ознакомиться с ядром Mach

http://gnuweb.kookel.org/software/hurd/gnumach-doc/mach.html
http://ftp.gnu.org/gnu/gnumach/gnumach-1.3.tar.gz

Сообщение отредактировано: rcz - 06.10.03, 15:06

[nvm]

Цитата rcz, 06.10.03, 18:08:15

Как и кто будет копировать?  Т.е. кто занимается поддержкой очередей в этом случае?

Для очереди получатель создает специальную секцию и сообщает ее ядру.
Очередь организуется простейшим циклическим буфером.
Ядро копирует сообщения в очередь сразу в момент их отправки.
Приложение-получатель теоретически их может читать сразу, но для синхронизации и очистки оно должно использовать системные вызовы, напр. GetMessage.

Цитата

Считаю от этого способа вполне можно отказаться. Он может быть реализован через 1-ый метод. Поток обработчика сам при надобности будет создавать очередь пришедших сообщений.

Это уже обсуждалось. Именно так сделано в KeyKOS.
Но создавать поток на каждое сообщение - все же очень накладно.
Поддержка очереди с помощью ядра - на порядок эффективнее.
Кроме того, подобную очередь будет реализовывать почти каждый обработчик (в GNU используется термин порт).
Считаю, что аргументы в пользу поддержки очереди ядром перевешивают.

Цитата

Т.е. новому потоку отдается все оставшееся время вызвавшего.

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

При отправке PostMessage получателю передается фиксированная порция (например 0.001) ресурса. Этого достаточно на минимальную обработку, что гарантирует защиту от спама.

Цитата

Ну и стоит добавить, что обработку сообщений надо как-то упорядочить. В этом варианте единственный способ - приоритет создаваемого потока зависит от приоритета сообщения.

Приоритет создаваемого потока можно указывать явно, при отправке сообщения.

А в очередь лучше помещать сообщения в порядке поступления (тем более, что они туда физически пишутся уже в момент отправки).

Цитата

Предлагаю еще ознакомиться с ядром Mach

Да.. немало понаписано..
ИМХО, здесь архитектура лучше  :D