Асинхронная системная ловушка

Асинхронная системная ловушка ( AST ) — это механизм, используемый в нескольких компьютерных операционных системах, разработанный бывшей корпорацией Digital Equipment Corporation (DEC) из Мейнарда , штат Массачусетс .

Механизм

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

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

AST чаще всего встречаются в результате выполнения QIO вызовов ядру . Завершение ввода-вывода может быть сигнализировано выдачей AST вызывающему процессу/задаче. Определенные ошибки во время выполнения также могут сигнализироваться с помощью механизма AST. В OpenVMS специальные AST режима ядра используются в качестве стандартного механизма для получения относительно удобного доступа к контексту процесса (включая выгрузку процесса в физическую память по мере необходимости). Эти типы AST выполняются с максимально возможным приоритетом для каждого процесса в следующий раз, когда планировщик сделает этот процесс текущим, и используются, среди прочего, для получения информации на уровне процесса (в ответ на команду $GETJPI "getjob/process information"). вызов) и для выполнения удаления процесса.

Следующие операционные системы реализуют AST:

• RSX-11 (включая все варианты)
• РСТС/Э
• OpenVMS

AST примерно аналогичны Unix сигналам . Важными различиями являются:

• AST не назначаются «сигнальные коды»: вместо назначения обработчика сигнальному коду и вызова этого кода AST указывается непосредственно по его адресу. Это позволяет одновременно ожидать любое количество AST (с учетом квот на обработку).
• AST никогда не прерывают текущий системный вызов . Фактически, процесс может перейти в состояние «гибернации» (с помощью системного вызова $HIBER) или дождаться флага события, вызвав, например, $WAITFR, после чего он ничего не делает, а только ждет, пока будут установлены AST. доставленный. При доставке AST (инициируемой завершением ввода-вывода, таймером или другим событием) процесс временно выводится из режима ожидания для выполнения AST. После завершения процедуры AST вызов, переводящий процесс в режим гибернации или ожидание флага события, выполняется снова; по сути, переоценивается причина ожидания. Единственный способ выйти из этого цикла (кроме удаления процесса) — выполнить системный вызов $WAKE или $SETEF для удовлетворения ожидания. Это можно сделать самим процессом, вызвав $WAKE или $SETEF в AST или (если используется глобальный флаг события) $SETEF в другом процессе.

В VAX/VMS V4 и более поздних версиях реализована интересная оптимизация проблемы синхронизации между кодом уровня AST и кодом, не относящимся к уровню AST. Системную службу с именем $SETAST можно использовать для отключения или включения доставки AST для текущего и всех менее привилегированных режимов доступа (термин OpenVMS для функций безопасности на основе кольца ). Однако если критическая секция, нуждающаяся в защите от AST, имеет длину всего несколько инструкций, то накладные расходы на вызовы $SETAST могут значительно перевесить время на выполнение этих инструкций.

Таким образом, только для пользовательского режима (кольцо с наименьшими привилегиями, обычно используемое обычными пользовательскими программами) пара битовых флагов была предоставлена ​​в заранее определенной области памяти, доступной для записи пользователем (в пространстве «P1» для каждого процесса). Значения этих двух флагов можно истолковать как «не доставлять AST» и «AST отключены». Вместо обычной пары вызовов $SETAST код пользовательского режима будет устанавливать первый флаг перед выполнением последовательности инструкций, во время которых необходимо блокировать AST, и очищать его после последовательности. Затем (обратите внимание на порядок здесь, чтобы избежать условий гонки ) он проверит второй флаг, чтобы увидеть, был ли он установлен за это время: если да, то AST действительно стали отключенными, и следует вызвать $SETAST, чтобы снова включить их. . В наиболее распространенном случае за это время ни один AST не станет ожидающим, поэтому вообще не будет необходимости вызывать $SETAST.

Код доставки AST ядра, со своей стороны, проверит первый флаг перед попыткой доставки AST пользовательского режима; если бы он был установлен, то он напрямую установил бы бит отключения AST в блоке управления процессом (тот же бит, который будет установлен явным вызовом $SETAST из пользовательского режима), а также установил бы второй флаг перед возвратом и выходом. АСТ не доставлен.

Механизм асинхронного вызова процедур в операционных системах семейства Windows NT представляет собой аналогичный механизм.

Дальнейшее чтение

• Внутреннее устройство и структуры данных OpenVMS Alpha: планирование и управление процессами: версия 7.0, Рут Голденберг, Саро Сараванан, Дениз Дюма, ISBN   1-55558-156-0