Cantor(ID:1303/can008)presumably from the Cantor sets Object-oriented language with fine-grained concurrency based on graphs Athas, Caltech 1987. Elegqant model for distributed programming, but in some circumstances fiendishly difficult to match circumstances to graphs suitable for distribution Places Structures: Related languages
References: Extract: Cantor Objects Cantor Objects Normally a Cantor object is at rest and remains so until a message arrives for it. The response of an object to a message is determined by the contents of the message, the current contents of the persistent variables, and a sequence of procedural statements defining the fundamental 'actions' that an object can perform. These actions include sending new messages and creating new objects. Other actions that an object can do include evaluating arithmetic expressions, assignment, and making decisions about what actions to perform next. An object cannot run indefinitely. After an object finishes processing a message, it must either ready itself to receive another message or self-destruct. 1.2 Object Interaction Message passing in Cantor is based upon the sending object possessing a "reference" to the destination object. The message passing model that Cantor uses is based upon the model used by Cosmic Kernel [9], namely, messages exhibit arbitrary delay when travelling from sender to destination. This notion of reference is comparable to the notion of "pointer" found in programming languages such as C and Pascal, in that both pointer and reference are a spatial decoupling between the name of an object and the instance of the object. Cosmic Kernel and Cantor expand upon this interpretation by making reference also a temporal decoupling between the name of an object and its instance. Therefore, sending a message to an object is not an instantaneous application of the message to the destination object. Cantor takes the temporal decoupling one step further by associating the decoupling not only with message passing, but also with object creation. Thus a reference to an object call exist and be computed on before the instance of the object exists. However, for an object to accept a message, the object must be instantiated. The message passing model of Cantor deviates slightly from the model of Cosmic Kernel with respect to preservation of message order. In Cosmic Kernel, messages sent between two objects that are in direct communication will arrive in the same order as they were sent. Because Cantor objects can become other objects, an object is not necessarily always stationary in Cantor. The preservation of message order property is contingent upon not using the become statement. 1.3 What Cantor Does for the Programmer The task of writing concurrent programs in Cantor focuses upon finding a good concurrent formulation for the intended application. The tasks of assigning objects to processing nodes and managing the delivery of messages to objects is handled jointly by the Cantor compiler and runtime system. Although the Cantor system manages these resources for the programmer, the choice of algorithms and programming style influences the performance of the computation. One of the objectives of this report is to suggest some programming paradigms that have been found to be useful and efficient. Hopefully many more such paradigms will be discovered as our experience with Cantor grows. 1.4 What Cantor Doesn't Do for the Programmer Data and control structures common to many high-level programming notations are not fundamental to Cantor. For example, data structures such as arrays, records, queues, and stacks are not included. These data structures must be built explicitly out of Cantor objects. With respect to control structures, iteration is not included as one of the basic actions. Instead, structured programming constructs such as for and while must be programmed by message passing operations. Programmers accustomed to the well-known imperative programming languages used on sequential processors may find programming in Cantor challenging, i.e. difficult, at first. Data structures are described as compositions of objects and control structures are described as sequences of message passing actions. These data and control structures are not prepackaged as part of Cantor. However, the programmer can accumulate libraries of object definitions for particular problems. Cantor bears some kinship to LISP, with the Cantor object replacing the 'cons" cell as the atomic constructor. Extract: Writing Cantor programs Writing concurrent programs using the objects of Cantor usually requires a considerable amount of forethought about the concurrent formulation for the program. The objective for the concurrent formulation phase of program writing is to determine how the various concurrent objects are to be organized and how the various components for the "state" of the computation are to be partitioned among the objects. The process of developing good concurrent formulations, whether by intuition, technique, or a combination of both, is fundamental to writing programs. To serve as a starting point for writing useful programs in Cantor, this section examines in detail three medium size programs. The discussions that follow place emphasis upon the concurrent formulations, trusting that the reader has a working knowledge of the individual mechanisms of Cantor. The historical origin for these examples is the XCPL report [3]; their inclusion here is a virtual wholesale rip-off from the XCPL report. External link: Online copy Message passing in Cantor is asynchronous and buffered, and message order is preserved between pairs of directly communicating objects. The only prerequisite for sending a message between two objects is that the sending object must contain a reference to the destination object. The concept of reference is captured in Cantor by the built-in data type, called reference. A data value of type reference is generated whenever a new object is created; this value can be shared between objects through message passing. DOI Extract: The Cantor Experiment The Cantor Experiment The goal of the Cantor experiment is to provide a platform for experimenting with concurrent computations on fine-grain multicomputers. The preferred physical form for a fine-grain multicomputer is an ensemble of thousands of single-chip computing nodes in which each chip contains an instruction processor, a memory system, and a message-passing interface. Communication between any pair of nodes is provided by the message-passing interface and a message-routing network. Because memory is located on-chip, the amount of directly addressable primary storage per node is small (on the order of tens of kilobytes). This limitation, plus the presence of communication capabilities as a fundamental resource, precludes general programming of fine-grain multicomputers using programming models that were developed for sequential computers. For Cantor computations, the machine abstraction of the fine-grain multicomputer is a distributed object space in which the assignment of objects to nodes and the routing of messages between nodes is jointly handled by the compiler and runtime system. This abstraction of the fine-grain multicomputer draws a fine line between the responsibilities of the programmer and the responsibilities of the compiler and runtime system. The primary task of the programmer is to build distributed data structures that are collections of objects. Thus, computations that manipulate data structures of potentially infinite size are expressible; however, these data structures must be built by distributing the constituent component objects over the many nodes of the multicomputer. The primary task of the compiler and runtime system is to distribute and manage the data structures over the nodes of the multicomputer. This task is a problem of resource allocation of different resources. The critical resource is storage, since a computation must fit onto the nodes. Other resources include balancing the message load placed on the communication links of the message-routing network, and balancing the work load placed on the instruction processors of the nodes. The Cantor experiment is therefore ~n experiment in message-driven programming using fine-.grain objects, but it is also an architecture experiment. Extract: Conclusions Conclusions Cantor represents one set of ideas about programming multicomputers. These ideas were tested by implementing Cantor on both concurrent and sequential computers and by writing numerous Cantor programs. Essential Cantor provided a minimal platform in which the most basic operations (such as iteration) were expressed explicitly by message passing. A negative result of Essential Cantor was the use of dynamic typing. Because message passing is late-binding, dynamic typing of the contents of a message was initially thought to be useful. In practice, dynamic typing was used virtually exclusively for automatic coercion between integers ~ud floating-point numbers. Another negative result was the decision to not include a rudimentary array type such as vector. Although it is possible to build a table as a distributed data structure, there is no restriction inherent in the computational model for supporting small vectors inside objects. Functional abstraction in Essential Cantor was limited to creating new objects. Full functional abstraction was not included, because calling a function requires first creating an object for a function and then sending it a list of parameters as a message. Although these two steps are straightforward, the rendezvous with the return from the function call introduces a discretionary receive that is a case of the unbounded queue problem. For Essential Cantor, the problem was initially thought to be solved by exploiting the duality of messages and objects, and by representing new objects as futures. This solution is not complete, however, because messages can be delivered to a future before the corresponding message becomes an object. The out-of-sequence messages must be buffered until the message becomes an object; thus, an unbounded queue is required. The important positive result of the experiments with Essential Cantor was determining the generality of message-driven programming. This model of programming has since been implemented in the Reactive Kernel of the Ametek 2010 series of multicomputers. Although the Ametek 2010 supports multiple programming environments, the programmlng environments are layered upon the Reactive Kernel, and programming at the "handler" level is purely message-driven. Essential Cantor has been replaced by Cantor Version 2.2, which addresses the above-mentioned negative results of Essential Cantor. Version 2.2 is typed strongly through the use of type declarations. In Version 2.2, internal iteration, vectors, and full function abstraction are supported. in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details in SIGPLAN Notices 24(10) October 1989 incorporating the Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, New Orleans (OOPSLA 89) view details in Concurrency: Practice and Experience 2000 v12 view details |