ABCL/1(ID:1191/abc008)Object-Based Concurrent LanguageAn Object-Based Concurrent Language. Yonezawa, U Tokyo 1987. Language for the ABCL concurrent (MIMD) system. Asynchronous message passing to objects. Implementations in KCL and Symbolics LISP available from the author. Structures: Related languages
References: The Computation Model Objects in ABCL/1 are autonomous information processing agents which work co-operatively with one another. Each object has its own computing power and works concurrently (or in parallel) with other objects. The computation model on which ABCL/1 is based assumes neither shared memory nor global clock. A collection of objects constitute a distributed computing system. An object has its own internal world, which consists of a local persistent memory and procedures inquiring/updating the local memory. They are called state and script, respectively. Also we assume that an object has its own local clock, namely, the local time is a well-defined concept for the object. The internal world of an object is a protected structure and cannot be accessed directly from any other object. Objects interact with one another via message passing. In response to a received message, an object executes one of the procedures in its script. Execution of a procedure by an object is a sequence of the following actions: 1. inquiring and updating the state of the object, 2. creating new objects, 3. sending and accepting messages, and 4. returning a value as a reply to a received message. In ABCL/1, the third kind of actions subsumes the fourth. For each object, there is a unique message queue and arriving messages are put in the message queue. We call this event message arrival. Messages in a message queue will be processed one at a time in a sequential manner. In ABCL/1, message arrival is asynchronous with the actions 1, 2, 3, and 4 mentioned above. This means that messages can even arrive at an object in deadlock. Each object is in one of the three modes, dormant, waiting, and active at any time. An object is in the dormant mode at its birth time. It becomes active when receiving a message. During execution of a procedure, it is in the active mode. It enters the waiting mode when it needs to receive another message in order to proceed with the execution of the procedure. By receiving an expected message, the object becomes active again, and continues the computation. After completing the procedure, the object becomes dormant again. There are three types of message passing, past, now, and future 1 . Just after transmitting a past type message, the sender object, say O, can continue its computation. If the receiver object, say O 0 is in the dormant mode, O 0 receives and then processes the message concurrently with the execution of O. In this case, O does not expect any reply as a response to the message. In contrast with the past type message passing, the sender object of a now type message does not resume its computation until the reply to this message arrives. In this case, the receiver object may return the reply while processing the message as well as after completing the actions in response to this message. The sender object O of a future type message also expects replies. But O does not have to wait for the replies immediately after the message transmission. O can continue its current sequence of actions. Each reply will be received asynchronously with these actions. For the purpose of asynchronous message reception, O creates a special object called a future object f whose behavior is similar to a queue. O attaches the name (or destination) of f to a future type message. All the replies to the message will arrive at f . O can remove and get replies stored in f and also check whether f is empty or not, whereas any other object O 0 cannot read the contents of f . What O 0 can do best is sending back a reply to f . In ABCL/1, a reply is returned as a message. For this convention, each message which requires a reply contains the information about the place to which the reply will be sent back. We call this information a reply destination. Each message is sent in either the ordinary or express mode. A message sent in the express mode has higher priority than those sent in the ordinary mode. More precisely, if an object receives a message in the express mode while processing a message in the ordinary mode, the object suspends the current computation sequence and starts processing the express message. By default, the suspended computation will be resumed after completing the actions for the express message. ABCL/1 satisfies the transmission ordering law: Suppose that two messages M and M 0 have the same sender O and the same receiver O 0 ; If M and M 0 are sent in this order according to the local clock of O, M and M 0 are always received in the same order according to the local clock of O 0 . Note that, in general, if M and M 0 are sent from different objects and received by the same one, their arrival order cannot be determined. in Object Oriented Concurrent Programming, A. Yonezawa, and M. Tokoro (eds.), MIT Press, Cambridge, MA. 1986 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(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details Differences between ABCL/R2 and ABCL/1 The ABCL/R2 system is not completely compatible with the ABCL/1 system. Some features of ABCL/1 are modified in ABCL/R2, and some are restricted or not available. Below, such features are discussed. 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 [ACM] ACM Computing Surveys (CSUR) 30(2) June 1998 view details in Concurrency: Practice and Experience 2000 v12 view details Resources
|