ANSI INCITS TR 7-1989 Information Processing Systems Technical Report User Documentation for Consumer Software Packages.pdf

《ANSI INCITS TR 7-1989 Information Processing Systems Technical Report User Documentation for Consumer Software Packages.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS TR 7-1989 Information Processing Systems Technical Report User Documentation for Consumer Software Packages.pdf（36页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI INCITS TR-7-1989(formerly ANSI X3/TR-7-1989)Information Processing SystemsTechnical ReportUser Documentation for ConsumerSoftware PackagesX3s Technical Report Series This Technical Report is one in a series produced by the American National Standards Committee, X3, Information Processing System

2、s. The Secretariat for X3 is held by the Computer and Business Equipment Manufacturers Association (CBEMA), 311 First St. NW, Suite 500, Washington, DC 20001-2178. As a by-product of the standards development process and the resources of knowledge devoted to it, X3 from time to time produces Technic

3、al Reports. Such Technical Reports are not standards, nor are they intended to be used as such. X3 Technical Reports are produced in some cases to disseminate the technical and logical concepts reflected in standards already published or under development. In other cases, they derive from studies in

4、 areas where it is found premature to develop a standard due to a still changing technology, or inappropriate to develop a rigorous standard due to the existance of a number of viable options, the choice of which depends on the users particular requirements. These Technical Reports, thus, provide gu

5、idelines, the use of which can result in greater consistency and coherence of information processing systems. When the draft Technical Report is completed, the Technical Committee approval process is the same as for a draft standard. Processing by X3 is also similar to that for a draft standard. ii

6、TABLE OF CONTENTS 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Explanation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Overview 2 2.1.1 Scope of Extensions 2 2.1.2 Concepts and Terminology 2 2.2. Job Structure . 4 2.2.1 Attributes and Scope Rules . 4 2.2.2 Task Structure 5 2.2.3 Task States 6 2.2.4 Task Termination 6 2.2.5 Discussion 7

8、 2.3. Protection of Shared Variables 8 2.3.1 The LOCK Statement . 9 2.3.2 Lock States 10 2.3.3 Rules For Shared Variables . 10 2.3.4 Discussion . 11 2.4. Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9、 . . . . . . . . . . . . 12 2.5. Synchronization and Scheduling . 12 2.5.1 Events and Event-lists . 12 2.5.2 The WAIT Statement 13 2.5.3 The SCHEDULE Statement . 15 2.5.4 Signals and On-units 17 2.6 Input/Output 17 2.6.1 Device I/O . 17 2.6.2 Shared Files 19 2.6.3 Shared Records . 20 2.6.4 Extra-Lin

10、gual File Sharing . 20 3. Language Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1 Attributes . 21 3.1.1 PROGRAM . 21 3.1.2 SHARED . 21 3.1.3 SHAREDRECORDS 22 3.2. Statements 22 3.2.1 ABOR

11、T 22 3.2.2 CONNECT . 23 3.2.3 DISCONNECT 23 3.2.4 LOCK . 24 3.2.5 SCHEDULE 25 3.2.6 WAIT 27 . . . Ill 3.3. Built-in Functions . 27 3.3.1 ABANDONED 27 3.3.2 ADDINTERVAL . 28 3.3.3 DATETIME . 28 3.3.4 DELAY 28 3.3.5 INTERVAL . 29 3.3.6 PRIORITY 29 3.3.7 RECORD . 29 3.4 Pseudo-variable 30 3.4.1 PRIORIT

12、Y 30 iv 1. Introduction This document presents extensions to American National Standard programming language PL/I, as defmed by ANSI X3.53-1976, and to its general-purpose subset, as defined by ANSI X3.74-1981. The language exten- sions are specifically designed for real-time applications including

13、the most demanding industrial applica- tions. The extensions will also be effective tools in other applications such as transaction processing. They are not, however, designed for use in implementing the fundamental components of an operating system. Expanding the design to accommodate this speciali

14、zed usage would degrade its value in real-time applications. The extensions are specifically intended for the PL/I programming language, but the concepts underlying the language features are, for the most part, language-independent. In particular, the treatment of tasking, shared variables, and sync

