B. Liskov,"The Argus Language and System", Proc. Advanced Course on Distributed Systems - Methods and Tools for Specification, TU Munchen, Apr. 1984.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....monitors. An Eject is typed, mobile and its invocation is location independent. The model integrates the object and virtual machine aspects: each Eject defines a multiprocess virtual machine. However, it contains a major part of the operating system, which complicates object management. In Argus [11], a special emphasis is placed on reliable distributed computation. Argus extends the CLU language to support atomic transactions in a distributed environment. An Argus Guardian encapsulates the notion of a virtual machine. A Guardian contains data objects and processes. A Guardian communicates ....

Liskov, B.H., "The Argus Language and System," in Distributed Systems: Methods and Tools for Specifications, pp. 343-430, Lecture Notes in Computer Science no. 190, Springer-Verlag, 1985.

....of distributed programs, such as a library information system, a distributed editor, and a mail repository. Status: The Argus research is active. Contact: Barbara Liskov, Massachusetts Institute of Technology, Laboratory for Computer Science, Cambridge, MA 02139 References: 52] 53] 54] [55], 56] 57] 58] 59] 60] 61] 62] 63] 64] 2.6 Athena Main Goal Project Athena is an educational experiment introduced in May 1983. It is a joint project of MIT, DEC and IBM to explore the potential uses of advanced computer technology in the university curriculum. Athena provides ....

B. Liskov, "The Argus Language and System", In M. Paul und H.J. Siegert, editor, Distributed Systems --- Methods and Tools for Specification, pages 343--430, LNCS #190, Springer Verlag, 1982.

....an object can act as both a client and a server. There are actually two kinds of objects in a client server world: the coarse grained active server objects, which are subject to distribution, and the fine grained passive objects, which are local to a given server. This model is used by Argus [1] and OMG CORBA [2] At the opposite, the so called blackboard model consists of a universe of objects which are are passive and can be distributed. An application is initiated by a process which invokes methods on objects of the universe. Processes communicate with each other by calling methods ....

B.H. Liskov, The Argus language and system, L.N.C.S , (190), pp. 343-340, 1985.

....operating system, which complicates object management. In Emerald [4] a successor project to Eden, static type checking was introduced, and objects may be active or passive. The emphasis on language support is an important feature of Guide, and is also present in Emerald, Clouds [5] and Argus [6]. A strong point of Argus is transaction support and recovery mechanisms. A major difference between Argus and Guide is the granularity of objects. While guardians (in Argus) are usually large units, such as servers, objects in Guide are usually small (like files in traditional systems) and may ....

B. H. Liskov, The Argus Language and System, in Distributed Systems: Methods and Tools for Specification , M. Paul and H.J. Siegert, ed., Lecture Notes in Computer Science, Springer-Verlag, n 190, 1985, pp. 343-430

....an object can act as both a client and a server. There are actually two kinds of objects in a client server world: the coarse grained active server objects, which are subject to distribution, and the fine grained passive objects, which are local to a given server. This model is used by Argus [1] and OMG CORBA [2] At the opposite, the so called blackboard model consists of a universe of objects which are passive and can be distributed. An application is initiated by a process which invokes methods on objects of the universe. Processes communicate with each other by calling methods on ....

B.H. Liskov, "The Argus language and system", L.N.C.S, num. 190, pp. 343-340, 1985.

....the atomic condition discussed earlier for shared variables. By making transactions appear atomic, concurrency control makes the system easier to understand. For this reason, atomic transactions have been proposed as a basic construct in distributed programming languages and systems such as Argus [Lis85] and Camelot [STP 87] Allowing transactions to be aborted permits more e#cient concurrency control algorithms. An algorithm can make scheduling decisions that lead to faster execution but may produce a nonserializable execution; it aborts any transaction whose execution would not appear atomic. ....

....With nested transactions, failures can be handled by aborting a subtransaction without aborting its parent. The parent is informed that its child has aborted and can take corrective action. Nested transactions appear as a fundamental concept in the Argus distributed programming language [Lis85] and in the Camelot system [STP 87] The framework presented in [LMWF88] is general enough for modeling nested transactions as well as ordinary single level transactions. ....

Barbara Liskov. The argus language and system. In M. Paul and H. J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, chapter 7, pages 343--430, Springer-Verlag, 1985.

....or remove scopes from the Cluster and the LsrScopes sets. In summary, ARIES RH adds only minimal overhead to ARIES to support delegation. 5 Related Work Previous work has produced many Advanced Transaction Models(ATMs) but each has its own tailor made implementation. For instance, both Argus [12] and Camelot [19] each supports its ATM (variants of nested transactions) SplitTransactions [16] allows the commitment of partial results but in a way that is less general than delegation (see section 2.2) Thus, although efficient, these systems are limited in the models they can synthesize. ....

