|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
 |
 |
HP OpenVMS systems documentation |
|
| Previous | Contents | Index |
Before kernel threads, OpenVMS implemented AST preemptions in inner modes as follows:
After kernel threads, in contrast to the preceeding list, kernel
threads deliver any non thread-safe inner mode ASTs to the kernel
thread that already owns the semaphore. If no thread currently owns the
semaphore when the AST is queued, then the semaphore is acquired in
SCH$QAST, and the owner is set to the target kernel thread for that
AST. Subsequently queued ASTs see that thread as the semaphore owner
and are delivered to that thread. This allows the PALcode and the
hardware architecture to process all the AST preemption and ordering
rules.
8.8 ASTs and Process Wait States
A process in a wait state can be interrupted for the delivery of an AST and the execution of an AST service routine. When the AST service routine completes execution, the process is returned to the wait state, if the condition that caused the wait is still in effect.
With the exception of suspended waits (SUSP) and suspended outswapped
waits (SUSPO), any wait states can be interrupted.
8.8.1 Event Flag Waits
If a process is waiting for an event flag and is interrupted by an AST, the wait state is restored following execution of the AST service routine. If the flag is set at completion of the AST service routine (for example, by completion of an I/O operation), then the process continues execution when the AST service routine completes.
Event flags are described in Section 6.8 of Chapter 6.
8.8.2 Hibernation
A process can place itself in a wait state with the Hibernate (SYS$HIBER) system service. This state can be interrupted for the delivery of an AST. When the AST service routine completes execution, the process continues hibernation. The process can, however, "wake" itself in the AST service routine or be awakened either by another process or as the result of a timer-scheduled wakeup request. Then, it continues execution when the AST service routine completes.
Process suspension is another form of wait; however, a suspended
process cannot be interrupted by an AST. Process hibernation and
suspension are described in Chapter 4.
8.8.3 Resource Waits and Page Faults
When a process is executing an image, the system can place the process
in a wait state until a required resource becomes available, or until a
page in its virtual address space is paged into memory. These waits,
which are generally transparent to the process, can also be interrupted
for the delivery of an AST.
8.9 Examples of Using AST Services
The following is an example of an HP Fortran program that finds the process identification (PID) number of any user working on a particular disk and delivers an AST to a local routine that notifies the user that the disk is coming down:
PROGRAM DISK_DOWN
! Implicit none
! Status variable
INTEGER STATUS
STRUCTURE /ITMLST/
UNION
MAP
INTEGER*2 BUFLEN,
2 CODE
INTEGER*4 BUFADR,
2 RETLENADR
END MAP
MAP
INTEGER*4 END_LIST
END MAP
END UNION
END STRUCTURE
RECORD /ITMLST/ DVILIST(2),
2 JPILIST(2)
! Information for GETDVI call
INTEGER PID_BUF,
2 PID_LEN
! Information for GETJPI call
CHARACTER*7 TERM_NAME
INTEGER TERM_LEN
EXTERNAL DVI$_PID,
2 JPI$_TERMINAL
! AST routine and flag
INTEGER AST_FLAG
PARAMETER (AST_FLAG = 2)
EXTERNAL NOTIFY_USER
INTEGER SYS$GETDVIW,
2 SYS$GETJPI,
2 SYS$WAITFR
! Set up for SYS$GETDVI
DVILIST(1).BUFLEN = 4
DVILIST(1).CODE = %LOC(DVI$_PID)
DVILIST(1).BUFADR = %LOC(PID_BUF)
DVILIST(1).RETLENADR = %LOC(PID_LEN)
DVILIST(2).END_LIST = 0
! Find PID number of process using SYS$DRIVE0
STATUS = SYS$GETDVIW (,
2 ,
2 '_MTA0:', ! device
2 DVILIST, ! item list
2 ,,,)
IF (.NOT. STATUS) CALL LIB$SIGNAL (%VAL(STATUS))
! Get terminal name and fire AST
JPILIST(1).CODE = %LOC(JPI$_TERMINAL)
JPILIST(1).BUFLEN = 7
JPILIST(1).BUFADR = %LOC(TERM_NAME)
JPILIST(1).RETLENADR = %LOC(TERM_LEN)
JPILIST(2).END_LIST = 0
STATUS = SYS$GETJPI (,
2 PID_BUF, !process id
2 ,
2 JPILIST, !itemlist
2 ,
2 NOTIFY_USER, !AST
2 TERM_NAME) !AST arg
IF (.NOT. STATUS) CALL LIB$SIGNAL(%VAL(STATUS))
! Ensure that AST was executed
STATUS = SYS$WAITFR(%VAL(AST_FLAG))
IF (.NOT. STATUS) CALL LIB$SIGNAL(%VAL(STATUS))
END
SUBROUTINE NOTIFY_USER (TERM_STR)
! AST routine that broadcasts a message to TERMINAL
! Dummy argument
CHARACTER*(*) TERM_STR
CHARACTER*8 TERMINAL
INTEGER LENGTH
! Status variable
INTEGER STATUS
CHARACTER*(*) MESSAGE
PARAMETER (MESSAGE =
2 'SYS$TAPE going down in 10 minutes')
! Flag to indicate AST executed
INTEGER AST_FLAG
! Declare system routines
INTRINSIC LEN
INTEGER SYS$BRDCST,
2 SYS$SETEF
EXTERNAL SYS$BRDCST,
2 SYS$SETEF,
2 LIB$SIGNAL
! Add underscore to device name
LENGTH = LEN (TERM_STR)
TERMINAL(2:LENGTH+1) = TERM_STR
TERMINAL(1:1) = '_'
! Send message
STATUS = SYS$BRDCST(MESSAGE,
2 TERMINAL(1:LENGTH+1))
IF (.NOT. STATUS) CALL LIB$SIGNAL(%VAL(STATUS))
! Set event flag
STATUS = SYS$SETEF (%VAL(AST_FLAG))
IF (.NOT. STATUS) CALL LIB$SIGNAL(%VAL(STATUS))
END
|
The following is an example of a C program setting up an AST:
#module SETAST "SRH X1.0-000"
#pragma builtins
/*
**++
** Facility:
**
** Examples
**
** Version: V1.0
**
** Abstract:
**
** Example of working with the $SETAST call and ASTs.
**
** Author:
** Steve Hoffman
**
** Creation Date: 1-Jan-1990
**
** Modification History:
**--
*/
/*
* AST and $SETAST demo
* raise the AST shields
* request an AST, parameter is 1
* request an AST, parameter is 2
* lower the shields
* <bing1><bing2>
*/
main()
{
int retstat = 0;
int bogus();
int SYS$SETAST();
int SYS$DCLAST();
printf("\ndisabling\n");
/*
* $SETAST() returns SS$_WASSET and SS$_WASCLR depending
* on the previous setting of the AST shield. Watch out,
* SS$_WASSET looks like a SUCCESSFUL SS$_ACCVIO. (ie:
* a debug EXAMINE/COND shows SS$_WASSET as the error
* %SYSTEM-S-ACCVIO. *Real* ACCVIO's never have the "-S-"
* code!)
*/
retstat = SYS$SETAST( 0 );
printf("\n disable/ was: %d\n", retstat );
retstat = SYS$DCLAST( bogus, 1, 0 );
retstat = SYS$DCLAST( bogus, 2, 0 );
printf("\ndclast %x\n", retstat );
printf("\nenabling\n" );
retstat = SYS$SETAST( 1 );
/*
* and, since we just lowered the shields, the ASTs should hit
* in here somewhere....
*/
printf("\n enable/ was: %d\n", retstat );
return( 1 );
};
/*
* and, here's the entire, sophisticated, twisted AST code...
*/
bogus( astprm )
int astprm;
{
printf("\nAST tripped. ast parameter was 0x%x\n\n", astprm);
return( 1 );
};
|
This chapter describes the OpenVMS Condition Handling facility and contains the following sections:
Section 9.1 gives an overview of run-time errors.
Section 9.2 gives an overview of the OpenVMS Condition Handling facility, presenting condition-handling terminology and functionality.
Section 9.3 describes VAX, Alpha, and I64 system exceptions, arithmetic exceptions, and unaligned access traps on Alpha and I64 systems.
Section 9.4 describes how run-time library routines handle exceptions.
Section 9.5 describes the condition value field and the testing and modifying of values.
Section 9.6 describes the exception dispatcher.
Section 9.7 describes the argument list that is passed to a condition handler.
Section 9.8 describes signaling.
Section 9.9 describes types of condition handlers.
Section 9.10 describes types of actions performed by condition handlers.
Section 9.11 describes messages and how to use them.
Section 9.12 describes how to write a condition handler.
Section 9.13 describes how to debug a condition handler.
Section 9.14 describes several run-time library routines that can be established as condition handlers.
Section 9.15 describes how to establish, write, and debug an exit
handler.
9.1 Overview of Run-Time Errors
Run-time errors are hardware- or software-detected events, usually errors, that alter normal program execution. Examples of run-time errors are as follows:
When an error occurs, the operating system either returns a condition code or value identifying the error to your program or signals the condition code. If the operating system signals the condition code, an error message is displayed and program execution continues or terminates, depending on the severity of the error. See Section 9.5 for details about condition values.
When unexpected errors occur, your program should display a message identifying the error and then either continue or stop, depending on the severity of the error. If you know that certain run-time errors might occur, you should provide special actions in your program to handle those errors.
Both an error message and its associated condition code identify an error by the name of the facility that generated it and an abbreviation of the message text. Therefore, if your program displays an error message, you can identify the condition code that was signaled. For example, if your program displays the following error message, you know that the condition code SS$_NOPRIV was signaled:
%SYSTEM-F-NOPRIV, no privilege for attempted operation |
The operating system provides a set of signaling and condition-handling routines and related system services to handle exception conditions. This set of services is called the OpenVMS Condition Handling facility (CHF). The OpenVMS Condition Handling Facility is a part of the common run-time environment of OpenVMS, which includes run-time library (RTL) routines and other components of the operating system.
The OpenVMS Condition Handling facility provides a single, unified method to enable condition handlers, signal conditions, print error messages, change the error behavior from the system default, and enable or disable detection of certain hardware errors. The RTL and all layered products of the operating system use the CHF for condition handling.
See the HP OpenVMS Calling Standard for a detailed description of OpenVMS condition
handling.
9.2.1 Condition-Handling Terminology
This section defines the terms used to describe condition handling.
exception
An event detected by the hardware or software that changes the normal flow of instruction execution. An exception is a synchronous event caused by the execution of an instruction and often means something generated by hardware. When an exception occurs, the processor transfers control by forcing a change in the flow of control from that explicitly indicated in the currently executing process.Some exceptions are relevant primarily to the current process and normally invoke software in the context of the current process. An integer overflow exception detected by the hardware is an example of an event that is reported to the process. Other exceptions, such as page faults, are handled by the operating system and are transparent to the user.
An exception may also be signaled by a routine (software signaling) by calling the RTL routines LIB$SIGNAL or LIB$STOP.
condition
An informational state that exists when an exception occurs. Condition is a more general term than exception; a condition implies either a hardware exception or a software-raised condition. Often, the term condition is preferred because the term exception implies an error. Section 9.3.1 further defines the differences between exceptions and conditions.condition handling
When a condition is detected during the execution of a routine, a signal can be raised by the routine. The routine is then permitted to respond to the condition. The routine's response is called handling the condition.On VAX systems, an address of 0 in the first longword of a procedure call frame or in an exception vector indicates that a condition handler does not exist for that call frame or vector.
On Alpha systems, the handler valid flag bit in the procedure descriptor is cleared to indicate that a condition handler does not exist.
On I64 systems, the handler present flag bit in the frame flags field of the invocation context block indicates the presence of a condition handler.
The condition handlers are themselves routines; they have their own call frames. Because they are routines, condition handlers can have condition handlers of their own. This allows condition handlers to field exceptions that might occur within themselves in a modular fashion.
On VAX systems, a routine can enable a condition handler by placing the address of the condition handler in the first longword of its stack frame.
On Alpha and I64 systems, the association of a handler with a procedure is static and must be specified at the time a procedure is compiled (or assembled). Some languages that lack their own exception-handling syntax, however, may support emulation of dynamic specified handlers by means of built-in routines.
If you determine that a program needs to be informed of particular exceptions so it can take corrective action, you can write and specify a condition handler. This condition handler, which receives control when any exception occurs, can test for specific exceptions.
If an exception occurs and you have not specified a condition handler, the default condition handler established by the operating system is given control. If the exception is a fatal error, the default condition handler issues a descriptive message and causes the image that incurred the exception to exit.
To declare or enable a condition handler, use the following system services:
Parallel mechanisms exist for uniform dispatching of hardware and software exception conditions. Exceptions that are detected and signaled by hardware transfer control to an exception service routine in the executive. Software-detected exception conditions are generated by calling the run-time library routines LIB$SIGNAL or LIB$STOP. Hardware- and software-detected exceptions eventually execute the same exception dispatching code. Therefore, a condition handler may handle an exception condition generated by hardware or by software identically.
The Set Exception Vector (SYS$SETEXV) system service allows you to
specify addresses for a primary exception handler, a secondary
exception handler, and a last-chance exception handler. You can specify
handlers for each access mode. The primary exception vector is reserved
for the debugger. In general, you should avoid using these vectored
handlers unless absolutely necessary. If you use a vectored handler, it
must be prepared for all exceptions occurring in that access mode.
9.2.2 Functions of the Condition Handling Facility
The OpenVMS Condition Handling facility and the related run-time library routines and system services perform the following functions:
MOVAB HANDLER,(FP) |
INTEGER*4 OLD_HANDLER EXTERNAL ERRLOG . . . OLD_HANDLER = LIB$ESTABLISH (ERRLOG) |
CALL LIB$ESTABLISH (OLD_HANDLER) |
| Previous | Next | Contents | Index |