OSDev

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

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

Всё понятно, - одно непонятно. Откуда цифра "8 килобайт на стек"? Сколько надо, столько и выделю. В любом случае, больше одной страницы (4 к) я бы не стал выделять на служебные поля, включая стек, на всю задачу.


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


Ну, ну, не надо так ругать создателей ранних линуксов. Ранние линуксы у меня вполне шустро вертелись в 4-8 мегабайтах памяти на 386 машине, значит не такие уж они импотенты. Конечно, линуксы обладают рядом серьёзных идеологических недоработок, но где ж вы видели идеальную ось?

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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



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



386-я машина и 4-8 мегабайт памяти -- это громадные вычислительная мощность и объём. Система же с такими возможностями, если отбросить графическую оболочку, должна без малейших тормозов работать на машине, примерно в 5 раз медленнее с точки зрения производительности, ну а памяти -- не больше 256 килобайт. (Заметьте, я не утверждаю, что Винда -- хорошо написанная система ;) ).

На самом деле, порочной в корне системой был оригинальный Уних и всё, что от него пошло расти и развиваться. Линух, хотя является типа независимым проектом, тянет за собой и "тяжкое наследие проклятого прошлого" в виде неудачной "идеологии" самой системы: г-н Торвальдс же не нормальную систему делал, а повторял Уних, если грубо говорить. Думается, сие было потому, что он в своём универе или где там именно с Унихом дело и имел, вот и взял за основу то, с чем был более-менее знаком. Ну а чтобы увидеть порочность некоей концепции, надо либо гением быть, либо иметь приличный кругозор -- а последнего у него, судя по высказываниям, что мне цитировали (касательно реализации файловых систем вне ядра), нет и сейчас...

Это лишь недостаток конкретной реализации. Мы же обсуждаем идеологию.


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


Я думаю, что любая прогрессивная система рано или поздно придёт к состоянию "тяжкого наследия". Более того, я совсем не уверен, что возможно выработать единственно правильную систему, архитектуру или какой-то алгоритм, т.к. всё время появляются какие-то новые факторы, которые тяжело или невозможно предвидеть.

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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Чем я больше узнаю Unix тем он мне больше нравится. Но это не значит что в нём все было идеальным.

Только вчера запускал эмулятор Boch с Линуксом версии 1.хх Отлично крутится на 15- 20 ИПС. Но вот памяти не смотрел сколько ест. Но само ядро весит 1.5 мегабайта думаю чистый монолит.

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

Можно ведь так дойти до ОС микроконтрольных. Где динамической памяти нет или она стековая. А что работает быстро! Где время планирования равно 0, так как выполняется во время написания программ или во время компиляции. Где всё переключение задач сводится к jmp на новую задачу. А из всей защиты только сторожевой таймер.

Зато стеки отдельные для каждой задачи позволяют переносить программу с одного процессора на другой даже во время работы в ядре. В многоядерной системе такое может дать прирост в скорости. А также организовать защиту данных разных процессов. Правда вопрос целесообразны ли такие вещи для меня открыт. Про защиту данных я вообще ничего не знаю.

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



Ещё и ещё раз. Стек ядра на каждый поток -- большой лишний расход памяти. Каждый такой стек должен иметь размер, не уступающий максимальным потребностям системы в стеке (ведь нельзя заранее сказать, когда весь этот объём понадобится). Поэтому в Линухе и отвели 8 Кбайт -- чтоб точно хватило. Но даже если отводить под собственно стек, без учёта области сохранения (она, понятное дело, одинакова при любом способе хранения), всего 1 Кбайт, то при 100 потоках получим уже 100 Кбайт, которые реально не используются, а лишь впустую занимают память. А 100 потоков -- это ерунда. В моей винде-7 сейчас, например, 965 потоков -- получается, впустую вылетит почти мегабайт. Правда, на машине с 12 Гбайтами ОЗУ это кажется несерьёзным, но это всегда отрицательно влияет как минимум на производительность (кэш не резиновый, и если единственный стек ядра с приличной вероятностью будет там находиться "хронически", поскольку используется при каждом прерывании, то вот в случае с кучей стеков ядра они будут постоянно друг друга там затирать). Кроме того, не всегда имеются машины с большим объёмом памяти.



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

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

