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

Цитата nvm, 02.10.03, 18:40:06

Чем Ваш VMA отличается от секций? Может, опишете существо?

Здесь секция - универсальная абстракция для области памяти.
В x86 секция по-хорошему должна поддерживать в полном объеме возможности сегментов - а на других платформах позволять без сегментов обходиться.
Секция по смыслу похожа на сегмент (и призвана его эмулировать на платформах, где он не доступен). А сегмент - сущность процессора, то есть самого низкого уровня, так кому, как не ядру ее поддерживать?!

struct Section<br>{<br>    pointer start;<br>    pointer end;<br>    int segment_selector;<br>    enum Type {CODE, DATA, STACK, OTHER};<br>    Type type;<br>    bool read_only;<br>    bool is_static; // невыгружаемая<br>};

В таком виде секция не является достаточно универсальной сущностью. Кроме того, она содержит данные, которые будут излишними при выполнении программы. На самом деле, от секций нужно избавляться при загрузке EXE и DLL-модулей - либо проецируя в VMA, либо создавая сегменты. Хочется ещё раз обратить ваше внимание на то, что для x86 использование отдельных сегментов не нужно.

Теперь немного о том, как это работает. Писать об этом долго, так что приведу простой пример.

// kernelmode structures:<br><br>struct vma_s<br>{<br>    void        *start_addr;    // start address in userspace<br>    void        *end_addr;      // last address in userspace<br>    avl_node_s  *node;          // AVL tree node to speed up search<br>    void        *param;         // subsystem-specific parameter<br>    vma_vtbl_s  *vtbl;          // subsystem-specific functions<br>    uint        flags;          // subsystem-specific flags<br>};<br><br>struct vma_vtbl_s<br>{<br>    void (*page_fault)(vma_s *vma, void *fault_addr, uint fault_flags);  // #PF handler<br>    void (*close)(vma_s *vma);   // finalize VMA when process or handle destroyed<br>    // ...<br>};<br><br>struct avl_node_s  // Adelson-Velskii-Landis (locally balanced) tree<br>{<br>      avl_node_s  *left;   // left kid of node<br>      avl_node_s  *right;  // right kid of node<br>      uint        depth;   // depth (height) of node's subtree<br>};

Пример использования VMA в программе:

// get stream:<br>hStream = open_file("/usr/bin/perl", O_READ);    // open file for reading<br>// - or -<br>hStream = shared_alloc(0x80000, "/ipc/x-wnd/oem_font");   // allocate 0x80000 bytes<br>// - or -<br>hStream = shared_open("/ipc/x-wnd/oem_font");   // open shared memory<br>// - or -<br>hStream = local_alloc(0x80000);   // allocate 0x80000 bytes of local memory<br>// - or -<br>hStream = open_vesa_vbuf();   // open VESA video buffer<br>// VMA can stick together parts of VESA1.x fragmented buffer<br><br>// map hStream at memory range [dwStart, dwEnd], from position dwOffset<br>hVma = map_stream(hStream, dwOffset, dwStart, dwEnd, VMA_READ | VMA_WRITE_COPY);

Далее идёт обработка map_stream() в режиме ядра.

Здесь следует заметить, что handle в любой ОС выполняет ф-цию шлюза, т.е. не позволяет программе подсовывать в ядро произвольные данные, а только то значение, которое ассоциировано с конкретным номером хэндла (как правило, указателем на структуру в пространстве ядра). Когда программа при вызове syscallа передаёт в ядро хэндл, вызываемая ф-ция ядра должна получить вместо него указатель на структуру объекта, связанного с этим хэндлом. Само же ядро не работает с хэндлами, а только с указателями.

// kernel directs map_stream() syscall to kernelmode function usr_map_stream()<br>// all hanles are translated to its respective kernel struct's pointers<br><br>struct vma_s *usr_map_stream (struct stream_s *stream, size_t offset, void *start, void *end, uint flags)<br>{<br>    struct vma_s *vma;<br><br>      vma = kmalloc(sizeof(vma_s));<br>      vma->vma.start_addr = start;<br>      vma->vma.end_addr = end;<br>      avl_insert_node(¤t_process->vma_tree, vma);<br>      vma->vma.vtbl = stream_mapping_vtbl;<br>      vma->vma.param = stream;<br>      vma->flags = flags;<br><br>      return vma;<br>}

// member function from struct vma_vtbl_s<br><br>void stream_mapping_page_fault (struct vma_s *vma, void *fault_addr, uint fault_flags)<br>{<br>    // if page is not present, get it:<br>    // ((struct stream_s *)vma->param)->vtbl->map_page(vma->param, pos, fault_addr)<br>    // to make page to be available<br><br>    // if page is write-protected, generate exception<br>}

// system-wide exception handler<br><br>void page_fault_exception (void *fault_addr, uint fault_flags)<br>{<br>    struct vma_s *vma;<br><br>    if (vma = avl_find_node(current_process->vma_tree, fault_addr))<br>        vma->vtbl->page_fault(vma, fault_addr, fault_flags);<br>    else<br>        raise_user_exception(UNHANDLED_PAGE_FAULT);<br>}

Цитата nvm, 02.10.03, 18:40:06

В идеале, стек - это объект с интерфейсрм всего их двух функций: push и pop. И ему вообще не нужно адресное пространство. То, что в современных архитектурах ему приходится выделять адреса - это технические издержки.
Это аргумент в пользу выделения стека в отдельную сущность.

Но это только в идеале. А на самом деле, не так.

Во-первых, каждая ф-ция в программе выделяет в стеке фрейм, в котором хранит временные переменные, к которым она обращается в произвольном порядке, а не через push/pop.

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

Цитата nvm, 30.09.03, 21:19:52

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

Из выше сказанного следует, что потоки не смогут работать с общими переменными в стеке. Значит, это решение не годится.

Цитата nvm, 02.10.03, 18:40:06

Цитата

И это не единственное осложнение, которое у вас появится, если вы будете и дальше отказываться от модели пулов тредов, которая на самом деле, проще, красивее и эффективнее в реализации,

Может, Вы бы описали ее немного подробнее (можно с фрагментами из других источников)

И вот вам первая проблема:

Цитата nvm, 02.10.03, 18:40:06

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

Цитата nvm, 02.10.03, 18:40:06

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

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

Цитата nvm, 02.10.03, 18:40:06

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

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

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

Цитата nvm, 02.10.03, 18:40:06

И заваливаем этим хламом приложение..

Нет (патамучта!)

Цитата nvm, 03.10.03, 21:28:01

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

Процесс, создавший 1000 тредов, съест ещё свыше 16Мб памяти и будет тратить на переключения между ними до 10\% всего процессорного времени (включая работу шедулера и проч.). Запустив 100000, вы тормознёте Pentium4. А если говорить о карманных ПК, то для них 10 тредов - это уже слишком много.

Цитата nvm, 03.10.03, 23:52:28

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

И это не поможет.

И главное не в том, что вычислительных мощностей пока что не хватает, а в том, что такой дизайн ничем не оправдан.

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

Цитата nvm, 02.10.03, 18:40:06

И что?.. Разве кто-то предлагал что-либо, вызывающее зависимость ядра от модулей??

Это к тому, что наличие дополнительных модулей в режиме ядра ещё не делает само ядро монолитным. Я считаю, что часть подсистем и драйверов, для которых важна высокая производительность (все драйверы, работающие с I/O портами, дисковые и видеодрайверы), должны работать на уровне ядра, а не приложения.

Цитата nvm, 02.10.03, 18:40:06

Есть одна зависимость: для реализации подкачки ядро вынуждено обращаться к драйверу диска - но это исключение неизбежно и единственно.

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

Цитата nvm, 26.09.03, 16:59:44

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

Таким образом, один процесс может в любой момент (!) управлять тредом другого процесса, и даже принудительно завершить его! Неужели вы не понимаете, что этого нельзя допускать?

Цитата nvm, 26.09.03, 20:56:16

Настоящий объект САМ выполняет действия над собой - а если действия производятся извне, да еще "без его ведома", то это не объект с точки зрения ООП.

Возникла путаница в понятиях. На самом деле, здесь действия надо объектом "тред" происходят без ведома объектов в данном процессе, но с ведома и посредсвом самого треда, котрый является объектом ядра.

Цитата nvm, 25.09.03, 20:49:10

Если бы ограничиться только сообщениями типа Post/SendMessage - тогда объект действительно бы однозначно ассоциировался с потоком цикла обработки сообщений в нем, и можно было бы сказать, что это одно и тоже.
Но, когда есть Run/ForkMessage - тогда через любой объект могут проходить разные потоки и однозначной связи нет.

Я бы начертил схему, что с чем и как ассоциировано, но у меня нет возможности выложить её на форум.

Цитата nvm, 03.10.03, 17:46:27

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

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

Обязательно сделаю свой сайт, но пока что у меня не хватает для этого времени.

Цитата Vilmor, 06.10.03, 23:21:04

В таком виде секция не является достаточно универсальной сущностью. Кроме того, она содержит данные, которые будут излишними при выполнении программы. На самом деле, от секций нужно избавляться при загрузке EXE и DLL-модулей - либо проецируя в VMA, либо создавая сегменты.

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

Цитата

Хочется ещё раз обратить ваше внимание на то, что для x86 использование отдельных сегментов не нужно.

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

Цитата

Теперь немного о том, как это работает. Писать об этом долго, так что приведу простой пример.

Пример использования VMA в программе:

// get stream:<br>hStream = open_file("/usr/bin/perl", O_READ);    // open file for reading<br>

hStream - для ядра лишнее понятие (в нем достаточно секций).

Открытие файла в моем сценарии:

<br>Section S(...); // fill requirements (параметры)<br>hSection=Allocate(S);                //  выделить память<br>Share(hKey_FileServer,hSection); //  разрешить совместное использование секции<br>RunMessage(hKey_FileServer,"hStream=open_file(hSection,""/usr/bin/perl"", O_READ);");<br>    // открыть файл (сообщение приведено в текстовом виде для наглядности)<br>

Технические детали (половина параметров вызовов) здесь опущены.

Сервер для доступа к разделяемой памяти вызывает
Allocate() с доп. параметрами: hKey_Client,hSection (относительный хэндл секции).

Цитата Vilmor, 06.10.03, 23:52:05

Из выше сказанного следует, что потоки не смогут работать с общими переменными в стеке. Значит, это решение не годится.

Потокам НЕ НУЖНО работать с общими переменными в стеке.
А если такой изврат где-то используется - это не повод извращать архитектуру.

Цитата

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

Все равно понадобится возможность монтирования этих клоновых стеков на отдельные секции - но, в основном, для отладчика..

Цитата

Процесс, создавший 1000 тредов, съест ещё свыше 16Мб памяти и будет тратить на переключения между ними до 10\% всего процессорного времени

По-минимуму, хватит 4 Мб (по странице на стек).
Но суть в том, что затормозится только тот процесс, где 1000 потоков.

..Пожалуй, на средней машине 100000 будет тормозить. Но сделать, чтобы 50 000 (сколько влазит без свопа) не тормозило - реально.

Цитата

Мало того, что на обработку сообщений должно приходиться не более потока на каждый объект. Более того, число потоков должно быть меньше числа объектов!

И зачем такое ограничение?!

Цитата

Таким образом, один процесс может в любой момент (!) управлять тредом другого процесса, и даже принудительно завершить его! Неужели вы не понимаете, что этого нельзя допускать?

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

Цитата nvm, 07.10.03, 00:35:22

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

Пускай хоть так.
В любом случае, предложенное вами API не удовлетворяет всем потребностям прикладного ПО в управлении памятью. К тому же, часть параметров вашей секции приложению на самом деле не нужна.

Цитата nvm, 07.10.03, 00:35:22

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

1. От таблиц перемещения всё равно не избавиться.
2. Защита не выше ни на грош.
3. Сегментация памяти в наше время окончательно вытеснена страничной.

Цитата nvm, 07.10.03, 00:35:22

Все равно использование не x86 платформ - все больше экзотика.

Это не экзотика, а широко распространённое явление.

Цитата nvm, 07.10.03, 00:35:22

hStream - для ядра лишнее понятие (в нем достаточно секций).

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

Цитата nvm, 07.10.03, 00:35:22

Открытие файла в моем сценарии:

<br>Section S(...); // fill requirements (параметры)<br>hSection=Allocate(S);                //  выделить память<br>Share(hKey_FileServer,hSection); //  разрешить совместное использование секции<br>RunMessage(hKey_FileServer,"hStream=open_file(hSection,""/usr/bin/perl"", O_READ);");<br>    // открыть файл (сообщение приведено в текстовом виде для наглядности)<br>

Технические детали (половина параметров вызовов) здесь опущены.

Сервер для доступа к разделяемой памяти вызывает
Allocate() с доп. параметрами: hKey_Client,hSection (относительный хэндл секции).

1. Зачем выделять память для секции, в которую будем проецировать файл?
2. Зачем задавать поле Type = {CODE | DATA | STACK | OTHER} ?
3. Можно ли проецировать большой файл или разделяемую область памяти в меньшую по размерам секцию?
4. Как вы собираетесь задавать смещение данных файла относительно начала проекции?
5. Можно ли поменять это смещение для уже проецированного файла?
6. Можно ли использовать метод WRITE_COPY?
7. Насколько удобно ваше API для проецирования других объектов помимо файлов и разделяемой памяти?
8. Какими недостатками обладает VMA по сравнению с секциями?
9. Какими преимуществами обладают секции по сравнинию с VMA?

Цитата nvm, 07.10.03, 01:17:34

Потокам НЕ НУЖНО работать с общими переменными в стеке.
А если такой изврат где-то используется - это не повод извращать архитектуру.

Это не изврат, а вполне реальная вещь, очень часто встречающаяся.

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

Цитата nvm, 07.10.03, 01:17:34

Все равно понадобится возможность монтирования этих клоновых стеков на отдельные секции - но, в основном, для отладчика..

А ваш метод можно легко реализовать с помощью одной VMA с локальными для треда страницами (TLS). И для отладчика это не будет проблемой.

Цитата nvm, 07.10.03, 01:17:34

По-минимуму, хватит 4 Мб (по странице на стек).

Практика показывает, что нужно не меньше 8Кб для каждого стека. Кроме того, не стоит забывать и про другие структуры, необходимые для треда. Так что тут будет никак не меньше 16-ти Мб.

Цитата nvm, 07.10.03, 01:17:34

Но суть в том, что затормозится только тот процесс, где 1000 потоков.

..Пожалуй, на средней машине 100000 будет тормозить. Но сделать, чтобы 50 000 (сколько влазит без свопа) не тормозило - реально.

1. Затормозятся все процессы, потому что они разделяют общее процессорное время, а объём накладных расходов растёт.
2. 50 000 потоков тоже будет тормозить, и вы с этим ничего не сможете поделать.

Цитата nvm, 07.10.03, 01:17:34

И зачем такое ограничение?!

Чтобы рационально использовать ресурсы памяти и процессорного времени. Число потоков всегда надо минимизировать.

Цитата nvm, 07.10.03, 01:17:34

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

Этого нельзя допускать в любом случае, потому что это всегда даёт шанс одной программе нарушить нормальную работу другой.

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

Цитата nvm, 07.10.03, 01:17:34

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

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

Сообщение отредактировано: vilmor - 06.10.03, 22:25

Цитата Vilmor, 07.10.03, 01:46:05

Пускай хоть так.
В любом случае, предложенное вами API не удовлетворяет всем потребностям прикладного ПО в управлении памятью. К тому же, часть параметров вашей секции приложению на самом деле не нужна.

Каким требованиям не удовлетворяет, и какие параметры не нужны?

Цитата

1. От таблиц перемещения всё равно не избавиться.

Если они кому нужны - пусть использует.
Кстати, подумывая о "родном" для системы формате exe-файла, я склоняюсь к чистому bin. Конечно, нужно поддерживать и много других, но bin - самый удобный (пусть приложение само себя размещает в памяти).

Цитата

2. Защита не выше ни на грош.

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

Цитата

3. Сегментация памяти в наше время окончательно вытеснена страничной.

Не вытеснена - просто в виндах она не поддерживается, поэтому никто и не пользуется.

Цитата

Это не экзотика, а широко распространённое явление.

Единственное место, где я видел не PC - это тех. университет. Там есть несколько SUN.
Но подозреваю, что их покупку просто кто-то лоббировал, так как они на самом деле не пришей ... . Вместо одного SUN можно купить 30 персоналок, каждая из которых по производительности практически сравнима.

Цитата

Это не объект микроядра, а пользовательской подсистемы, работающей в режиме ядра.

У Вас, похоже, пользовательская подсистема имеет прямой доступ к структурам ядра?
Если так, то это по сути моноядро.
По-хорошему, только само ядро имеет доступ к своим структурам. Драйвера, работающие в привил. режиме имеют тем не менее свое адресное пространство.

Цитата

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

Непонятно, чем проецирование отличается от расшаривания.

Цитата

1. Зачем выделять память для секции, в которую будем проецировать файл?

Потому что виртуальное адресное пространство полностью во владении приложения - даже ядро по своей инициативе не имеет права в него ничего монтировать.
allocate - это монтирование либо новой либо расшаренной памяти на виртуальные адреса.

Цитата

2. Зачем задавать поле Type = {CODE | DATA | STACK | OTHER} ?

STACK - принципиально отличается по свойствам.
Кроме того, только в CODE может быть точка входа, и только она может исполняться.

Цитата

3. Можно ли проецировать большой файл или разделяемую область памяти в меньшую по размерам секцию?

Ядро позволяет только расшарить буфер. А как им пользоваться - приложения "договариваются" сами.
Функции read и write реализуются очевидным образом.

Цитата

4. Как вы собираетесь задавать смещение данных файла относительно начала проекции?

Стандартным синтаксисом read/write/seek - чтения (или записи) файла.

Цитата

5. Можно ли поменять это смещение для уже проецированного файла?

seek

Цитата

6. Можно ли использовать метод WRITE_COPY?

Это не специфично для файлов.
Для любых разделяемых секций этот метод можно использовать.

Цитата

7. Насколько удобно ваше API для проецирования других объектов помимо файлов и разделяемой памяти?

А кроме памяти ничего и не проецируется.

Цитата

8. Какими недостатками обладает VMA по сравнению с секциями?
9. Какими преимуществами обладают секции по сравнинию с VMA?

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

Цитата Vilmor, 07.10.03, 02:22:26

Это не изврат, а вполне реальная вещь, очень часто встречающаяся.

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

..Как-будто изврат не может реально часто встречаться  :)..

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

