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

Механизм, используемый в нескольких компьютерных операционных системах

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

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

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

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

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

• RSX-11 (включая все варианты)
• RSTS / E
• 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 из пользовательского режима), а также установил бы второй флаг перед возвратом и оставлением AST недоставленным.

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

• OpenVMS Alpha Internals and Data Structures: Scheduling and Process Control: Version 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas, ISBN 1-55558-156-0