Один стек ядра или много -- это более сложный вопрос. В случае, если ОЗУ мало (например, на микроконтроллерах, даже весьма мощных: так, 400-МГц AT91SAM9G45 имеет всего 64 Кбайта встроенного ОЗУ, куда надо ещё и саму систему с программами впихнуть, поскольку флэш-памяти у него нет -- ну или городить систему с внешней памятью, что удорожает конструкцию, увеличивает её габариты, массу и энергопотребление), много стеков ядра -- это однозначно плохо, поскольку расход памяти становится критически важным. В системах, где ОЗУ хоть залейся (современные ПК), вопрос не столь однозначный. Использование единственного стека ядра со 100% вероятностью гарантирует экономию памяти (обсуждалось выше) и практически гарантирует несколько более высокую производительность (если её не убить чем-либо другим, но будем исходить из "прочих равных") за счёт более эффективного использования кэша, а значит, уменьшения числа реальных обращений к памяти, причём, чем выше производительность процессора, тем больше выигрыш (другое дело, что освободившееся время не всегда бывает, куда деть: 6 ядер моего нынешнего халявного проца явно не шибко перетруждаются во время набора мною сего опуса :) ; кроме того, выигрыш будет отнюдь не в разы, а, может, на пару процентов -- это сильно зависит от интенсивности поступления прерываний, ведь именно тогда идёт переключение стеков). Со сложностью реализации вопрос интереснее. С одной стороны, много стеков допускают "тупой" подход: сохрани контекст в стеке, делай дальше, что хочешь, а если нужно -- вообще усыпи ядро с этим стеком и включи другой стек для обслуживания чего-то другого. Однако, с другой стороны, когда важная информация "складируется" таким неявным образом (в локальных переменных процедур, которые как раз располагаются в стеке), намного выше вероятность возникновения трудноуловимых ошибок, связанных со всякими взаимными блокировками. Например, обработчик захватил какой-то ресурс, сохранил ссылку на него в своей переменной и пошёл что-то делать дальше. В этот момент его прерывает другой обработчик и желает тяпнуть (возможно, косвенно) тот же самый ресурс -- и в результате мёртвая блокировка системы. Когда же вся информация складируется в явно выделенной для этого структуре данных, а не в обычных рабочих переменных, вероятность возникновения такой проблемы меньше: программист просто больше уделяет этому внимания (надо ж описать структуру, выделить под неё память, заполнить, освободить -- глядишь, и не забудет, что в какой-то момент надо, например, прерывания запретить). Так что, ИМХО, тут лишние "телодвижения" окупаются.



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

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

Извеняюсь вчера написал и получилось что первые 2 предложения связаны. А они совершенно о разном.
Все мы знаем о семафорах и критических секциях. Так вот они блокируют систему и пока один поток выполняется второй и N будут бесполезно крутиться в цикле. Эту задачу можно решить, причём разными путями.
Рассказываю вкратце. Основная идея заключается в том чтобы разбить данные на участки куда доступ разрешён только определённому процессору или определенным. Для примера пусть у нас есть некоторый поток команд или очередь данных. Чтобы безопасно обрабатывать очередь, её нужно заблокировать, но тогда остальные потоки не получат возможность их обрабатывать. Если очередь большая то её можно условно разделить на N потоков.
К примеру с 1 по к элемент принадлежат 1 потоку. с к по 2к второму с 2к по 3к третьему и так далее. Но такая схема имеет недостатки. Есть второй способ. Планировщик берёт всю очередь и раскидывает их по очередям принадлежащим остальным потокам. Тем самым мы решаем проблему блокировки так как данные раскиданы по отдельным очередям. И каждый поток обладает своей очередью. Теперь не нужно блокировать основную очередь... Каждому потоку не нужно блокировать свою очередь... Более того того в такой системе невозможна ошибки рода когда первый поток ждёт второго, а второй не может работать так как завис в критической секции первого.

Теперь перенесём от идеи с очереди на стек. Собственно тоже самое.

Но вот есть ли смысл делать в ядре каждому процессу по стеку или нет это ещё вопрос? Скорее всего нет, достаточно стеков пользовательского уровня. Хотя это же Линукс тут нет простых решений.