{"title":"Report of session on concurrency","authors":"J. Dennis, M. D. Schroeder","doi":"10.1145/800021.808269","DOIUrl":"https://doi.org/10.1145/800021.808269","url":null,"abstract":"This session was devoted to discussion of primitives for synchronizing the execution of concurrent processes. Jack Dennis introduced the session by noting that concurrent activity in a computer systems leads to the possibility of nondeterminacy. While most users with applications programs do not want nondeterminate results, some applications are inherently nondeterminate in part, e.g., an airline seat reservation system. At a lower level, the programmers of the operating system itself need to write both determinate and nondeterminate programs. The challenge is in providing primitives at each level in a system which guarantee determinacy when that is required, yet allow the construction of nondeterminate programs when that is required. As a basis for discussion, Dennis invited Rick Holt to make a short presentation on the levels in a computer system and their relationship to synchronizing primitives.\u0000 Holt indicated that the principle reason we have concurrency in computer systems is the economic necessity to run I/O devices in parallel with the much faster central processors. There are also fancier reasons, like constructing nondeterminate computations. Concurrency is usually handled by embedding various synchronizing primitives in the system or in high-level programming languages. In order to decide what primitives are appropriate you need to know what problems are to be solved. The problems being solved depend in turn upon the level of the computer system being considered. A computer system can be divided into five levels: hardware, kernel, nucleus, subsystems, and applications. The kernel multiplexes the central processors, implementing processes. At this level very simple synchronization primitives may be sufficient, like turning off interrupts. A critical problem at this level is the processor allocation strategy and maintaining queues of waiting processes. The nucleus is responsible for sharing devices. We want to be able to write device managers that multiplex data paths and schedule the use of these paths. These managers can be built in two ways: distributed managers that execute as part of user processes or centralized managers that execute in their own processes. Dijkstra has told us how to handle the concurrency generated by decentralized managers using primitives like P and V. Message passing works for centralized managers. (Note that message buffers are an important system resource to be managed. They cannot be managed using message switching, so this management must occur in the kernel.) At the levels of subsystems and applications something more complex and specifically suited to certain applications may be required to control concurrency. At all levels concurrency is interrelated with problems of protection, reliability, and pre-emption. If we ignore these problems we will miss entirely the problems of implementing primitives to control concurrency. Holt also discussed the primitives used at the various levels in the SUE system, a","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"160 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"114676931","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Programming languages for operating systems","authors":"R. McKeag","doi":"10.1145/390014.808294","DOIUrl":"https://doi.org/10.1145/390014.808294","url":null,"abstract":"","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"114 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"124079083","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"A systems implementation language for small computers","authors":"S. Hautaniemi","doi":"10.1145/390014.808281","DOIUrl":"https://doi.org/10.1145/390014.808281","url":null,"abstract":"","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"27 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"122546558","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Report of evening session protection","authors":"P. Neumann","doi":"10.1145/800021.808271","DOIUrl":"https://doi.org/10.1145/800021.808271","url":null,"abstract":"The session began late following an almost three hour dinner for some of us! (Southern hospitality?) Discussion centered on access control mechanisms in operating systems and/or in languages, weaknesses in the state of the art, and desirabilities for secure systems.\u0000 Should protection be specifiable within the base language of a system? Jack Dennis: a resounding “yes”. It is highly desirable to associate protection with accessing. (There was some disagreement here). Barbara Liskov: Some help obtainable from type checking during compilation where privileges can be specified at compile time. (Beware of subsequent modifications). Gio Wiederhold: Subsets of types can be useful here.","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"54 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"123836395","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Transferability and translation of data","authors":"A. Merten, E. Sibley","doi":"10.1145/800021.808295","DOIUrl":"https://doi.org/10.1145/800021.808295","url":null,"abstract":"Data translation is defined as the process whereby data stored in a form that can be processed on one computer (the source file) can be translated into a form (target file) which can be used by the same or different processing systems on a possibly different computer. The research approach is to develop a generalized methodology of data translation and within this framework to design and implement a specific prototype translator.\u0000 The current methodology for translating data and files from one system to another typically consists of writing file translation programs. This method, which involves writing a new program for each file to be translated, is often referred to as manual file translation. Because of the machine level detail required, these translation programs are typically written in assembly language. As a result, the programming time is large.","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"100 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"116045884","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Procedural encapsulation: A linguistic protection technique","authors":"S. Zilles","doi":"10.1145/800021.808305","DOIUrl":"https://doi.org/10.1145/800021.808305","url":null,"abstract":"System reliability is an important aspect of operating system construction. Because of this, a number of researchers have proposed design methodologies [e. g., 1, 2, 3] which are intended to produce more reliable software. Although the methodologies differ, there seem to be some important properties that they have in common.\u0000 One property is the decomposition of the system into components or modules which make as few assumptions as possible about the other components. We will call this the “minimal assumptions” property. Minimizing the assumptions one component makes about another component means that subsequent maintenance and extensions can be done with a smaller probability of introducing errors. A programmer is less likely to overlook critical, obscure interconnections if such interconnections are severely restricted.","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"1 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"130428745","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Abstract machines and software design","authors":"J. King","doi":"10.1145/800021.808288","DOIUrl":"https://doi.org/10.1145/800021.808288","url":null,"abstract":"A recent trend in operating system design [1,2,6,7] is to consider the design as a hierarchy of abstract machines. The problem is viewed as constructing a “users' machine” from a given hardware machine by means of software. Rather than do this in one large step, a progression of abstract machines are defined starting at the hardware machine and ending with the users' machine. Each new machine is “built from” the earlier machines, adding to their capabilities.\u0000 This approach appears to be a strong positive step toward bringing more discipline to the software development process. Liskov [6, 7] carefully documents the advantages. She also tries to establish formal rules to guide the process and relates this approach to structured programming [3, 8].","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"42 3","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"120906542","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Report of session on systems programming languages","authors":"R. Freiburghouse, R. M. Graham","doi":"10.1145/800021.808270","DOIUrl":"https://doi.org/10.1145/800021.808270","url":null,"abstract":"Discussion in this session centered around two major topics: experience using a particular language for systems programming and features which are required or desirable in a systems programming language. In general, as one might expect, the users of a particular language were happy with that language and felt they had made the right choice, even though they were not completely satisfied. There seemed to be general agreement that a higher level language than machine language (assembly language) should be used for systems programming. There was considerable difference of opinion as to how high level the language should be. There was a similar difference of opinion as to what features are desirable, and even necessary, in a systems programming language. Although the session was organized so as to discuss the two major topics separately, there was considerable discussion of desirable and necessary language features mixed in with the discussion of experience with specific languages.\u0000 The session opened with a report by Bob Freiburghouse on the use of PL/I for implementation of Multics. \"In general the project was successful. We're not about to switch to some other programming language. But we would like to enforce more discipline. I think we would like to recognize and enforce a subset of all this. He listed a number of key features, the most important of which was external procedures and external variables. Other important features included structured data with controlled packing, recursion, block structure, high level control statements, type checking, pointers and dynamic storage allocation, and % include. A few extensions were made to the language such as pointer valued functions, functions to construct and take apart pointers, P and V operations, and a notation for referencing Multics segments. In addition, a support routine called the binder was implemented. Using this routine one can combine a number of procedure and data segments into a single module. References to this module can be made using only designated names, all other names originally associated with the segments in the module will be hidden, that is, undefined outside the module.","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"36 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"127551923","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"Towards ISMs for OPSs","authors":"D. Berry","doi":"10.1145/800021.808277","DOIUrl":"https://doi.org/10.1145/800021.808277","url":null,"abstract":"Information structure models (ISMs) [Weg70] have been applied successfully to the study of programming languages both in their definitions [LW69, Wlk68,70,Wgb70] and in proofs of correctness and equivalence of various implementation strategies [Luc69,JH70,JL71,McG71,Bry72].\u0000 This paper examines briefly the possibility using ISMs to define operating systems (OPSs). We give a definition of the notion of ISM and indicate how to use them. Then we describe methods by which the process notion has been defined in the past in the hope that this will give some idea of the applicability of the ISM approach to the definition of OPSs.","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"8 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"128541241","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}
{"title":"An experience in structured programming and transferability","authors":"O. Lecarme","doi":"10.1145/800021.808290","DOIUrl":"https://doi.org/10.1145/800021.808290","url":null,"abstract":"This paper is not concerned with a true operating system, but with a long and complex program, that is a translator writing system (TWS)1 which has many of the characteristics of operating systems. The experience reported here is on transferring such a system from a PDP-10 computer to a CDC Cyber 74, and translating it from Fortran into Pascal2. We do not examine the points which are related to the host operating systems. Our principal purpose is to report on the different aspects of the work involved in translating such a program from Fortran to Pascal, and on the transferability of the resulting program.","PeriodicalId":161752,"journal":{"name":"SIGPLAN-SIGOPS Interface Meeting","volume":"70 1","pages":"0"},"PeriodicalIF":0.0,"publicationDate":"1900-01-01","publicationTypes":"Journal Article","fieldsOfStudy":null,"isOpenAccess":false,"openAccessPdf":"","citationCount":null,"resultStr":null,"platform":"Semanticscholar","paperid":"132660822","PeriodicalName":null,"FirstCategoryId":null,"ListUrlMain":null,"RegionNum":0,"RegionCategory":"","ArticlePicture":[],"TitleCN":null,"AbstractTextCN":null,"PMCID":"","EPubDate":null,"PubModel":null,"JCR":null,"JCRName":null,"Score":null,"Total":0}