ANSI INCITS TR-7-1989 Information Processing Systems Technical Report - Real-Time Extensions for PL I (NOT AN AMERICAN NATIONAL STANDARD) (formerly ANSI X3 TR-7-1989)《信息处理系统技术报告.PL.pdf

《ANSI INCITS TR-7-1989 Information Processing Systems Technical Report - Real-Time Extensions for PL I (NOT AN AMERICAN NATIONAL STANDARD) (formerly ANSI X3 TR-7-1989)《信息处理系统技术报告.PL.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS TR-7-1989 Information Processing Systems Technical Report - Real-Time Extensions for PL I (NOT AN AMERICAN NATIONAL STANDARD) (formerly ANSI X3 TR-7-1989)《信息处理系统技术报告.PL.pdf（36页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI INCITS TR-7-1989(formerly ANSI X3/TR-7-1989)Information Processing SystemsTechnical ReportUser Documentation for ConsumerSoftware PackagesCopyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license

2、 from IHS-,-,-X3s Technical Report Series This Technical Report is one in a series produced by the American National Standards Committee, X3, Information Processing Systems. The Secretariat for X3 is held by the Computer and Business Equipment Manufacturers Association (CBEMA), 311 First St. NW, Sui

3、te 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 Technical Reports. Such Technical Reports are not standards, nor are they intended to be used as such. X3 Technical Reports are produced

4、 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 areas where it is found premature to develop a standard due to a still changing technology, or inappropriate to develop a rigoro

5、us 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 guidelines, the use of which can result in greater consistency and coherence of information processing systems. When the draft Tech

6、nical 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 Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networki

7、ng permitted without license from IHS-,-,-TABLE OF CONTENTS 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 2. Explanation . . . . . . . . . . . . . . . . . . . . . . .

8、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

9、.2.4 Task Termination 6 2.2.5 Discussion 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

10、 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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

11、 2.6.3 Shared Records . 20 2.6.4 Extra-Lingual File Sharing . 20 3. Language Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1 Attributes . 21 3.1.1 PROGRAM . 21 3.1.2 SHARED . 21 3.1.3 SHAR

12、EDRECORDS 22 3.2. Statements 22 3.2.1 ABORT 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 Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without licens

13、e from IHS-,-,-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 PRIORITY 30 iv Copyright American National Standards Institute Provided by IHS under license w

14、ith ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-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 l

15、anguage exten- sions are specifically designed for real-time applications including 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

16、components of an operating system. Expanding the design to accommodate this specialized 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, langu

17、age-independent. In particular, the treatment of tasking, shared variables, and synchronization 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 requir

18、ed data types are integer, Boolean, and character. The extensions require neither a 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 do

19、cument is the final version of an ANSI Technical Committee X3J1.4 working document. 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 exte

20、n- sions are not part of any standard or proposed standard. Many of the unresolved issues 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

21、committee expressly solicits accounts of implementation experiences, for it is only 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 Copyright American National Standa

22、rds Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-2. Explanation 2.1 Overview 2.1.1 Scope of Extensions The language extensions defined in this paper are designed to provide: 1. The ability for multiple PL/I progr

23、ams 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 system will not contain potential deadlocks. 2.

24、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. Each task has a lifetime that is inde- pendent

25、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 to respond to asynchronous interrupts and/or

26、 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 Concepts and Terminology A prqgram is a set of exter

27、nal 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 parallelism within a program execution. The rea

28、l-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. There is no hierarchical relationship between

29、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 separ- ate compilation. An entry point of an e

30、xternal procedure is an exkrnal entry point. 2 Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-Tasks communicate with each other through shared variables which, within a job, ar

31、e known to all tasks whose programs declare them. A special form of communication is provided by the WAIT statement, which is 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);

32、 /* Wait until shared variable /* COUNTER has been counted down /* to zero. */ */ */ Synchronization with events in the external 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 parti

33、cular device /* interrupt. l / */ */ */ WAIT (FLAG) /* Wait for the device interrupt /* to occur. Events related to date and time 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,

34、TIME = TIMEOUT); The task waits until one of the events has occurred. */ In addition to variables, whole files and the individual 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

35、 the task has locked the object. This locking mechanism prevents one task from modifying a shared object at the same time another task is reading or modifying it. It is possible for several tasks to simultane- ously read a shared object. 3 Copyright American National Standards Institute Provided by

36、IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,-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 (see b

37、elow). 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 are a

38、ll 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 th

39、e 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 at

40、tributes: 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 job

41、-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, SH

42、AREDRECORDS). 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 Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without licens

43、e from IHS-,-,-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 linker need manage only a single set of global names. 2.2.2 Task Structure A task contains everything required to support its progr

44、ams 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 SHARED variables have task local storage. None of this storage is accessible to any other task, even to another task executing the sam

45、e 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: 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 me

46、ans), 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;” assigns 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

47、 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; ELSE CALL RECOVER In this case, the ELSE clause will be executed if the variables cannot be locked within 10 seconds. In all the examp

48、les 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 be locked for read-only, for example, LOCK READONLY (A) THEN. Any number of tasks may simultaneously have a variable locked for read-

49、only. Thus, use of the feature may reduce queueing delays for locks. This is especially important in the case of shared records. 9 Copyright American National Standards Institute Provided by IHS under license with ANSI Not for ResaleNo reproduction or networking permitted without license from IHS-,-,- ._ _ - _ _-_-