Linux or Windows?

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

это смотря с какой стороны посмотреть
и как это обозвать
что вы сейчас и сделали

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

в Linux все обработчики асинхронных событий (прерываний и т. д) не являются потоками
они выполняются в контексте тех потоков, выполнение которых они прервали

никто не говорит, что Linux - это ОС реального времени
есть расширения, делающие ее таковой, но стандартное ядро не является ядром реального времени

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

к примеру
put_user()
copy_from_user()
я не скажу, что эти действия нельзя реализовать вне контекста потока, но это будет, во-первых, нелогично, а во-вторых - мы потеряем часть производительности засчет "грязных хаков"

 

UbIvItS

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

Конечно, пропустить через компилятор проще, но опять-таки -- вопрос эффективности Т.е. исходить надо из того, каковы приоритеты при разработке программы. Если переносимость стоит выше эффективности -- да, надо писать на ЯВУ, если наоборот -- на асме.

Но int или деление на нуль -- это синхронные события. В программе они происходят всегда в один и тот же момент. Такие обработчики в Линух будут потоками или же будут "нормальными" обработчиками прерываний, неподвластными планировщику?

На самом деле нормальную ОСРВ из Линуха сделать нельзя, как и из Винды. Можно сделать систему "мягкого реального времени", но это -- не то-с... Вот QNX -- это другое дело. Впрочем, к нашей теме это отношения не имеет

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

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

 

извините, та фраза была незаконченной
вот полная версия
в Linux все обработчики асинхронных (прерываний и т. д) и синхронных событий не являются потоками
они выполняются в контексте тех потоков, выполнение которых они прервали

может быть
я особо не в курсе различных типов режимов реального времени
вполне возможно, что расширения как раз реализуют "мякгий" режим работы

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

стек не может быть пустым хотя бы потому, что функция оперирует какими-то данными, которые сохраняются в стеке и продолжает ими пользоваться после возобновления работы (после выхода из режима ожидания)

 

SII

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

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

 

rei3er

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

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

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

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

 

UbIvItS

Неверно. Как возможно представить на ЯВУ даже банальный in/out? Это же машиннозависимые функции! Они зачастую непереносимы на другие платформы. Ну нету у некоторых процессоров адресного пространства ввода-вывода, и всё тут! А у некоторых вводом-выводом "заведуют" вообще вспомогательные процессоры, и центральный лишь подготавливает для них программу и даёт им команду на её выполнение. Никакого ЯВУ здесь быть не может -- слишком тесна связь со специализированными аппаратными функциями.

А представимы на ЯВУ "общечеловеческие" операции -- арифметико-логические операции, управляющие конструкции (переходы), доступ к памяти. Собственно, и всё.

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

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

 

rei3er

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

 

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

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

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

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

я не сказал, что проблемы не решаемы
они решаемы, но производительность снизиться исходя из 2-ух возможных способов реализации
1. "игра" с CR3 на время чтения/записи, побочный эффект - сброс TLB
2. преобразоание линейного адреса в физический адрес страницы (перед этим возможно, как вы уже сказали, чтение с диска), отображение ее на адресное пространство ядра и осуществление чтения/записи

 

SII

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

ну, и что с того??) I\O релизиться на асме конкретного камня и потом цепляется компилем. яву может лишь то, что заложенно в компиль, но всё что может асм - можно заложить и в возможности яву.

 

все, что может ассемблер?
к примеру
SMSW, VERR, LSL, LAR
допустим сделали built-in функции в компиляторе
smsw(), verr(), lsl(), lar()
будут ли они работать, скажем, на MIPS?
нет
наши действия?
не включать их в реализацию компилятора для MIPS
но тогда код их использующий нельзя перенести на MIPS без модификаци
в этом вся суть ЯВУ
конструкции ЯВУ абстрагируют нас от конкретной реализации инструкций имеющихся в том или ином виде на всех платформах

 

rei3er
я не говорю о реализации конкретных асм команд - речь идёт о том, чтобы яву поддерживал 5 ф-ций (#180) - и это реально, а вот об оптимальной реализации этой идеи на практике я сильно сомневаюсь, на данный момент времени)

 

Я подозреваю, почему тема не закрыта.
Тут вживую пишется книга по ОСям и языкам программирования...

 

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

 

первые 3 пункта итак есть
IRQ вообще с архитектурой имеет мало общего (или что понимается под IRQ?)
I/O как уже сказал SII может вообще не быть

 

rei3er

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

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

Можно, можно В конце концов, я же реально существующий механизм описал (с минимальными изменениями под особенности IA-32).

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

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

 

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

в большинстве случаев подкачка используется редко либо вообще не используется (при больших объемах ОЗУ)
так что чтение с диска не является ощутимым тормозом

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

 

rei3er

Не совсем понял, что тут имеется в виду: постановка нужного потока на процессор или обеспечение доступа обработчику прерывания к контексту (фактически -- памяти) этого потока?

Вот в этом я как раз не уверен, но сейчас нет времени утопиться в мануалах

 

Надо бы тему переименовать в "Pascal vs. C"

 

rei3er

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

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

 

UbIvItS

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

МультипроцессОРного или, более по-русски -- многопроцессорного. Но это тоже давным-давно решено и описано, просто на ПК это сравнительно новая тема.