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

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

Механизм

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

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

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

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

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

  • Для 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 из пользовательского режима), а также установить второй флаг перед возвратом и оставлением AST недоставленным.

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

Рекомендации

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

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