Amber(ID:1815/amb002)U Washington, late 80's. An object-oriented distributed language designed for the Topaz operating system, and based on a subset of C++. Amber is a distributed object-oriented system, based on C++, for writing parallel programs that execute on a local-area network. It uses a single shared distributed address space above which C++ objects are supported Structures: Related languages
References: Amber shows that support for loosely-coupled multiprocessing can be efficiently realized using an object-based programming model. Amber programs execute in a uniform network-wide object space, with memory coherence maintained at the object level. Careful data placement and consistency control are essential for reducing communication overhead in a loosely-coupled system. Amber programmers use object migration primitives to control the location of data and processing. Extract: Introduction 1 Introduction Small-scale shared-memory multiprocessors are becoming widely available in implementations ranging from single-user workstations to mini-supercomputers. The proliferation of multiprocessors means that local area networks of these systems are likely to become common. This presents the opportunity to program a group of these machines to work together on a single application. For many applications, networks of small-scale multiprocessors will have greater performance potential than the fastest mainframes at significantly lower cost, and with greater flexibility. Amber was designed to take advantage of this trend by supporting the development of parallel applications that use multiple machines in a network of shared-memory multiprocessors. Amber provides a set of programming facilities and abstractions that isolate the programmer from the low-level details of programming in this environment. The abstractions are intended to simplify communication, distribution, and parallelism, while supporting a dynamic program structure that can express and benefit from locality. Amber is based on a model of computation in which a collection of mobile objects distributed among nodes in a network interact through location-independent invocation. Amber objects are passive fine-grained entities consisting of private data and a set of public operations that can be locally or remotely invoked. The active entities in the system are thread objects, which possess processor state and a runtime stack and can execute on a CPU. A typical application might contain many threads concurrently executing object operations on different processors in a node and on different nodes in the network. The threads in an Amber program execute in a flat network-wide shared object space. Object references can be transmitted across node boundaries and dereferenced on any node with consistent semantics, allowing programs to operate on distributed data structures in a uniform way. Amber programs are written in an object-based subset of the C++ programming language [Stroustrup 861, supplemented with primitives for thread management and object mobility. The system is composed of a preprocessor to C++ and a runtime kernel which is linked with the user's program. Amber is implemented on the Topaz operating system for the DEC Firefly [Thacker et al. 881, a multiprocessor workstation based on VAX microprocessors. Applications have been executed on a group of eight Fireflies connected by a IO-megabit/second Ethernet. in [ACM] Proceedings of the 12th ACM Symposium on Operating Systems Principles, December 1989 view details With the advent of workstations and efficient networks, distributed systems are becoming common, and these systems are inherently more complex to program than their centralized counterparts. The additional mechanisms introduced to access information on distant nodes are a major source of complexity. Within a single address space, procedure call is a well-understood mechanism for the transfer of both control and data. In contrast, messagebased systems require the programmer to deal with the details of message packaging, locating the message target, and asynchronous communication. Remote procedure call (RPC) [4] provides', the familiar procedure call abstraction and hides most of the details of control and data transfer. However, the programmer is still responsible for locating the target of the call. Other problems arise from subtle semantic differences between RPC and local procedure call and because RPC imposes a client/server model on the distributed application [16]. Recently, the object-oriented paradigm has attracted much interest because it achieves data abstraction, software modularity, and code reuse in a natural way. Operations on an object are invoked by sending messages to the object. Thus, communication among objects maps readily to the communication in a distributed system, and local and remote invocation are both syntactically and semantically identical. Since there is no distinction between local and remote objects, it is possible to move objects at run time between the nodes of the distributed system, thus allowing for dynamic load adaptation and reconfiguration. However, total transparency is not desirable: a few distribution-related features are required to take full advantage of distribution and to tune performance (e.g., to keep related objects close together to avoid remote invocation), but their use can be deferred to a late implementation (preinstallation) phase. Integrating distribution and objectoriented languages has attracted much attention in recent years. Some well-known systems offering both location-independent invocation and object migration are Emerald [5, 6, 10], Amber [7], and Distributed Smalltalk [2, 3, 8, 11]. in [ACM] CACM 36(09) (Sep 1993) view details in Concurrency: Practice and Experience 2000 v12 view details |