|
|
Updated:
11 December 1998
|
OpenVMS Programming Concepts Manual
3.8.3.4 Initiating Image Rundown for Another Process
The Force Exit (SYS$FORCEX) system service provides a way for a process
to initiate image rundown for another process. For example, the
following call to SYS$FORCEX causes the image executing in the process
CYGNUS to exit:
$DESCRIPTOR(prcnam,"CYGNUS");
.
.
.
status = SYS$FORCEX(0, /* pidadr - Process id */
&prcnam, /* prcnam - Process name */
0); /* code - Completion code */
|
Because the SYS$FORCEX system service calls the SYS$EXIT system
service, any exit handlers declared for the image are executed before
image rundown. Thus, if the process is using the command interpreter,
the process is not deleted and can run another image. Because the
SYS$FORCEX system service uses the AST mechanism, an exit cannot be
performed if the process being forced to exit has disabled the delivery
of ASTs. AST delivery and how it is disabled and reenabled is described
in Chapter 5.
The following program segment shows an example of an exit-handling
routine:
#include <stdio>
#include <ssdef>
/* Exit control block */
struct {
unsigned int *desblk;
unsigned int (*exh)();
unsigned int argcount;
unsigned int *cond_value; (1)
}exitblock = {0, &exitrtn, 1, 0};
main() {
unsigned int status;
/* Declare the exit handler */
status = SYS$DCLEXH(&exitblock); (2)
if ((status & 1) != 1)
LIB$SIGNAL(status);
}
int exitrtn (int condition ) { (3)
if ((status & 1) != 1)
{
/* Clean up */
.
.
.
return 1;
}
else
/* Normal exit */
return 0;
}
|
- EXITBLOCK is the exit control block for the
exit handler EXITRTN. The third longword indicates the number of
arguments to be passed. In this example, only one argument is passed:
the address of a longword for the system to store the return status
code. This argument must be provided in an exit control block.
- The SYS$DCLEXH system service call designates
the address of the exit control block, thus declaring EXITRTN as an
exit handler.
- The EXITRTN exit handler checks the status
code. If this is a normal exit, EXITRTN returns control. Otherwise, it
handles the error condition.
3.8.4 Deleting a Process
Process deletion completely removes a process from the system. A
process can be deleted by any of the following events:
- The Delete Process (SYS$DELPRC) system service is called.
- A process that created a subprocess is deleted.
- An interactive process uses the DCL command LOGOUT.
- A batch job reaches the end of its command file.
- An interactive process uses the DCL command STOP/ID=pid or
STOP username.
- A process that contains a single image calls the Exit (SYS$EXIT)
system service.
- The Force Exit (SYS$FORCEX) system service forces image exit on a
process that contains a single image.
When the system is called to delete a process as a result of any of
these conditions, it first locates all subprocesses, and searches
hierarchically. No process can be deleted until all the subprocesses it
has created have been deleted.
The lowest subprocess in the hierarchy is a subprocess that has no
descendant subprocesses of its own. When that subprocess is deleted,
its parent subprocess becomes a subprocess that has no descendant
subprocesses and it can be deleted as well. The topmost process in the
hierarchy becomes the parent process of all the other subprocesses.
The system performs each of the following procedures, beginning with
the lowest process in the hierarchy and ending with the topmost process:
- The image executing in the process is run down. The image rundown
that occurs during process deletion is the same as that described in
Section 3.8.3.1. When a process is deleted, however, the rundown releases
all system resources, including those acquired from access modes other
than user mode.
- Resource quotas are released to the creating process, if the
process being deleted is a subprocess.
- If the creating process specifies a termination mailbox, a message
indicating that the process is being deleted is sent to the mailbox.
For detached processes created by the system, the termination message
is sent to the system job controller.
- The control region of the process's virtual address space is
deleted. (The control region consists of memory allocated and used by
the system on behalf of the process.)
- All system-maintained information about the process is deleted.
Figure 3-1 illustrates the flow of events from image exit through
process deletion.
Figure 3-1 Image Exit and Process Deletion
3.8.4.1 Deleting a Process By Using System Services
A process can delete itself or another process at any time, depending
on the restrictions outlined in Section 3.1.1. Any one of the following
system services can be used to delete a subprocess or a detached
process. Some services terminate execution of the image in the process;
others terminate the process itself.
- SYS$EXIT---Initiates normal exit in the current image. Control
returns to the command language interpreter. If there is no command
language interpreter, the process is terminated. This routine cannot be
used to terminate an image in a detached process.
- SYS$FORCEX---Initiates a normal exit on the image in the specified
process. GROUP or WORLD privilege may be required, depending on the
process specified. An AST is sent to the specified process. The AST
calls on the SYS$EXIT routine to complete the image exit. Because an
AST is used, you cannot use this routine on a suspended process. You
can use this routine on a subprocess or detached process. See
Section 3.8.3.4 for an example.
- SYS$DELPRC---Deletes the specified process. GROUP or WORLD
privilege may be required, depending on the process specified. A
termination message is sent to the calling process's mailbox. You can
use this routine on a subprocess, a detached process, or the current
process. For example, if a process has created a subprocess named
CYGNUS, it can delete CYGNUS, as follows:
$DESCRIPTOR(prcnam,"CYGNUS");
.
.
.
status = SYS$EDLPRC(0, /* Process id */
&prcnam); /* Process name */
|
Because a subprocess is automatically deleted when the image it is
executing terminates (or when the command stream for the command
interpreter reaches end of file), you normally do not need to call the
SYS$DELPRC system service explicitly.
3.8.4.2 Terminating Mailboxes
A termination mailbox provides a process with a way of determining
when, and under what conditions, a process that it has created was
deleted. The Create Process (SYS$CREPRC) system service accepts the
unit number of a mailbox as an argument. When the process is deleted,
the mailbox receives a termination message.
The first word of the termination message contains the symbolic
constant, MSG$_DELPROC, which indicates that it is a termination
message. The second longword of the termination message contains the
final status value of the image. The remainder of the message contains
system accounting information used by the job controller and is
identical to the first part of the accounting record sent to the system
accounting log file. The description of the SYS$CREPRC system service
in the OpenVMS System Services Reference Manual provides the complete format of the termination
message.
If necessary, the creating process can determine the process
identification of the process being deleted from the I/O status block
(IOSB) posted when the message is received in the mailbox. The second
longword of the IOSB contains the process identification of the process
being deleted.
A termination mailbox cannot be located in memory shared by multiple
processors.
The following example illustrates a complete sequence of process
creation, with a termination mailbox:
#include <stdio.h>
#include <descrip.h>
#include <ssdef.h>
#include <msgdef.h>
#include <dvidef.h>
#include <iodef.h>
#include <accdef.h>
unsigned short unitnum;
unsigned int pidadr;
/* Create a buffer to store termination info */
struct accdef exitmsg;
/* Define and initialize the item list for $GETDVI */
static struct { (1)
unsigned short buflen,item_code;
void *bufaddr;
void *retlenaddr;
unsigned int terminator;
}mbxinfo = { 4, DVI$_UNIT, &unitnum, 0, 0};
/* I/O Status Block for QIO */
struct {
unsigned short iostat, mblen;
unsigned int mbpid;
}mbxiosb;
main() {
void exitast(void);
unsigned short exchan;
unsigned int status,maxmsg=84,bufquo=240,promsk=0;
unsigned int func=IO$_READVBLK;
$DESCRIPTOR(image,"LYRA");
/* Create a mailbox */
status = SYS$CREMBX(0, /* prmflg (permanent or temporary) */ (2)
&exchan, /* channel */
maxmsg, /* maximum message size */
bufquo, /* no. of bytes used for buffer */
promsk, /* protection mask */
0,0,0,0);
if ((status & 1 ) != 1)
LIB$SIGNAL( status );
/* Get the mailbox unit number */
status = SYS$GETDVI(0, /* efn - event flag */ (3)
exchan, /* chan - channel */
0, /* devnam - device name */
&mbxinfo, /* item list */
0,0,0,0);
if ((status & 1 ) != 1)
LIB$SIGNAL( status );
/* Create a subprocess */
status = SYS$CREPRC(&pidadr, /* process id */
&image, /* image to be run */
0,0,0,0,0,0,0,0,
unitnum, /* mailbox unit number */
0); /* options flags */
if ((status & 1 ) != 1)
LIB$SIGNAL( status );
/* Read from mailbox */
status = SYS$QIOW(0, /* efn - event flag */ (4)
exchan, /* chan - channel number */
func, /* function modifier */
&mbxiosb, /* iosb - I/O status block */
&exitast, /* astadr - astadr AST routine */
0, /* astprm - astprm AST parameter */
&exitmsg, /* p1 - buffer to receive message*/
ACC$K_TERMLEN, /* p2 - length of buffer */
0,0,0,0); /* p3, p4, p5, p6 */
if ((status & 1 ) != 1)
LIB$SIGNAL( status );
}
void exitast(void) {
if(mbxiosb.iostat == SS$_NORMAL) (5)
{
printf("\nMailbox successfully written...");
if (exitmsg.acc$w_msgtyp == MSG$_DELPROC)
{
printf("\nProcess deleted...");
if (pidadr == mbxiosb.mbpid)
{
printf("\nPIDs are equal...");
if (exitmsg.acc$l_finalsts == SS$_NORMAL)
printf("\nNormal termination...");
else
printf("\nAbnormal termination status: %d",
exitmsg.acc$l_finalsts);
}
else
printf("\nPIDs are not equal");
}
else
printf("\nTermination message not received... status: %d",
exitmsg.acc$w_msgtyp);
}
else
printf("\nMailbox I/O status block: %d",mbxiosb.iostat);
return;
}
|
- The item list for the Get Device/Volume
Information (SYS$GETDVI) system service specifies that the unit number
of the mailbox is to be returned.
- The Create Mailbox and Assign Channel
(SYS$CREMBX) system service creates the mailbox and returns the channel
number at EXCHAN.
- The Create Process (SYS$CREPRC) system
service creates a process to execute the image LYRA.EXE and returns the
process identification at LYRAPID. The mbxunt argument
refers to the unit number of the mailbox, obtained from the Get
Device/Volume Information (SYS$GETDVI) system service.
- The Queue I/O Request (SYS$QIO) system
service queues a read request to the mailbox, specifying both an AST
service routine to receive control when the mailbox receives a message
and the address of a buffer to receive the message. The information in
the message can be accessed by the symbolic offsets defined in the
$ACCDEF macro. The process continues executing.
- When the mailbox receives a message, the AST
service routine EXITAST receives control. Because this mailbox can be
used for other interprocess communication, the AST routine does the
following:
- Checks for successful completion of the I/O operation by examining
the first word in the IOSB
- Checks that the message received is a termination message by
examining the message type field in the termination message at the
offset ACC$W_MSGTYPE
- Checks for the process identification of the process that has been
deleted by examining the second longword of the IOSB
- Checks for the completion status of the process by examining the
status field in the termination message at the offset ACC$L_FINALSTS
In this example, the AST service routine performs special action
when the subprocess is deleted.
The Create Mailbox and Assign Channel (SYS$CREMBX), Get Device/Volume
Information (SYS$GETDVI), and Queue I/O Request (SYS$QIO) system
services are described in greater detail in Chapter 11.
Chapter 4
Symmetric Multiprocessing (SMP) Systems
4.1 Introduction to Symmetric Multiprocessing
OpenVMS Alpha supports tightly coupled symmetric multiprocessing (SMP).
This chapter presents a brief overview of symmetric multiprocessing
terms and characteristics. For more information about SMP concepts and
hardware configurations, refer to OpenVMS AXP Internals and Data Structures.
A multiprocessing system consists of two or more CPUs that address
common memory and that can execute instructions simultaneously. If all
CPUs in the system execute the same copy of the operating system, the
multiprocessing system is said to be tightly coupled. If all CPUs have
equal access to memory, interrupts, and I/O devices, the system is said
to be symmetric.
In most respects the members of an OpenVMS SMP system are symmetric.
Each member can perform the following tasks:
- Initiate an I/O request
- Service exceptions
- Service software interrupts
- Service hardware interrupts, such as interprocessor and interval
timer interrupts
- Execute process context code in any access mode
4.2 CPU Characteristics of an SMP System
The members of an SMP system are characterized in several ways. One
important characteristic is that of primary CPU. During system
operation the primary CPU has several unique responsibilities for
system timekeeping, writing messages to the console terminal, and
accessing any other I/O devices that are not accessible to all members.
Although the hardware and software permit device interrupts to be
serviced by any processor, in practice all device interrupts are
serviced on the primary CPU. An SMP configuration may include some
devices that are not accessible from all SMP members. The console
terminal, for example, is accessible only from the primary processor.
4.2.1 Booting an SMP System
Booting the system is initiated on a CPU with full access to the
console subsystem and terminal, called the BOOT CPU. The BOOT CPU
controls the bootstrap sequence and boots the other available CPUs. On
OpenVMS Alpha systems, the BOOT CPU and the primary CPU are always the
same; the others are called secondary processors.
The booted primary and all currently booted secondary processors are
called members of the active set. These processors actively participate
in system operations and respond to interprocessor interrupts, which
coordinate systemwide events.
4.2.2 Interrupt Requests on SMP System
In an SMP system, each processor services its own software interrupt
requests, of which the most significant are the following:
- When a current Kernel thread is preempted by a higher priority
computable resident thread, the IPL 3 rescheduling interrupt service
routine, running on that processor, takes the current thread out of
execution and switches to the higher priority Kernel thread.
- When a device driver completes an I/O request, an IPL 4 I/O
postprocessing interrupt is requested: some completed requests are
queued to a CPU-specific postprocessing queue and are serviced on that
CPU; others are queued to a systemwide queue and serviced on the
primary CPU.
- When the current Kernel thread has used its quantum of CPU time,
the software timer interrupt service routine, running on that CPU,
performs quantum-end processing.
- Software interrupts at IPLs 6 and 8 through 11 are requested to
execute fork processes. Each processor services its own set of fork
queues. A fork process generally executes on the same CPU from which it
was requested. However, since many fork processes are requested from
device interrupt service routines, which currently execute only on the
primary CPU, more fork processes execute on the primary than on other
processors.
4.3 Symmetric Multiprocessing Goals
SMP supports the following goals:
- One version of the operating system. As part of the standard
OpenVMS Alpha product, SMP support does not require its own version.
The same OpenVMS version runs on all Alpha processors. The
synchronization methodology and the interface to synchronization
routines are the same on all systems. However, as described in
OpenVMS AXP Internals and Data Structures, there are different versions of the synchronization
routines themselves in different versions of the executive image that
implements synchronization. Partly for that reason, SMP support imposes
relatively little additional overhead on a uniprocessor system.
- Parallelism in kernel mode. SMP support might have been implemented
such that any single processor, but not more than one at a time, could
execute kernel mode code. However, more parallelism was required for a
solution that would support configurations with more CPUs. The members
of an SMP system can be executing different portions of the Executive
concurrently.
The executive has been divided into different
critical regions, each with its own lock, called a spinlock. A spinlock
is one type of system synchronization element that guarantees atomic
access to the functional divisions of the Executive using Alpha
architecture instructions specifically designed for multi-processor
configurations. Two sections in Chapter 16, Section 16.4 and
Section 16.5 describe both the underlying architecture and software
elements that provide this level of SMP synchronization.
The
spinlock is the heart of the SMP model, allowing system concurrency at
all levels of the operating system. All components that want to benefit
from multiple-CPU configurations must incorporate these elements to
guarantee consistency and correctness. Device drivers, in particular,
use a variant of the static system spinlock (a devicelock) to ensure
its own degree of synchronization and ownership within the system.
- Symmetric scheduling mechanisms. The standard, default behavior of
the operating system is to impose as little binding between system
executable entities and specific CPUs in the active set as possible.
That is, in general, each CPU is equally able to execute any Kernel
thread. The multi-processor scheduling algorithm is an extension of the
single-CPU behavior, providing consistent preemption and real-time
behavior in all cases.
However, there are circumstances when an
executable Kernel thread needs system resources and services possessed
only by certain CPUs in the configuration. In those non-symmetric
cases, OpenVMS provides a series of privileged, system-level CPU
scheduling routines that supersede the standard scheduling mechanisms
and bind a Kernel thread to one or more specific CPUs. System
components that are tied to the primary CPU, such as system timekeeping
and console processing, use these mechanisms to guarantee their
functions are performed in the correct context. Also, because the Alpha
hardware architecture shows significant performance benefits for Kernel
threads run on CPUs where the hardware context has been preserved from
earlier execution, the CPU scheduling mechanisms have been introduced
in OpenVMS Alpha Version7.0 as a series of system services and user
commands. Through the use of explicit CPU affinity and user
capabilities, an application can be placed throughout the active set to
take advantage of the hardware context. Chapter 3 in Section 3.4
describes these features in greater detail.