15、hronization should be of general interest. Section 2 introduces this material infor- mally; reading it does not require PL/I expertise. The extensions rely on only a few features of the PL/I language. The only required data types are integer, Boolean, and character. The extensions require neither a

16、real-time operating system nor an extensive run- time library for their operation, but it is expected that an implementation would interface to and exploit the capabilities of an appropriate operating system. This document is the final version of an ANSI Technical Committee X3J1.4 working document.

17、It contains a specification of the extensions developed through formal procedures by the committee and an appendix which discusses the issues remaining unresolved when the committee finished its formal work. The exten- sions are not part of any standard or proposed standard. Many of the unresolved i

18、ssues exist because of the lack of implementation experience with the various alternatives. This document is being published to stimulate interest in the extensions and to guide pioneers in their implementation. The committee expressly solicits accounts of implementation experiences, for it is only

19、through such feedback that the remaining issues can be resolved. Comments should be sent to X3Jl in care of American National Standards Institute 1430 Broadway, New York, NY 10018 1 2. Explanation 2.1 Overview 2.1.1 Scope of Extensions The language extensions defined in this paper are designed to pr

20、ovide: 1. The ability for multiple PL/I programs to share variables and files in a manner which ensures that all shared objects always have a consistent state. The sharing mechanism is designed so that by following a very simple discipline, a real-time applications programmer can ensure that the sys

21、tem will not contain potential deadlocks. 2. The ability for a program to schedule the execution of another program, hereinafter called a task Each task can be given a set of arguments and a priority. Furthermore, tasks can be created and scheduled to respond to the occurrence of specific events. Ea

22、ch task has a lifetime that is inde- pendent of the lifetime of any other task. 3. The ability for a task to delay its own execution until a specific event has occurred. 4. The ability for a task to abort itself or any other task leaving the machine in a well-defined state. 5. The ability for a task

23、 to respond to asynchronous interrupts and/or data transmissions from devices. All of the above capabilities are defined in a machine-independent manner and can be implement- ed on any computer that has a timer or clock that can be set to interrupt at a specified time or time interval. 2.1.2 Concept

24、s and Terminology A prqgram is a set of external procedures. The PL/I standard defines the effect of executing a single pro- gram. In practice that execution might interact with other simultaneous program executions (via I/O), but such interaction is outside the scope of the standard. There is no pa

25、rallelism within a program execution. The real-time extensions introduce the notion of ajob, which is the execution of a set of related programs. A single program execution within the job is called a tusk. In one job there may be any number (including zero) of tasks executing a particular program. T

26、here is no hierarchical relationship between tasks; the pro- grammer may arrange their initiation and termination in any manner that is appropriate for the application. IIn PL/I an external procedure is a procedure that is not textually nested inside any other procedure. It is the natural unit for s

27、epar- ate compilation. An entry point of an external procedure is an exkrnal entry point. 2 Tasks communicate with each other through shared variables which, within a job, are known to all tasks whose programs declare them. A special form of communication is provided by the WAIT statement, which is

28、useful for synchronization. Examples: WAIT (INPUT-EVENT); /* Wait until the shared Boolean l / /* variable INPUT-EVENT has the l / /* value 1 B (true). */ WAIT (COUNTER = 0); /* Wait until shared variable /* COUNTER has been counted down /* to zero. */ */ */ Synchronization with events in the extern

29、al world is handled by connecting a shared variable to a device, for example, CONNECT FLAG TO (DEVICE INTERRUPT); /* Connect the /* Boolean shared variable FLAG /* to a particular device /* interrupt. l / */ */ */ WAIT (FLAG) /* Wait for the device interrupt /* to occur. Events related to date and t

30、ime may be directly specified in a WAIT statement, for example, WAIT(TIME = TIMEOUT); and a WAIT statement may specify a list of events, for example, WAIT(FLAG, COUNTER = 0, TIME = TIMEOUT); The task waits until one of the events has occurred. */ In addition to variables, whole files and the individ

31、ual records of certain files may be shared. All of these are called shared objects. Except in special synchronization statements, a task may not access a shared object unless the task has locked the object. This locking mechanism prevents one task from modifying a shared object at the same time anot