B. Liskov and R. W. Scheifler. The Argus Language and System. In Lecture Notes on Computer Science Springer Verlag, volume 190, Berlin, 1982.

....system, and fault tolerant systems are no exception. Numerous languages, extensions to existing languages, and language libraries have therefore been developed to provide the programmer with mechanisms that support commonly used fault tolerance techniques. Examples of such languages include Argus [Lis85] Aeolus [LW85] and Plits [EFH82] that were designed from the very outset as languages for fault tolerant programming; Arjuna [SDP91] and Avalon [HW87] designed as libraries to existing languages; and finally Fault Tolerant Concurrent C [CGR88] HOPS [Mad86] and the languages described in ....

....ensures that if several actions are carried out by concurrent processes, the result is always as if the individual actions were carried out one at a time in some serial order. These properties have also been called totality and serializability [Wei89] and recoverability and indivisibility [Lis85] In the database literature, atomic actions are referred to as transactions [BHG87] The atomic object action paradigm is best suited for applications that manage persistent data whose consistency must be maintained despite failures. The unitary property of actions is implemented by a commit ....

[Article contains additional citation context not shown here]

Barbara Liskov. The Argus language and system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....; and b) to separate objects from execution structures, i.e. to define passive objects being executed by independently defined processes. We did not find strong logical arguments in favour of either solution. Both have been adopted by existing object based systems (e.g. active objects in Argus [19], Eden [5] and Emerald; passive objects in Clouds [11] Amoeba [22] and SOS [26] The choice is mostly influenced by considerations of efficiency and adequacy for the hardware and application domain. The applications that we contemplate involve creating many (usually small) objects, 4 and ....

B. Liskov, The Argus Language and System, In Distributed Systems: Methods and Tools for Specification, M. Paul and H.J. Siegert editors, Lecture Notes in Computer Science, No. 190, pp. 343-430 (1985).

....initially bound objects the implementation can be optimized such that the non distributed case is not worse than in traditional object oriented languages. 1 Introduction Usually distributed object oriented systems are derived from non distributed object oriented languages, i.e. Argus from CLU [1], Clouds from C called DC [2] and from Eiffel called Distributed Eiffel [3] These approaches introduce a new kind of object which is distributable, all other objects of the base language used being non distributable. The result is a two stage object model with different semantics ....

B. Liskov, "The Argus language and system"; In: Distributed systems, methods, and tools for specification; M. Paul, H. J. Siegert [Eds.], Lecture Notes in Comp. Sci. 190; Springer, Berlin; 1985 -- pp. 343-430

....make the resulting system unscalable. An additional cost is the maintenance of coherency between the nodes; many systems use a single copy protocol with the more recent ones using a multiple reader singlewriter protocol, this may result in considerable network traffic. 3. 3 Argus The Argus system [lis85] was an experiment in distributed systems which support long lived data. The Argus approach is the epitomy of the federated stores model. In Argus, each store is protected by a software entity known as a guardian. Each guardian is an abstraction of a stable store and provides access procedures ....

Liskov, B. "The Argus Language and system", Lecture Notes in Computer Science, 190 (Springer--Verlag, New York, 1981).

....file system. In many persistent systems persistence is determined by reachability from some form of persistent root [13, 15, 19] Thus all persistent objects can be found by computing the transitive closure of that root. Other systems have taken the approach of associating persistence with type [40, 50] in violation of the third principle (and the second as a consequence) This can result in dangling references, or at best invalidated fields of structures, as shown in Figures 1 and 2 from [43] Database Type Database Type Value Figure 1: Persistent objects before being sent to the store. ....

Liskov, B. "The Argus Language and System", Lecture Notes in Computer Science, vol 190, Springer-Verlag, New York, 1985.

....as well. The language has been implemented using the x kernel, an operating system designed for experimenting with communication protocols [HP91] and runs standalone on a network of Sun workstations. The orientation towards supporting multiple paradigms distinguishes FT SR from other languages [Lis85, EFH82, LW85] language extensions [SCP91, CGR88, KU87] and language libraries [BSS91, Coo85, PS88, HW87] related to fault tolerance, which are typically oriented around a particular paradigm. Support for a single paradigm has been shown to be constraining in many situations [Bal91] and is ....

....execution. An action is both unitary and serializable, which guarantees the atomicity of its execution with respect to both failures and the concurrent execution of other actions. These properties have also been called totality and serializability [Wei89] and recoverability and indivisibility [Lis85] In the database literature, atomic actions are known as transactions [BHG87] A system built using the object action paradigm may be implemented using FS atomic objects. Objects in the system correspond to FS atomic objects. An action corresponds to an abstract thread realized by the ....

[Article contains additional citation context not shown here]

Barbara Liskov. The Argus language and system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....Over the years, a variety of techniques, mechanisms, and structuring paradigms have been developed for building software of this type. These include such things as recovery blocks [Ran75] and Nversion programming [Avi85] for dealing with software faults, and checkpointing [BHG87] atomic actions [Lis85], and the replicated state machine approach [Sch90] for dealing with operational faults. All of these simplify the problems associated with faults by providing the programmer with higher level models or abstractions. Despite the inherent differences in these approaches, one common thread is that ....

B. Liskov. The Argus language and system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....ffl The first class consists of environments which regard load distribution as a problem of the application and leave load distribution completely to the programmer. Most parallel programming libraries like PVM [20] and p4 [5] and parallel programming languages such as Emerald [4] and ARGUS [17] belong to this class; a survey may be found in [3] Although PVM manages the assignment of processes to nodes, it does not manage the assignment of subproblems to certain processes) ffl The second class consists of environments supporting the task farming paradigm as for example Linda [7] DIB ....

