B. Liskov, Distributed programming in Argus, Communications of the ACM 31 (3) (1988) 300--312.  Home/Search   Document Not in Database   Summary   ACM   TOC   Related Articles   Check

.... of forms, much of the work on concurrency is aligned with one of two basic paradigms: communication via shared variables (e.g. Concurrent Pascal [5] UNITY [10] communication via message passing (e.g. CSP [18] and Actors [1] including remote operations (e.g. Ada [3] and Argus [23]) which we view as a highly structured message passing protocol. The two paradigms di#er in the mechanisms they provide for communication among concurrent processes. However, both rely upon the use of names to identify (directly or indirectly) the communicating parties. Given this state of ....

B. Liskov. Distributed programming in Argus. Communications of the ACM, 31(3):300--312, March 1988.

.... There has been little attention paid to providing support for fault tolerance, aside from work based on fail stop failure models, that may not always be appropriate in global computing [10] An example of a local computing language that provided support for fault tolerance is the Argus language [35]. Fault tolerance was based on guardians and nested transactions [38, 36] Similar support for transactions was provided by languages such as Avalan C and Venari ML [19, 29] and is an integral part of various well known distributed computing platforms, including CORBA OTS, COM MTS, and Java ....

Barbara Liskov. Distributed programming in Argus. Communications of the ACM, 31(3):300--312, March 1988. 53

....to cope with those issues. For example, the distributed language Emerald[52] has an object migration mechanism; one of two tightly communicating objects can be moved to the host where the other object resides, to reduce the overheads of remote communication. Another distributed language Argus[63 65] has a transaction mechanism, which easily handles and recovers faulty processes in distributed systems. If we had the desired mechanisms built into a language, it would be easier to develop efficient, portable, modular and robust application programs. However, few of them are available to the ....

Barbara Liskov. Distributed programming in Argus. Communications of the ACM, Vol. 31, No. 3, pp. 300--312, March 1988.

....to transactional objects, and static fields of classes. Our underlying thesis is, however, that concurrency control and failure management are hard to aspectize in general, and we argue below that this is actually not surprising. On one hand, existing transactional languages, e.g. Argus [25], Arjuna [26] KAROS [27] Transactional Drago [28] or PJama [29, 30, 18] provide primitives for expressing transaction boundaries within methods, and not as separate concerns. Furthermore, even if the systems underlying those languages provide default mechanisms for handling concurrency and ....

.... and failures, most work on how to obtain effective mechanisms advocate the tight integration of the mechanisms within the actual methods or objects [21, 31, 32] The difficulty of providing local concurrency control mechanisms and the strong integration with recovery management is pointed out in [25]. On the other hand, object oriented programming is about modeling real world phenomenon with objects. Each object is supposed to encapsulate the state and the behavior of a real world phenomena, and concurrency and failures are usually parts of that phenomena. For instance, the very fact that ....

Liskov, B.: "Distributed Programming in Argus". Communications of the ACM 31(3), pp. 300 -- 312, March 1988.

.... 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 implementation details are discussed in Chapter 5. The prototype CRL implementation supports single threaded ....

Barbara H. Liskov. Distributed Programming in Argus. Communications of the ACM, pages 300--313, March 1988.

....support for long lived actions, cooperative activities and multidatabase systems. Much of this work is surveyed comprehensively in [Elmagarmid 1993] Several systems have been developed that successfully combine transaction processing with the object oriented programming methodology, e.g. Argus [Liskov 1988] and Arjuna [Parrington, Shrivastava et al. 1995] These systems offer support for nested transactions and provide a powerful linguistic base for developing reliable distributed programs. Competitive concurrency is well controlled and fully supported in such systems, but no support is provided for ....

B. Liskov, "Distributed Programming in Argus," Communications of the ACM, vol. 31, no.3, pp.300-312, 1988. 33

....A mail system may have a mix that is dominated by updates, since mail tends to be read in batches, but clients interact with the system relatively infrequently. Our prototypes implement a simple location service with insertion and lookup operations. The prototypes were implemenl in Argus [23]. An Argus program is composed of a number of modules called guardians that may reside on different nodes of a network. Each guardian contains local state information and provides operations called handlers that can be called by other guardians to observe or modify its state; it cames out each ....

....guardian contains local state information and provides operations called handlers that can be called by other guardians to observe or modify its state; it cames out each call in a separate thread and in addition can run some background threads. A computation in Argus runs as an atomic wansaction [23]; transactions are not needed in our implementation and add to the cost of using the service, but the additional cost is incurred equally in both the replicated and unreplicated prototypes. The replicati service is implemented as a number of guardians, one for each replica. Each guardian provides ....

Liskov, B. Distributed Programming in Argus. Comm. of the ACM 31(3):300-312, March, 1988.

....one wished, their implementation could be independent. Thus, by adding persistence as Service Provider (Micro kernel) OS 2 Machine 1 Machine 2 Service Provider Figure 1 Distributed Persistence Server an ancillary property, we provide both uniformity of view and implementation independence [14]. Another approach to persistence as an outgrowth of the data model would be to add the abstraction of multiple storage levels. Each data unit would be allocated and manipulated at a particular storage level. Services would be available to alter the level of a data unit. Perhaps data units at ....

Liskov, B., "Distributed Programming in Argus," Communications of the ACM, Volume 31, Number 3, March 1988.

....have generally refrained from using it. The fact that this paradigm did not fit well with any programming language construct, resulted in a rather alien abstraction. The abstract data type has had quite an impact on distributed system design and implementatation. Some early systems such as Argus [Ls88] and Eden [Al85] used object based methodologies to design and implement distributed services. Systems such as FOG [Mk91] have extended the traditional notion of an object using proxies to provide distributed services. Emerald [Ju88] achieves distribution through object mobility and remote ....

Liskov B., "Distributed Programming in Argus", Communications of the ACM, Vol. 31, No. 3, March 1988, pp. 300-312.

....parallel structure within each object [ 28 ] Implicit methods of encapsulating parallelism such as path expressions [ 29 ] are possible. In opting for an explicit means an object manager APTT is similar to a number of distributed object programming environments for example SR [ 30 ] ARGUS [ 31 ] and ALPS [ 32 ] In addition, the object manager, or in our case data farmer, can perform task scheduling. The template design decouples the (farmer) client from worker (server) by polling, moving away from a synchronous model of computation. Parallel slackness and bu ering are user level ....

B. Liskov. Distributed programming in Argus. Communications of the ACM, 31(3):300-312, 1988.

.... styles of distributed programming relies on extending the notion of invocation to a distributed context, i.e. o#ering some form of remote procedure call (RPC) 7] The integration of this distributed interaction style with an object oriented programming language has been thoroughly studied, e.g. [41, 11, 42, 10]. More recently, Java [29] has introduced its own variant, the remote method invocation (RMI) 61] through a precompiler approach. By using the same abstraction for distributed interactions as for local ones, RPC and its derivatives integrate naturally with a language, and make distributed ....

....any subscriptions performed by their master copy . 5. 4 RPC and Publish Subscribe Originally introduced as remote procedure call (RPC) 7] remote invocations have been quickly applied to objectoriented languages, leveraging some form of remotely accessible entity, e.g. guardians in Argus [41] (its follow up CLU [42] network objects in Modula 3 [11] and Obliq [10] every object is potentially a network object) and of course remote objects in Java RMI [61] 5.4.1 Invocations vs Events There are mainly two di#erences between such remote invocations and our event based model: ....

B. Liskov. Distributed Programming in Argus. Communications of the ACM, 31(3):300--312, Mar. 1988.

....6. Comparison of some System Implementations In the following, we will compare some systems implementing nested transactions with regard to the degree of parallelism supported, the applied concurrency control schemes and the way deadlocks are treated. In particular, we will consider Argus [Liskov88, Liskov87], Camelot [Spector88, EpingerS91] 28 Clouds [Ahamad87, Dasgupta89] Eden [Almes85, Pu85] and LOCUS [Mller83, Weinstein85] The table below summarizes the results. While Camelot, Clouds, Eden and LOCUS allow for parent child as well as sibling parallelism, ARGUS does not permit a parent ....

Liskov, B.: Distributed programming in ARGUS. Comm. ACM 31, pp. 300-312, March 1988.

....a system object, but there are several cases where the language object model differs from the system object. For example, one language may not provide any object oriented support. In such a system, the user must be conscious of a system object that is coarse grained. Eden [Almes et al. 85] Argus [Liskov 88] and Clouds [Dasgupta 86] Wilkenloh et al. 89] can be classified into this type, which we call the different object single language model. System Objects Space Language Space system object procedures, functions, objects, etc. Figure 2.1 Different Object Single Language Model Emerald ....