32、her task is reading or modifying it. It is possible for several tasks to simultane- ously read a shared object. 3 2.2 Job Structure A job consists of the following: a) a set of one or more programs, b) a set of one or more tasks, and c) storage for variables and fne constants that have job-scope (se

33、e below). Initialization of a job initializes job-level storage, creates a task for one of the jobs procedures, and places that task in the executing state. The means for collecting the programs of a job, specifying the initial pro- gram, and specifying the initial entry point within that program ar

34、e all implementation-defined. Any task in a job may create another task by means of a SCHEDULE statement (discussed in detail later). For example, SCHEDULE REPORT WHEN (TIME = NOON); creates a new task whose execution will be delayed until noon. Once created, the new task executes inde- pendently of

35、 the creating task except for explicitly programmed synchronization. Either task may termin- ate fust, or both may continue indefinitely. A job terminates when its last task terminates (which in principle need never happen). 2.2.1 Attributes and Scope Rules The real-time extensions include three new

36、 attributes: PROGRAM: specifies that an external procedure may be scheduled as a task. SHARED: specifies that a variable or file may be shared among tasks. SHAREDRECORDS specifies that the individual records of a file may be shared among tasks. A name declared with one of these three attributes has

37、job-scope. Within a job all job-scope declarations of a name are bound to the same object and that object exists for the duration of the job. RULE 1) All job-scope declarations of a name must agree as to data type and initialization. All must specify the same attribute from the set (PROGRAM, SHARED,

38、 SHAREDRECORDS). RULE 2) Within a program there must not be two declarations of a name, one of which has job-scope and the other external-scope. 4 NOTE: Within a program, all declaration of a name with external-scope are linked to the same object. Rule (2) ensures that, when a program is linked, the

39、 linker need manage only a single set of global names. 2.2.2 Task Structure A task contains everything required to support its programs execution except storage for objects with job- scope. In particular, it contains storage for the programs variables and its FILE constants.2 Ail variables except SH

40、ARED variables have task local storage. None of this storage is accessible to any other task, even to another task executing the same program. A task has the following items (some optional) that pertain to the real-time extensions: priority. This is an integer p in the range lOTHENB=B+A; A = 0; END:

41、 The task waits until both A and B can be locked, then executes the body of the BEGIN block. On exit from the BEGIN block (by any means), the variables are unlocked. A single executable statement may also be used as the body of a LOCK statement. For example, the state- ment “LOCK (A) THEN X = A;” as

42、signs the current value of the shared variable A to X. A LOCK statement may also have an ELSE clause that is executed instead of the LOCK body if the variables cannot be locked, either immediately or after a specified timeout interval. For example, LOCK (A,B,C) TIMEOUT (10) THEN BEGIN; . . . END; EL

43、SE CALL RECOVER In this case, the ELSE clause will be executed if the variables cannot be locked within 10 seconds. In all the examples so far, the shared variable has been locked for writing (which also allows reading by the locking task). For efficiency reasons, the language allows a variable to b

44、e locked for read-only, for example, LOCK READONLY (A) THEN. Any number of tasks may simultaneously have a variable locked for read-only. Thus, use of the feature may reduce queueing delays for locks. This is especially important in the case of shared records. 9 ._ _ - _ _-_- - _ ,-. _._-_ mx_ “-x_i

45、.lA-_-i_L.iil . 2.3.2 Lock States A shared object is in one of four states: Unloclced: No task has the object locked. La then the following are all shared variable references to X: X(l), X.A, SUBSTR (X( 1). B,3,7). 10 Rule 1) With certain exceptions, a shared-variable-reference must denote a shared

46、variable locked by the referencing task The exceptions are: use in a LOCK statement, use as the tested shared-variable-reference in an event in the WAIT and SCHEDULE statements, use in the STATUS option of the SCHEDULE state- ment, and use in the CONNECT and DISCONNECT statements. Rule 2) If the ref

47、erence is used in any assignment context (and PL/I has many of these), the shared vari- able must be locked for writing. Rule 3) If the shared-variable-reference is passed by reference as a procedure argument, the shared vari- able must be locked for writing. Rule 4) A shared-variable-reference must

48、 not be used as the argument of the ADDR built-in function. Rule 5) The data of a shared variable (or of any components for a structure) must be a computational (arithmetic or string) data type. Rules (3) and (4) limit aliasing of shared variables so that checking rules (1) and (2) can always be done at c