Barbara Liskov, "The ARGUS Language And System", In M. Paul and H.J. Siegert, editors, Distributed Systems, Methods and Tools for Specification, chapter 7, pages 343--430, Springer Verlag, 1985.

.... software include the object action paradigm [Gra86] the primary backup approach [AD76] the state machine approach [Sch90] and conversations [Ran75] Fundamental abstractions that have been defined in conjunction with these paradigms include stable storage [Lam81] atomic actions [Lis85] common global time [Lam78] and reliable multicast [CM84] These abstractions serve as a convenient base for realizing the various paradigms by defining operations with higher level functionality or with semantics that are well defined even when failures occur. For example, many of these ....

....[Lam81] thus, stable storage is similar to standard memory or disk storage, but with better semantics in the face of failures. Atomic actions are sequences of instructions potentially spanning multiple machines that are guaranteed to either execute completely or not at all despite failures [Lis85] again, this makes atomic actions similar to standard sequential execution sequences, but with better behavior when failures occur. Resilient processes are processes that can continue executing correctly even if interrupted by failure and then restarted; the similarity here is, of course, to ....

[Article contains additional citation context not shown here]

B. Liskov. The Argus language and system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....passing (see figure 1) The system is populated by ROMANCE objects. ROMANCE objects consist of passive data encapsulated by a set of operations or methods, dubbed the object interface. Our model closely follows recent work on distributed object oriented systems as, among others, Emerald [6] Argus [22], Clouds [12] Comandos [32] SOS [30] and Arjuna [31] All ROMANCE objects are characterized by a set of attributes: ffl All ROMANCE objects are distributed. They can be accessed from any node of the system, with location transparency. All ROMANCE objects are accessed as if in the context of ....

B. Liskov. The ARGUS language and system. In Distributed Systems, Methods and Tools for Specification, Lecture Notes in Computer Science, volume 190. Springer-Verlag, 1985.

.... used to reason about the relative order of events [Lam78, Sch82, 25 Mat89] or real time from synchronized clocks [KO87, WL88, RSB90, VR92] Other important service abstractions are atomic actions, a collection of operations whose execution is indivisible despite concurrency and failures [Lam81, Lis85, SDP89] and stable storage, storage whose contents is guaranteed to survive failures [Lam81, BY87] Paradigms for structuring fault tolerant software further simplify developing applications. The replicated state machine approach is a paradigm for building fault tolerant services using ....

....KDK 89, KG94] The configurable systems presented illustrate different approaches taken towards customization in fault tolerant computing. A large number of other projects are not addressed in detail here, including ADS [IM84] Amoeba [RST89, KT91] AMp and xAMp [VRB89, RV91, RV92] Argus [Lis85, Lis88] Avalon [DHW88] Chorus [BFG 85] Clouds [DLA88, DLAR91] Delta 4 [PSB 88, BHV 90, Pow91] Saturne [DFF 90] Totem [AMMS 93, AMMS 95, MMSA 96] Transis and Lansis [ADKM92b, ADKM92a] and the V kernel [CZ85] 2.1.1 Static Systems 2.1.1.1 Isis The Isis system ....

B. Liskov. The Argus language and system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....platform. Over the years, a variety of techniques, mechanisms, and structuring paradigms have been developed for building software of this type. These include such things as recovery blocks [1] and Nversion programming [2] for dealing with software faults, and checkpointing [3] atomic actions [4], and the replicated state machine approach [5] for dealing with operational faults. All of these simplify the problems associated with faults by providing the programmer with higher level models or abstractions. Despite the inherent differences in these approaches, one common thread is that they ....

B. Liskov, "The Argus language and system," in Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190 (M. Paul and H. Siegert, eds.), ch. 7, pp. 343--430, Berlin: Springer-Verlag, 1985.