Цитата

А ваш метод можно легко реализовать с помощью одной VMA с локальными для треда страницами (TLS). И для отладчика это не будет проблемой.

..Тогда в чем, собственно, принципиальное отличие?!

Цитата

Практика показывает, что нужно не меньше 8Кб для каждого стека. Кроме того, не стоит забывать и про другие структуры, необходимые для треда. Так что тут будет никак не меньше 16-ти Мб

Другие структуры уложатся в десятки байт.

Цитата

1. Затормозятся все процессы, потому что они разделяют общее процессорное время, а объём накладных расходов растёт.
2. 50 000 потоков тоже будет тормозить, и вы с этим ничего не сможете поделать.

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

Цитата

Чтобы рационально использовать ресурсы памяти и процессорного времени. Число потоков всегда надо минимизировать.

Это резко ограничивает свободу в алгоритмах.
Если реализовать эффективную поддержку большого числа потоков - это будет очень большим козырем системы.

Цитата

Этого нельзя допускать в любом случае, потому что это всегда даёт шанс одной программе нарушить нормальную работу другой.

Смотря как эта другая программа написана.

Важный момент: при завершении потока все блокировки семафоров, которые он сделал, должны автоматически сниматься.

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

Цитата

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

Если поток создан клиентом, то он и нужен клиенту, а задаче-серверу он безразличен.
Но это технический вопрос, так как передача прав владения потоком все равно предусматривается.

