P. Brinch Hansen. Concurrent programming concepts. Computing Surveys, 5:223--245, 1973.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....papers on types and on data abstraction, Borg86 Cunn86 Gogu86 Hend86 Khos86 Lalo86 Lieb86 Mads86 Nguy86 Ossh86 Sand86 Snyd86b Stro86c Wegn86] Concurrency: These papers discuss various mechanisms and formalisms for coping with concurrency (CSP, monitors, etc. The Andrews survey is excellent. [Andr81 Andr83 Bern81 Brin72 Brin73 Brin78 Broo84 Dijk75 Hoar74 Hoar78 Lamp83 Nier87b Shoc82 Silb84 Upfa84] Data Abstraction: These papers explain various aspects of data abstraction. See also papers on languages with data abstraction mechanisms, and some of the papers on types. Gutt77 Ledg77 Smit77a Smit77b] Distribution: Papers on distributed problems are also mixed in with those on concurrency, ....

P. Brinch Hansen, "Concurrent Programming Concepts", ACM Computing Surveys, vol. 5, no. 4, pp. 223-245, 1973.

....Background and Motivation In recent years there has been great interest in development of high level language constructs to support parallel programming. Numerous synchronization constructs have been proposed since Dijkstra introduced the semaphort19 ] These include conditional critical regions[5], monitors[18, path expressions[8] and zerializers[3] In addition, we have come to realize the importance the role prorammtng languages play in the development of reliable, high quality software. Languages that support good program structure significantly enhance programmer effectiveness in ....

Brinch Hansen, Per, "Concurrent Programming Concepts", Computing Surveys, (5, 't), December 1973.

....but neither of these approaches are employed in the current CRL implementation. Finally, it is worth noting that CRL s integration of data access and synchronization into a single mechanism is not unlike that provided by monitors, a linguistic mechanism suggested by Hoare [28] and Brinch Hansen [8], or other linguistic mechanisms that integrate synchronization and data access (e.g. mutexes in Argus [53] mutex operations in COOL [15] etc. 34 CRL Internals This chapter describes the general structure of the prototype CRL implementation used in this thesis. Platform specific ....

Per Brinch Hansen. Concurrent Programming Concepts. ACM Computing Surveys, 5(4):223--245, 1973.

....individual server cannot handle service requests because it is blocked making a request of its own. If a cycle in these client server dependencies exists, then the system is said to have deadlocked. To see why this is the case, we have to consider the four necessary conditions for deadlock [53] [17], from operating system theory: 1. Mutual exclusion condition Resources exist that are not sharable. 2. Non preemption condition Once a resource is given to a process, it cannot be revoked until the process voluntarily gives it up. 3. Hold and wait, or partial allocation condition ....

P. B. Hansen, "Concurrent Programming Concepts," Computing Surveys, Vol. 5, No. 4, pp. 223-245, Dec. 1973.

....in its critical or noncritical sections. A process may remain forever in its noncritical section. These conditions rule out algorithms in which processes take turns entering, or declining to enter, their critical section; such algorithms are really solutions to the producer consumer problem [1]. Assume that a process i wants to enter its critical section first, while another process j is in its noncritical section. Since j could remain in its noncritical section forever, i must be able to enter its critical section without communicating with j. Assume that this has happened and i is in ....

....one that owns the variable this is a reasonable requirement. We will see below that it is automatically enforced by the programming language in which the algorithms are described. This requirement allows us to introduce the following notation. Definition 1 For any variable v we let V [1] , V [2] denote the write operation executions to v, where V [1] # V [2] # . We let v [i] denote the value written by the operation execution V [i] 3 However, it is possible to solve producer consumer problems with it. In fact, an interrupt bit of an ordinary computer ....

[Article contains additional citation context not shown here]

P. Brinch Hansen. Concurrent programming concepts. Computing Surveys, 5:223--245, 1973.

....place upon a solution. 2.1 Basic Requirements We assume that each process s program contains a noncritical section statement and a critical section statement, which are executed alternately. These statements generate the following sequence of elementary operation executions in process i: NCS [1] i # CS [1] i # NCS [2] i # CS [2] i # where NCS [k] i denotes the k th execution of process i s noncritical section, CS [k] i denotes the k th execution of its critical section, and # is the precedence relation introduced in Part I. Taking NCS [k] i and CS [k] i ....

....2.1 Basic Requirements We assume that each process s program contains a noncritical section statement and a critical section statement, which are executed alternately. These statements generate the following sequence of elementary operation executions in process i: NCS [1] i # CS [1] i # NCS [2] i # CS [2] i # where NCS [k] i denotes the k th execution of process i s noncritical section, CS [k] i denotes the k th execution of its critical section, and # is the precedence relation introduced in Part I. Taking NCS [k] i and CS [k] i to be ....

[Article contains additional citation context not shown here]

P. Brinch Hansen. Concurrent programming concepts. Computing Surveys, 5:223--245, 1973.

....that allow exactly one activity to enter a critical section. Both mutex and locks can easily be implemented with semaphore operations. Conditional Critical Region The basic idea of conditional critical regions is to provide some syntactic support for conditional coordination of parallelism [107, 108, 115]. Whereas in the critical region defined by semaphores arbitrary code could be executed, and hence accesses to arbitrary sets of data elements could be coordinated, conditional critical regions make the purpose of coordinating of accesses more transparent. The idea is to collect variables in ....

P. Brinch Hansen. Concurrent programming concepts. ACM Computing Surveys, 5(4):223-- 245, December 1973. 55

....19 up with two algorithms to operate on it. With a problem statement these algorithms are proved to be the best we can do. The related work for synchronization and communication is enormous. To name a few: semaphores [Dij68] message passing communicating sequential processes [Hoa78] monitors [Han73], rendezvous [RK79] and many more. Our work is unique because we capture real time aspects of a system by constructs like real time semaphore, and realtime mutex, while performing synchronization and communication. It is done such that predictability in the system improves. For memory ....

.... and Communication The two major breakthroughs for Synchronization and Communication have been semaphores by Dijkstra [Dij68] and message passing communicating sequential processes by Hoare[Hoa78] Other equivalent concepts and extensions to these concepts have been proposed e.g. monitors[Han73], bolt variables, rendezvous[Hoa78] sequencers[RK79] and path expressions[CH74] For real time multiprocessor systems, there is an ongoing debate as to what is the appropriate mode of synchronization and communication. One view is to have time as a parameter, in the synchronization and ....

P. Brinch Hansen, "Concurrent Programming Concepts", ACM Computing Surveys, 1973.

....work presented in chapter 7 will examine the relationship between synchronization and coherence for a set of applications in greater detail. 3.1. 3 Discussion The notion of explicitly binding data to synchronization variables was first introduced separately by Hoare [40] and Brinch Hansen [37] over two decades ago. The concepts defined in these early papers were called Conditional Critical Regions (CCR s) and were proposed as a method for structured programming. CCR s are an extension of semaphores in which the variables used for synchronization are explicitly bound to the variables ....

P.B. Hansen. Concurrent programming concepts. In Computing Surveys, Vol. 5, No. 4, pages 223-245, December 1973.

....but also a timely manner. The well known solution to the reader writer problem is to employ a synchronization protocol, such as semaphore locking, monitors or other synchronization techniques, to enforce mutual exclusion so that only one process is allowed to access the shared data at a time [9, 13]. Mechanisms characterized by such lockbased mutual exclusion are accepted as a standard approach to solving many concurrent programming control problems. In addition, various hardware supported primitives have been implemented for this purpose. Lock based mutual exclusion effectively creates ....

Brinch Hansen, P. Concurrent Programming Concepts. ACM Computing Surveys 5, 4 (Dec. 1973), 223--245.

....but neither of these approaches are employed in the current CRL implementation. Finally, it is worth noting that CRL s integration of data access and synchronization into a single mechanism is not unlike that provided by monitors, a linguistic mechanism suggested by Hoare [28] and Brinch Hansen [8], or other linguistic mechanisms that integrate synchronization and data access (e.g. mutexes in Argus [53] mutex operations in COOL [15] etc. Chapter 4 CRL Internals This chapter describes the general structure of the prototype CRL implementation used in this thesis. Platform specific ....

Per Brinch Hansen. Concurrent Programming Concepts. ACM Computing Surveys, 5(4):223--245, 1973.

....they will not, and the synchronization component of the access done primitives may be disabled from the application. 2. 2 Related Work The notion of binding data to synchronization variables was first introduced as a method for structured concurrent programming by Hoare [15] and Brinch Hansen [13]. In this approach, called Conditional 4 Critical Regions (CCR s) the variables used as monitors are explicitly bound to the shared variables that they protect, enhancing program clarity by making the effect of entering the critical section more obvious, but also permitting the compiler to ....

P.B. Hansen. Concurrent programming concepts. In Computing Surveys, Vol. 5, No. 4, pages 223245, December 1973. 23

....can be described as shared data that can be accessed via a set of procedures. The procedures define the operations that can be performed upon the monitor s data. Alternatively, the procedures can be regarded as services provided by the monitor. In Brinch Hansen s Distributed Processes model [Brinch73] any number of processes can make a request for service from the monitor, but only one process can execute within the monitor s procedures at a time. In this way a monitor provides mutual exclusion over the shared data. Processes that use the procedures of a monitor are queued in a single ....

P. Brinch Hansen. Concurrent Programming Concepts. ACM Computer Surveys, Volume 5, Number 4, December 1973, pages 223-245.

No context found.

P. Brinch Hansen. Concurrent programming concepts. Computing Surveys, 5:223--245, 1973.

No context found.

Per Brinch Hansen. Concurrent programming concepts. Software|Practice and Experience, 5(4):223-245, December 1973.

No context found.

P. Brinch Hansen. Concurrent programming concepts. ACM Computing Surveys 5(4):223-245, December 1973.

No context found.

P. Brinch-Hansen. Concurrent Programming Concepts. Computing Surveys 5(4): 224-245, 1973.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC