Report of session on concurrency

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. 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, as described in his working paper.