Цитата

Ещё одна (какая уже по счёту?) лишняя сущность.

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

Сообщение отредактировано: nvm - 07.10.03, 06:58

Спасибо за пояснения.

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

Отлично. Вот только все эти ваши идеи прийдётся реализовать вам своими руками.
Во всяком случае, я в этом помогать не собираюсь.

Однако со своей стороны, осмелюсь ещё посоветовать вам чему-нибудь научиться сначала. Можно поступить на 1-й курс фак-та информатики в каком-нибудь университете. Хочется надеяться, это вам поможет.

Цитата Vilmor, 07.10.03, 10:57:33

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

Все же разработку принято четко делить на этапы: сначала интерфейс, потом реализация.
Не утвердив хотя бы на 90\% API ядра, нет смысла проектировать реализацию (кроме как на уровне общих идей).
Причем, проектирование интерфейсов - очень большая часть работы.

Цитата

Отлично. Вот только все эти ваши идеи прийдётся реализовать вам своими руками.
Во всяком случае, я в этом помогать не собираюсь.

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

Цитата

Однако со своей стороны, осмелюсь ещё посоветовать вам чему-нибудь научиться сначала. Можно поступить на 1-й курс фак-та информатики в каком-нибудь университете. Хочется надеяться, это вам поможет.

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

