OSDev

На самом деле зависит от особенностей системы. В однопроцессорных системах а-ля RSX-11, VAX/VMS и Windows механизма отложенных обработчиков полностью достаточно для обеспечения внутренней синхронизации кода ядра. Идея в том, что первичный обработчик не может обращаться и тем более изменять общесистемные данные, т.е. он может работать только со "своими" структурами данных (например, если это обработчик прерываний от диска, то он может менять поля блока управления устройством для диска, но не более того), а вот отложенный обработчик может менять любые общесистемные данные. В частности, отложенный обработчик может менять текущий поток, а значит, отображение виртуальной памяти на физическую. Поэтому, например, при программной передаче данных между устройством и памятью сама передача выполняется в первичном обработчике (считывает данные из регистра устройства, записывает в заранее зафиксированный в физической памяти буфер и завершает прерывание), а вот завершение операции ввода-вывода делается уже в отложенном обработчике, вызываемом из первичного, когда тот обнаружил, что все данные переданы (ну или возникла ошибка, препятствующая дальнейшему выполнению операции). Отложенные же обработчики ставятся в очередь и выполняются строго последовательно, что гарантирует невозможность "левого" доступа к общесистемным данным.

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

Ну а как сделано в других системах -- это надо спрашивать у их авторов.

Вместо блокировок на важные данные, наверно можно сделать отдельной задачей монитор этих данных? Я в своей ВМ вообще хочу без прерываний обойтись, если получится.
Отдельные задачи для каждого устройства. И задача для передачи сообщений между ними. Ещё у меня ,по ходу, реального времени система. Переключение на каждый цикл ВМ.

Что значит "монитор этих данных"? Лично мне подобная формулировка абсолютно ни о чём не говорит.

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

Синхронизация доступа к своим собственным данным, простая защита от переполнения стека.

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

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

Если обработчик выполняется в нулевом кольце, то он в любом случае способен завесить всю систему. А вообще, действительно лучше, если "обвязку" вокруг обработчика, в т.ч. и посылку EOI, будет делать код ядра. Т.е. нужно максимально упростить по крайней мере API, сведя обработку прерывания в драйвере до простого вызова функции со стандартным интерфейсом.


Отложенные обработчики можно выполнять в своём собственном контексте.


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

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

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

У меня возможность выполнения отложенных обработчиков на других процессорах заложена, для чего с каждым обработчиком сопоставлена маска сродства с процессорами. Предполагается, что это позволит ускорить отложенную обработку путём приостановки выполнения потоков на других процессорах, если текущий и без того загружен отложенной обработкой. Ну а маска потребовалась из-за того, что не всякий обработчик можно отдать "налево": моя система поддерживает асимметричную многопроцессорную обработку, поскольку на АРМах асимметрия -- обычное дело (например, двухъядерные Тегры-2 на самом деле являются трёхъядерными: два ядра Cortex-A и одно ARM7TDMI, кажется -- последнее имеет куда меньший набор команд; кроме того, внешние устройства могут быть разными на разных ядрах).



А что это за зверь такой? (Чтоб с терминами определиться). Да и микроядерность -- очень растяжимое по нынешним временам понятие...

SII
Проблемы понятны, решения видны, надо думать прорабаывать. К прерываниям это не относится это проблемы паралельноси и проблемы построения защиты.

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


phantom-84

Проблема понятно. Решаема. К примеру делать обработчик отдельной задачей с высшим приоритетом. А обработку сохронения и возврата делать через механизм переключения задач.

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

Yoda
У меня скорее гибрид или химера.

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

Да, сейчас понятия часто путаются. Я подразумеваю следующую классификанию:
Монолит - все драйверы и все сервисы выполняются в пространстве ядра в нулевом кольце защиты.
Микроядро - все сервисы и очень часто драйверы (отложенная обработка) выполняются в своём собственном пространстве с пониженным приоритетом.
Считается, что эти два подхода имеют определённые недостатки, в микроядре страдает производительность, в монолите - надёжность. Поэтому многие системы пытаются "гибридизировать" эти два подхода. Гибридизация может происходить по двум направлениям. В одном случае часть функций переносят в ядро (сервисы, управление памятью, планировщик), но непосредственно драйверы оставляют в ядре. В другом случае часть драйверов работает в ядре, часть в своём пространстве.
К гибридному ядру традиционно относят Win NT, т.к. в нём графическая подсистема работает в пространстве ядра.

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

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