Sloop(ID:1362/slo004)Parallel Programming in a Virtual Object Space Steven E. Lucco, Bell Labs, 1987 Structures: Related languages
References: Introduction Sloop is a parallel language and environment that employs an object-oriented model for explicit parallel programming of MIMD multiprocessors. The object-oriented computational model provides a natural setting for the construction of parallel programs. By conceiving a problem solution in terms of a collection of cooperating objects, a programmer can partition a program into natural functional units, replicating these units according to the data parallelism inherent in the particular problem. Sloop exploits the power of this model by providing new semantics and facilities that address the special requirements of parallel systems. The Sloop project has two major goals: to study methodologies for explicit parallel programming, and to apply the results of these studies to the design of a programming language and environment. Sloop evolved as a consequence of experiences in parallel programming during a two year period. The principal abstraction for the conceptual organization of Sloop programs is the distributed object. Distributed objects are a parallel extension of the class notion[GR83] with the following properties. First, a distributed object can be built from component objects located on different physical processors in a multiprocessor. Second, distributed objects are potentially accessible from any other object in the multiprocessor. Third, all of the component objects which constitute a distributed object can run operations simultaneously. Sloop hides details of the underlying multiprocessor by providing an abstraction called a virtual object space. A virtual object space contains a collection of objects that cooperate to solve a problem. Sloop encapsulates virtual object space semantics within a predefined object type. This type, called domain, provides an operation for asynchronously creating and accessing objects. It also provides an. operation for specifying groups of objects that should, for efficiency, reside on the same physical processor. However, the programmer can choose to construct distributed objects without explicitly mapping their components onto specific physical processors, in which case the Sloop runtime system performs mapping and load balancing functions. The encapsulation of these fundamental semantics within an object definition makes Sloop syntactically concise, since objects interact with domains exactly as they interact with objects of other types: through invoking operations. Sloop has been running since January 1986 on two multiprocessors at AT&T Bell Laboratories: the S/Net, a bus-based architecture with up to 12 processors [Ah83], and an experimental 64 processor hypercube[De85]. In December 1986, a third version of the Sloop runtime system was completed for a heterogeneous collection of workstations connected by an Ethernet. Extract: A Virtual Object Space A Virtual Object Space Sloop provides a high-level computational model that makes the use of distributed objects straightforward and concise. From the programmer's perspective, the Sloop runtime system transforms a network of computers into a single virtual object space. In a running program, a collection of objects within the virtual space cooperate to solve a problem. This model has several properties that facilitate distributed objects. First, objects compute and communicate in a uniform environment. The programmer need not pack and format data into a message in order to communicate information. Second, the programmer need not explicitly map objects to processors, although Sloop provides for explicit mapping when desired. Finally, one can build hierarchical structures without regard to crossing processor boundaries, because physically remote object references are supported transparently by the runtime system. As in most object-oriented languages, a set of object types defines a Sloop program. Each type consists of structured private data, and operations for manipulating these data. Object types can include a constructor operation, which is invoked upon creation of each instance of that type. At any instant the state of the computation is the collection of objects in the virtual space, their private data, and the set of operations invoked but not completed. A Sloop program begins execution with a single object, called the start object. To run a Sloop program, the user designates a start object type, and provides arguments for the constructor of that type. The runtime system creates a start object of the designated type, and invokes the object's constructor with the given arguments. The start object in turn creates additional objects, each with the potential to access all other objects and to invoke operations on them. Thus, through a small collection of object definitions, the start object unfolds into a complex computation. This methodology produces programs that adapt easily to varying conditions. Because a computation begins with a single object, it can grow to fit different input sizes and amounts of available computational power. Unlike processes in parallel languages such as [Ge85], Sloop objects become active only in response to an asynchronous operation invocation. In practice, this difference serves to reduce the amount of code devoted to synchronization in Sloop programs, and to increase modularity. in SIGPLAN Notices 22(12) December 1987 (OOPSLA '87) view details |