Докатились! Терпимее друг к другу.

Чтоб до такого не доходить предлагаю приводить подробные примеры и цифры, где какая архитектура будет производительне и надежнее.

Многое ясно только на экспериментах и практике.

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

Цитата

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

Хорошие идеи всегда реализовывать интересней чем плохие. Товарищи, прислушивайтесь друг к другу.

Цитата

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

Правильно. Но просто кто-то постоянно отбрасывает все идеи.


Делаем так. Чтоб не дойти до драки.

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

Но в одном треде это невозможно, появляется сильная путаница, то скатываемя на верхний уровень, то опять вниз, то к памяти, то к процессам.

З.Ы. надо что ль как-то  организованнее.

Цитата

>Предлагаю еще ознакомиться с ядром Mach
Да.. немало понаписано..
ИМХО, здесь архитектура лучше  

И так нельзя заявлять. Та архитектура хорошая и главное рабочая. Есть чему всем поучиться.

..Насчет локальных переменных в отдельной секции я немного погорячился..
Кроме как в стек их, конечно, никуда не денешь.

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

А там, где это все же делается - использовать элиасы стека.

Цитата rcz, 07.10.03, 12:11:35

Многое ясно только на экспериментах и практике.

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

Цитата

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

Сначала важно со спецификацей разобраться - от этого кардинально зависит вся реализация.

