Asynchronous system trap
| Industry | Computer hardware and software |
|---|---|
| Founded | November 11, 1957 |
| Fate | Acquired by Compaq in 1998 |
| Headquarters | Maynard, Massachusetts , United States |
Asynchronous system trap (AST) refers to a technique utilized in multiple operating systems originally created by the former Digital Equipment Corporation (DEC). This feature enables the invocation of subroutines asynchronously, outside the primary execution thread.
Mechanism
Within these operating systems, different events can notify user processes through ASTs, which function similarly to subroutine calls but are delivered asynchronously and independently from the main thread's state. This design mandates that:
- The code shared between the AST and the main thread must be reentrant,
- Data accessed by both must be safeguarded against corruption, often by temporarily disabling ASTs during critical sections.
ASTs frequently originate from QIO requests made to the kernel, signaling the completion of I/O operations back to the initiating process or task. Additionally, runtime exceptions may also generate ASTs. In OpenVMS, specialized kernel-mode ASTs offer privileged, high-priority access to process context, facilitating operations such as gathering process details ($GETJPI) or terminating processes.
Operating systems that incorporate AST functionality include:
While ASTs share similarities with Unix signals, they differ notably in several aspects:
- ASTs lack "signal codes" and are identified directly by their addresses, enabling multiple ASTs to be queued within defined limits.
- Unlike Unix signals, ASTs do not interrupt or abort active system calls. Processes may enter a "hibernate" state ($HIBER) or wait on event flags ($WAITFR), during which AST delivery temporarily interrupts the wait to execute handlers. The wait resumes after AST processing unless explicitly terminated through $WAKE or $SETEF system calls.
Beginning with VAX/VMS V4, synchronization between AST and non-AST execution was enhanced using the $SETAST service. This mechanism manages AST delivery based on access modes—OpenVMS's ring-based security levels. For brief critical sections in user mode, a pair of user-modifiable bit flags allow efficient prevention of AST delivery without invoking costly $SETAST calls. One flag indicates a request to block all ASTs, while the other records if blocking occurred during that period. If necessary, $SETAST is called afterward to re-enable AST processing.
Before dispatching user-mode ASTs, kernel-level delivery routines inspect these flags; if delivery is blocked, they mark corresponding bits in the process control block and postpone the AST until later.
The concept of asynchronous procedure calls in Windows NT systems serves a similar purpose.
Further reading
- OpenVMS Alpha Internals and Data Structures: Scheduling and Process Control, Version 7.0, Ruth Goldenberg, Saro Saravanan, Denise Dumas