Barbara Liskov. DISTRIBUTED PROGRAMMING IN ARGUS. Communications of the ACM, Vol. 31, No. 3, March 1988.

....made non persistent, or to relax serializability in certain situations. An alternative way to look at this project is as providing OODB like services a la carte. Distributed Programming Languages Several distributed programming languages have been developed, such as Emerald[5] and Argus[8]. These systems provide more sophisticated distribution services than those developed for this project. On the other hand, they require programmers to adopt a new programming language and often a runtime environment. It seems that these requirements tend to place undue emphasis on the distribution ....

B. Liskov. Distributed Programming in Argus. Communications of the ACM, 31(3):300-312, March 1988.

....enough. The concurrent programming features of Ada 95 are very powerful and well integrated into the language, and hence application programmers make ubiquitous use of them. It would be very annoying to restrict the use of tasking inside a transaction. Some existing transaction systems (Argus [16], Camelot [17] allow nested transactions to execute concurrently, which can indeed improve performance. But nested transactions are isolated from each other, and thus only provide competitive concurrency. To make cooperative concurrency possible, a different scheme must be used, namely a mixture ....

Liskov, B.: "Distributed Programming in Argus". Communications of the ACM 31(3), pp. 300 -- 312, March 1988.

....in allowing parts of the application (and the run time itself) to be modified, for example using meta object protocols) However the challenge of this work has been to provide flexible mechanisms for allowing types to be changed at run time, while ensuring type safety. The Argus system [43, 5, 4] provided some support for updating a running system, using guardians, however versioning was largely of the nature provided by object oriented languages, and support mainly focused on properly terminating transactions. Evans and Dickman [22] describe an approach to managing multiple versions of ....

Barbara Liskov. Distributed programming in Argus. Communications of the ACM, 31(3): 300--312, March 1988.

No context found.

B. Liskov, Distributed programming in Argus, Communications of the ACM 31 (3) (1988) 300--312.

No context found.

B. Liskov,"Distributed Programming in Argus," Communications of the ACM,vol. 31, no. 3, pp. 300-312, March 1988.

No context found.

B. Liskov. Distributed Programming in Argus. CACM, 31,

No context found.

Liskov, B.: Distributed programming in argus. Communications of the ACM 31 (1988) 300--312

No context found.

B. Liskov. Distributed programming in Argus. Communications of the ACM, 31(3):300--312, March 1988.

No context found.

B. Liskov. Distributed programming in argus. Communications of the ACM, 31(3):300-312, March 1988.

No context found.

B. Liskov, "Distributed programming in Argus," Communications of the ACM, vol. 31, no. 3, pp. 300--312, March 1988.

No context found.

B. Liskov. Distributed Programming in Argus. Comm. of the ACM, 31(3):300--312, Mar. 1988.

No context found.

B Liskov. Distributed programming in Argus. Communications of the ACM, March 1988.

First 50 documents  Next 50

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