Цитата

Хорошие идеи всегда реализовывать интересней чем плохие. Товарищи

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

Цитата

Правильно. Но просто кто-то постоянно отбрасывает все идеи.

Интересно, кто это.
..Наверное, всех касается..

Цитата

Делаем так. Чтоб не дойти до драки.

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

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

Один вариант API я описал. Если есть альтернативы - приведите более-менее полные списки функций, чтобы можно было понять концепцию.

Если что-то из моего описания не понятно - можно ведь уточнить.
Многие уточнения я уже делал по ходу обсуждения.
Но заранее сделать исчерпывающее описание я не могу (интересно, кто может?!) - заранее не предусмотришь все моменты, которые со стороны непонятны.

Цитата

И так нельзя заявлять. Та архитектура хорошая и главное рабочая. Есть чему всем поучиться.

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

Цитата

..Насчет локальных переменных в отдельной секции я немного погорячился..
Кроме как в стек их, конечно, никуда не денешь.

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

Согласен. Это плохо.

Но думаю не сложно проецировать стек родителя. А надежность приложения - дело рук самого разработчика. Он сам должен понимать, что это плохо.

Цитата

Предлагаю сначала утвердить API ядра. Причем в упрощенном варианте.

Хм. Что под этим понимается. API может включать сотни функций.

Какого уровня. Если делаем ОС, логично предположить, что именно ядра. Но т.к. делаем микроядро, то надо разбить четко все обсуждение по объектам, подсистемам.

В проектировании ОС главная проблемма - непонятно с какого конца начать. С ядра или с API . Все взаимосвязанно. И что сначало пишетя. Спецификация и архитектура. По-моему архитектура и API к ней привязывается. Поэтому надо писать API, когда часть, подсистему полностью рассмотрим.

Цитата

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

Неее. Идеи плохие - всегда плохо:) . Но кто не рискует.... Просто надо быть аккуратней, все хорошо проверять. И сразу выкидывать плохие идеи.(может я консерватор)

И не стоит забывать, что все новое - хорошо забытое старое. просто надо смотреть, что уже есть, смотреть их ошибки, брать лучшее - это ведь уже будет само по себе новое.

Сообщение отредактировано: rcz - 07.10.03, 13:36

Цитата rcz, 07.10.03, 17:18:59

Но думаю не сложно проецировать стек родителя.

Не совсем просто... Но решаемо.

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

Цитата

Хм. Что под этим понимается. API может включать сотни функций.

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

Цитата

В проектировании ОС главная проблемма - непонятно с какого конца начать. С ядра или с API

С API ядра. Этим, собственно и определяется система. Реализация - сугубо технический аспект.

Цитата

Неее. Идеи плохие - всегда плохо:) . Но кто не рискует.... Просто надо быть аккуратней, все хорошо проверять. И сразу выкидывать плохие идеи.(может я консерватор)

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