Concurrent Pascal(ID:578/con009)Dialect of Pascal which supports monitorsBrinch Hansen, 1972-75, implimented by Brinch Hansen's PhD student Hartmann after an earlier attempt by 6 graduate students. Dialect of Pascal which supports monitors (the first language to do so). All access to hardware devices through monitor calls, also processes and classes. Brinch Hansen had begun with Algol 60 device processes, then graduated to Pascal after Wirth published his description. Seeds of CP in the book on systems programming, then took the idea fo the virtual machine from Nori and the Simula class from Nygaard and Dahl. Several experimental versions were made, and used as part of concurrency systems developed toy operating systems (Deamy (1974), Pilot (1975)) before writing Solo (1975) in a mixture of CP and SP. This was then extended (still in the Solo system) have a ring network of PDP11s. Brinch Hansen and Staunstrup added (1978) transition commands, with process synchronizations represented as state transitions, and remote procedure calls (called distributed processes) in 1980. The Solo operating system was distributed throughout the world with the CP and SP compilers, and became a kind of lingua franca for concurrency. Brinch Hansen revisited the simpler ideas in Joyce and Edison. People: Related languages
References: in IEEE Transactions on Software Engineering 1(2) June 1975 view details in IEEE Transactions on Software Engineering 1(2) June 1975 view details in IEEE Transactions on Software Engineering 1(2) June 1975 view details in IEEE Transactions on Software Engineering 1(2) June 1975 view details in Proceedings of the Fifth International Computer Symposium, 1977 view details in Proceedings of the Fifth International Computer Symposium, 1977 view details 1) A manager declares a (finite) set of identical instances of an abstract data type (class or monitor); 2) A manager dynamically allocates an instance to a competing process, and this process cannot identify the instance or alter its allocation. 3) Between allocation and release of an instance the process has access to all capabilities of the managed type without mentioning the manager any more. Therefore, simultaneous processing with various allocated instances is possible (this is the main benefit as compared to monitors); 4) Instances of the managed type cannot refer to one another or to local variables of the manager. This is supported by the scope rules of the language; 5) At most one process can be active in a manager at any time and queue variables are allowed; 6) The correctness of access rights can be checked at compile time. At execution time one must check that a valid allocation exists. The definition of a manager has the form type M-type = manager of T-type-ref: T-type; and the variable declaration var M: M-type introduces a manager object of type M-type. A process can declare a variable var T: T-type of M which indicates the type of T and the identity of its manager. The parameter T-type-ref of the manager definition serves as a formal name: during the call T.P of a procedure P of manager M of this parameter stands for T. In case of a manager with entry procedures open and close which do the allocation job, for instance a monitor type with entry procedures send and receive, a sequence of calls T. open; [ T. send; T. receive; ] * T. close; is possible. If T-type is a class type then it is necessary to guarantee that only one process can have access to a class instance. This problem is solved by introducing two standard procedures, bind and release, which do the allocation using count variables exclusively. To permit verification of the access protection mechanism at compile time, the manager has access only to the class instance specified by the parameter T-type-ref, i.e., the access is combined with an activity of a (single) process within the manager. in ACM Computing Reviews 19(03) March 1978 view details in ACM Computing Reviews 19(03) March 1978 view details in ACM Computing Reviews 19(03) March 1978 view details This paper proposes an extension to Concurrent PASCAL to resolve this difficulty. In particular, we define a new concept scope which specifies the names of the program components which can declare an instance of a particular type. Given this concept and the program component manager, we devise a mechanism which will be shown to be consistent with the design goals of Concurrent PASCAL and which can be used to enforce processes to use the IO procedure with the index I set to only those pages which they have a legal right to access. External link: Online copy in The Computer Journal 22(2) May 1979 view details in The Computer Journal 22(2) May 1979 view details 1. INTRODUCTION Programming languages traditionally offered procedures and functions as the only means of abstraction, that is, of providing powerful and high-level concepts while suppressing the details of their realization. The last ten years have seen many efforts to devise better abstraction facilities. SIMULA 67, Concurrent PASCAL, MODULA, CLU, and MESA are some of the newer languages offering abstraction mechanisms. The facilities offered by those languages are intended to hide by abstraction the interplay of different operations on the same data and to prevent access to the common data except by use of the abstract operations. Most researchers have looked to the type concept as a basis for an abstraction mechanism. However, no single type-based approach has been generally accepted. The approach taken in this paper differs from previous ones in a fundamental way. It is not based on a generalization of the type concept. Instead, the emphasis is on statements and procedures. The syntax we introduce is similar to that used for other proposed abstraction mechanisms. In order to avoid confusion, the reader must initially assume a simplified notion of types. A type is considered to be a set of values. From a theoretical point of view a type is considered to be a set component of an algebra, and a distinction is made between an algebra and its sets of values. This attitude differs essentially from Guttag and Horning's [5]. The algebra itself can be identified with other parts of this proposal, but this is not done explicitly here. This paper introduces the proposed language constructs in steps, each including examples. Section 2 concentrates on how to use an abstraction; it is divided into subsections of increasing complexity. Section 3, showing how abstractions are defined, is also subdivided according to complexity. Section 4 specifies the semantics using rewriting rules and thus indicates a possible implementation. Section 5 presents some final remarks. in TOPLAS 3(1) January 1981 view details in TOPLAS 4(2) April 1982 view details in The Computer Journal 25(1) 1984 view details in [ACM SIGPLAN] SIGPLAN Notices 28(03) March 1993 The second ACM SIGPLAN conference on History of programming languages (HOPL II) view details in [ACM SIGPLAN] SIGPLAN Notices 28(03) March 1993 The second ACM SIGPLAN conference on History of programming languages (HOPL II) view details in [ACM SIGPLAN] SIGPLAN Notices 28(03) March 1993 The second ACM SIGPLAN conference on History of programming languages (HOPL II) view details |