Асинхронная системная ловушка ( AST ) относится к механизму, используемому в нескольких компьютерных операционных системах, разработанных бывшей Digital Equipment Corporation (DEC) из Мейнарда , Массачусетс .
Механизм
Различные события в пределах этих систем может быть необязательно сигнал обратно в пользовательских процессов с помощью механизма AST. Эти AST действуют как вызовы подпрограмм, но доставляются асинхронно , то есть независимо от контекста основного потока. Из-за этого необходимо соблюдать осторожность:
- чтобы гарантировать, что любой код, который используется совместно основным потоком и AST, должен быть реентерабельным , и
- любые данные, которые передаются, должны быть защищены от повреждения в случае их изменения AST в любое время. В противном случае данные должны быть защищены путем блокировки AST во время критических секций .
AST чаще всего встречаются в результате выполнения вызовов QIO к ядру . О завершении ввода-вывода может сигнализировать выдача AST вызывающему процессу / задаче. О некоторых ошибках времени выполнения можно также сигнализировать с помощью механизма AST. В OpenVMS специальные AST режима ядра используются в качестве стандартного механизма для получения относительно удобного доступа к контексту процесса (включая подкачку процесса в физическую память, если это необходимо). Эти типы AST выполняются с максимально возможным приоритетом для каждого процесса в следующий раз, когда планировщик делает этот процесс текущим, и используются, среди прочего, для получения информации на уровне процесса (в ответ на систему $ GETJPI "getjob / process information" вызов) и для выполнения удаления процесса.
Следующие операционные системы реализуют AST:
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