....due to either varying failure assumptions or implementation techniques. Here, we concentrate on processors with fail silent semantics, although the approach generalizes to other failure models as well. The orientation towards a multi paradigm approach distinguishes FT SR from other languages [Lis85 , EFH82, LW85] language extensions [SCP91, CGR86, KU87] and language libraries [BSS91, Coo85, PS88, HW87] related to fault tolerance, which are typically oriented around a particular paradigm. Support for a single paradigm has been shown to be constraining in many situations [Bal91 ] and is ....

....is indeterminate. This notification could be generated, for example, if the processor on which the object is executing crashes, or if a lower level constituent object fails. This notification aspect, which is one of the properties that distinguishes FS atomic objects from regular atomic objects [Lis85 ] is intended to allow for the possibility that the abstraction might, in fact, fail to hold under certain circumstances. This reflects the reality that there is always some non zero probability that an abstraction may not be maintained should, for example, multiple failures occur ....

[Article contains additional citation context not shown here]

B. Liskov. The Argus language and system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....in another virtual node then it must be do so through message passing. Such a framework allows general designs to be produced, with the underlying hardware providing a controlled influence upon the design approach. Burns and Wellings [2] note how this acts as a basis for CONIC [13] SR [14] Argus [15] and StarMod [16] The virtual node concept allows us recognise the the interaction between the hardware and the software of a distributed system in a controlled manner. Unfortunately, the notations that are founded upon this concept often do not provide sufficient abstractions and ....

Liskov, B, "The Argus Language and System", in Distributed Systems Methods and Tools for Specification, An Advanced Course, ed. Siegert, M Paul and H J, Springer-Verlag (1985).

....by the National Science Foundation under grant CCR 9003161 and the Office of Naval Research under grant N00014 91 J 1015. the other end of the spectrum are high level languages specifically intended for constructing fault tolerant applications using a given technique. Examples here include Argus [2] and Plits [3] which support a programming model based on atomic actions. Such languages simplify the problems considerably, yet can be overly constraining if the programmer desires to use fault tolerance techniques other than the one supported by the language [4] The net result is that neither ....

....The second is that, whenever possible, these mechanisms use or form natural extensions to existing SR mechanisms. These considerations resource main imports transManager, dataManager, stableStore, lockManager body main var virtMachines[3] cap vm # array of virtual machine capabilities dataSS[2], tmSS: cap stableStore # capabilities to stable stores lm: cap lockManager; dm[2] cap dataManager # capabilities to lock and data managers virtMachines[1] create vm( on host1 virtMachines[2] create vm( on host2 virtMachines[3] create vm( on host3 # backup machine # create ....

[Article contains additional citation context not shown here]

B. Liskov, "The Argus language and system," in Distributed Systems: Methods and Tools for Specification, LNCS, Vol. 190 (M. Paul and H. Siegert, eds.), ch. 7, pp. 343--430, Berlin: Springer-Verlag, 1985.

....Over the years, a variety of techniques, mechanisms, and structuring paradigms have been developed for building software of this type. These include such things as recovery blocks [Ran75] and N version programming [Avi85] for dealing with software faults, and checkpointing [BHG87] atomic actions [Lis85], and the replicated state machine approach [Sch90] for dealing with operational faults. All of these simplify the problems associated with faults by providing the programmer with higher level models or abstractions. Despite the inherent differences in these approaches, one common thread is that ....

B. Liskov. The Argus languageand system. In M. Paul and H.J. Siegert, editors, Distributed Systems: Methods and Tools for Specification, Lecture Notes in Computer Science, Volume 190, chapter 7, pages 343--430. Springer-Verlag, Berlin, 1985.

....of distributed applications is now supported by multiple alternatives when considering high level distributed environments. Using a system platform for remote access to services Such a platform can be a pure distributed operating system or a distributed language runtime like Emerald[1] Argus[2] , Guide[3] or a platform that integrates distribution like CORBA[4] ILU[5] Network OLE, etc. Those technologies aim at providing transparent and easy access to distributed services available on a workstation cluster, thus normalizing the way of accessing them. Such a normalization most often ....

B. H. Liskov , The Argus Language and System , L.N.C.S , 190, 1985.

No context found.

B. Liskov,"The Argus Language and System", Proc. Advanced Course on Distributed Systems - Methods and Tools for Specification, TU Munchen, Apr. 1984.

No context found.

B. Liskov: "The Argus Language and System"; Distributed Systems, Methods and Tools for Specification; M. Paul , H. J. Siegert [Eds.]; Springer, Berlin et. al., 1985; pp. 343-430

No context found.

B. H. Liskov (1985). The Argus Language and system. Distributed Systems : Methods and tools for specification (M. Paul & H. J. Siegert, ed.). Lectures Notes in Computer Science. Springer-Verlag.

No context found.

B. Liskov,"The Argus Language and System", Proc. Advanced Course on Distributed Systems - Methods and Tools for Specification, TU Munchen, Apr. 1984.

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