Comments 6
DPC были ещё в RSX-11M, оттуда они перешли в VAX/VMS и потом в WinNT.
Смысл DPC — не в легковесной поддержке тредов. Наоборот, это обработчик прерываний, вызваемый не из самого прерывания, а чуть погодя.
Идея состоит в том, что на PDP-11 нужно было как можно быстрее выйти из прерывания, ибо в режиме прерывания другие прерывания заблокированы (стек маленький, его берегли). Поэтому в прерывании делали абсолютный минимум — считывали то, что разрушалось при выходе из прерывания и ставили в очередь DPC. Дальше адрес выхода из прерывания подменялся на вход в обработтчик очереди DPC.
То есть в большинстве случаев (кроме прерывания, произошедших во время нахождения в некоторых процедурах ядра) DPC обрабатывался синхронно, просто с открытыми прерываниями.
Был ещё промежуточный уровень — когда открыты более приоритетные прерывания, но не может ещё раз произойти то прерывание, по которому мы уже прерывались. Не помню, как этот режим звался.
Все это нужно было для того, чтобы пересылать байты на бешенной по тем временам скорости 38400 бод, то есть с прерываниями раз в 300 микросекунд. FIFO тогда не было, и малейшая задержка с закрытыми прерываниями приводила к потере байта
Смысл DPC — не в легковесной поддержке тредов. Наоборот, это обработчик прерываний, вызваемый не из самого прерывания, а чуть погодя.
Идея состоит в том, что на PDP-11 нужно было как можно быстрее выйти из прерывания, ибо в режиме прерывания другие прерывания заблокированы (стек маленький, его берегли). Поэтому в прерывании делали абсолютный минимум — считывали то, что разрушалось при выходе из прерывания и ставили в очередь DPC. Дальше адрес выхода из прерывания подменялся на вход в обработтчик очереди DPC.
То есть в большинстве случаев (кроме прерывания, произошедших во время нахождения в некоторых процедурах ядра) DPC обрабатывался синхронно, просто с открытыми прерываниями.
Был ещё промежуточный уровень — когда открыты более приоритетные прерывания, но не может ещё раз произойти то прерывание, по которому мы уже прерывались. Не помню, как этот режим звался.
Все это нужно было для того, чтобы пересылать байты на бешенной по тем временам скорости 38400 бод, то есть с прерываниями раз в 300 микросекунд. FIFO тогда не было, и малейшая задержка с закрытыми прерываниями приводила к потере байта
Непонятно, зачем для этого новое понятие. Открыть прерывания в драйвере можно и так. Или выставить новый level — многие юниксовые драйвера так и делали, открывая прерывания для своего и более высоких уровней приоритета.
Почему же? Все понятно.
1) С DPC мы получали существенное ускорение за счет одновременной обработки множества прерываний от одного или нескольких однотипных устройств.
2) DPC вызывается, когда таблицы ядра консистентны. То есть прерывание может произойти во время изменения таблиц ядра, а DPC — нет.
Ещё раз. Как происходит обработка при бешенном потоке в 38400 бод (3840 прерываний в секунду) при скорости процессора 300 тысяч операций в секунду. И это — без FIFO.
1) Прерывание
1.1) Считали в регистр принятый байт
1.2) Разрешили вышестоящие прерывания
1.3) Записали принятый байт в DCB (device control block). памяти там немного, но 16 байт для программного FIFO найдется
1.4) Добавили DPC в очередь (если его ещё там не было)
2) DPC вызывает при выходе из прерывания (если были в режиме пользователя). Или при выходе из ядра (если были в режиме ядра)
3) DPC пробегает DCB всех устройств данного типа и организовывает передачу байт в буфера ядра или прямо в программу пользователя. При этом делаются медленные операции маппинга памяти и кучи разбора системных таблиц.
1) С DPC мы получали существенное ускорение за счет одновременной обработки множества прерываний от одного или нескольких однотипных устройств.
2) DPC вызывается, когда таблицы ядра консистентны. То есть прерывание может произойти во время изменения таблиц ядра, а DPC — нет.
Ещё раз. Как происходит обработка при бешенном потоке в 38400 бод (3840 прерываний в секунду) при скорости процессора 300 тысяч операций в секунду. И это — без FIFO.
1) Прерывание
1.1) Считали в регистр принятый байт
1.2) Разрешили вышестоящие прерывания
1.3) Записали принятый байт в DCB (device control block). памяти там немного, но 16 байт для программного FIFO найдется
1.4) Добавили DPC в очередь (если его ещё там не было)
2) DPC вызывает при выходе из прерывания (если были в режиме пользователя). Или при выходе из ядра (если были в режиме ядра)
3) DPC пробегает DCB всех устройств данного типа и организовывает передачу байт в буфера ядра или прямо в программу пользователя. При этом делаются медленные операции маппинга памяти и кучи разбора системных таблиц.
Может быть так и нужно проектировать современную операционную систему как слой, который изолирован от железа, т.е. концептуальные вещи ничего не знающие о железе? И тогда эта ось сможет работать на любом желе ну или почти на любом.
существует штатная поддержка запуска кода внутри «лёгких» нитей — Deferred Procedure Call
Это неверно, «нити» тут ни при чем.
Sign up to leave a comment.
Драйверы умного или виртуального железа