Barbara Liskov and Liuba Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the SIGPLAN'88 conference on Programming Language Design and Implementation, pages 260--267, 1988.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....which Method Object(s) meet the synchronization constraints. The Method Object is then bound to the current Representation and the method is allowed to access update this Representation and create a Result. 3 3. Return result the final phase binds the Result value, if any, to a future [5, 6] object that passes return values back to the caller when the method finishes executing. A future is a synchronization object that enforces writeonce, read many synchronization. Subsequently, any readers that rendezvous with the future will evaluate the future and obtain the result value. The ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems, " in Proceedingsof the SIGPLAN'88Conferenceon Programming Language Design and Implementation, pp. 260-- 267, June 1988.

....the request reception from request processing. An initial inspiration for this approach was the implementation of continuations in the MACH kernel, which resulted in significant performance improvements in that OS kernel [5] Other examples of similar work include Futures [18] and Promises [19], which are language mechanisms that decouple method invocation from method return values passed back to the caller when a method finishes executing. Other distributed object computing middleware, such as DCOM [20, 21] also support asynchronous invocations on the client and the server side. Java ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems," in Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pp. 260--267, June 1988.

....provide methods used by Method Requests to implement predicates used by a Scheduler to determine Method Request execution order. Future When a client invokes a method on the Proxy, a Future is returned to the client. The Future is an object that enforces write once, read many synchronization [7, 8]. It allows the caller to obtain the results of the method after the Servant completes the method execution. 8 Dynamics The following figure illustrates the three phases of collaborations in the Active Object pattern: ############# ############# ##################### ##################### ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems, " in Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pp. 260-- 267, June 1988.

....for a basic value in Thor. Like regular references, it can be a future for the result of a call. In addition, a promise can be initialized to refer to a particular value. To get the actual value the promise refers to, the promise is claimed. Promises were first described in Mercury call streams [13]. However, a Mercury promise must be claimed before it can be used as an argument to a subsequent call. A Thor promise does not have to be claimed before it is used as an argument. It only needs to be claimed if the actual value of the promise is needed. Promises can be used to increase the ....

B. Liskov and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the ACM SIGPLAN '88 Conference on Programming Languages Design and Implementation. ACM, June 1988. 63

....over the same communications channel. In order to take full advantage of this pipelining, the originator needs to be able to make many calls before claiming any of the returns. Some additional linguistic support is required to make such callstreams as neatly modular as simple RPC [LBG 88, LS88] In many cases the streaming problem can be solved by migrating the client to the location of the data, instead of insisting that the data journey to the client. Consider the case where the individual elements of the stream are to be summed together. Instead of arranging to stream the data over ....

....the computations on A and B completed they would have both sent their results directly to C, where they would have been added and immediately printed. In this case the delay would have been only 2T . In a standard RPC system that also supported some kind of futures (such as those described in [LS88] the analogous program would in fact run with a delay of 2T so in this case RPC wins. The migration heuristics had to guess about the best place to compute the sum (which is computed after a delay of 2T in either case) and they got it wrong. RPC is too inflexible to even consider the ....

[Article contains additional citation context not shown here]

Barbara Liskov and Liuba Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proc. Conference on Programming Language Design and Implementation, pages 260--267. ACM, July 1988. BIBLIOGRAPHY 155

....should be satisfied on every access of an action to an object, regardless if the action already has the lock. This is a result of allowing a parent to run concurrently with its descendants in our new model, enabling descendants to snatch locks from objects used by their active ancestors ( Xu Liskov 1988]) ffl A read lock is required for reading even if the action has a write lock. The reason has to do with updating timestamps (see Section 4.2) Atomic objects enable a site to undo modifications done by an action (when the action is aborted) by using versions. The state of an unlocked object is ....

....if less than the quorum committed. 7.2.5 Claiming DAs DAs, as presented in our work, are synchronized with their transaction only when the latter commits. Therefore DAs can not return replies to their transaction like handler calls do. A linguistic support for asynchronous work was proposed in [Liskov Shrira 1988] with the introduction of promises into the language. A promise is returned to the caller when an asynchronous activity begins, and can be used by the program to reclaim the results of that activity later. More work can be done to try and combine the two methods; a promise can be supported by our ....

B. Liskov and L. Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In Proc. of the ACM SIGPLAN '88 Conference on Programming Languages Design and Implementation, ACM, June 1988.

....over the same communications channel. In order to take full advantage of this pipelining, the originator needs to be able to make many calls before claiming any of the returns. Some additional linguistic support is required to make such call streams as neatly modular as simple RPC [LBG 88, LS88] In many cases the streaming problem can be solved by migrating the client to the location of the data, instead of insisting that the data journey to the client. Consider the case where the individual elements of the stream are to be summed together. Instead of arranging to stream the data over ....

.... the vertices among the processors on a network, and migrating subgraphs from processor to processor as needed in order to apply reduction rules, linear graph reduction could be used to improve on existing network technology such as remote procedure calls (RPC) BN84] and network futures [LS88] Bawden built the nlgr (Network Linear Graph Reduction) system to demonstrate these capabilities [Baw92] Linear references made it easy to support cheap cross network references and highly portable data structures, and linear references also facilitated the demand driven migration of tasks and ....

Barbara Liskov and Liuba Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proc. Conference on Programming Language Design and Implementation, pages 260--267. ACM, July 1988.

....can be invoked; providers (servers) of methods do not have to receive messages, find out the correct method to invoke, generate a result and use a transport to send the result back to the caller. Instead, all of this is automatically performed by the Dispatcher class. 2.3. 11 Promise Promises [LS88] are used to start a computation and return while the computation is being performed (just after starting it) In the context of group communication, a promise is used to send a request to all (or N) members of the group and return immediately. The promise can be checked for completion and number ....

....from the promise. Promises allow clients to asynchronously invoke a method call without having to be blocked until the result is returned. Their main value lies in starting multiple invocations in parallel, and gathering the results later (load balancing) In contrary to the work described in [LS88] promises as used in the context of JavaGroups are not returned from some method call, but used as starting point as well. 2.3.12 RepeatedUnicast Frequently clients accessing a server will find that the server has crashed, or for some other reasons, does not respon within a certain time frame. ....

B. Liskov and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. ACM SIGPLAN Notices, 23(7), July 1988.

....window system incorporates asynchronous RPC mechanism[Dav92] Many of the calls in the X 11 interface are asynchronous. The Mercury communication system developed at MIT combines asynchronous and synchronous RPCs with and without replies in one single communication facility called a call stream [Cou94, Lis88]. These different forms of the communication are treated in a similar way by the servers they just receive invocations and return results. This approach allows the server design to be uninfluenced by the method of communication used by their clients. The clients can choose either the ....

....used by their clients. The clients can choose either the synchronous or the asynchronous mode of request to the servers. Three different forms of requests are available to the clients: ffl Synchronous RPC ffl Asynchronous RPCs without replies ffl Asynchronous RPCs with replies Liskov and Shrira[Lis88] have proposed a new data type called a promise to support asynchronous RPCs. Promises allow the clients to continue with other work during a call and subsequently to pick up results and exceptions from the call. The Nexus Communication system, developed by Argonne National Laboratory [Fos94] ....

Liskov, B. and Shrira, L. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In Proceedings of SIGPLAN'88 Conference Programming Language Design and Implementation, 1988.

....of the computation or exhaustion of data, the coprocessor issues an interrupt and the host application is either notified of the completion or asked to supply more data. An application can install a software handler, which gets called when the board issues an interrupt. By using a promise object [15] representing the result, one part of the host algorithm can pass the promise to other parts. Only when the value of the result is needed is the data read back from the coprocessor, or the algorithm is blocked until the data is available. The loader generates a bit stream, which can be downloaded ....

B. Liskov, L. Shrira, Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation. ACM SIGPLAN Notices 23 (7), 1988.

....asynchronous invocation returns immediately with a ticket, that can be used to collect the result of the invocation at some future time. Consequently, source and destination object are decoupled, and can continue their execution in parallel. A similar mechanism is adopted in systems like Mercury [12] and Cronus [17] Every invocation triggers an action at the destination object, that executes the method corresponding to the requested operation. The object s internal state is exposed only to these method executing actions (see figure 2) State changes can only occur as a result of invoking ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems" pp. 260-267 in Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation (June, 1988).

....based on tickets. In this mode, an invocation returns immediately with a ticket, that can be used to collect the result at a future time. As such, source and destination object are decoupled, and can proceed concurrently with their work. A similar mechanism is adopted in systems like Mercury [9] and Cronus [15] state methods dialogues actions Figure 3. COMET Object Model Action Slot Model Each invocation triggers an action at the destination object, that executes the method corresponding to the requested operation. Only actions are allowed to manipulate the object s internal ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems" pp. 260-267 in Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation (June, 1988).

....in conjunction with the Common Prototyping Language project. 1 1 INTRODUCTION Writing distributed programs is difficult for programmers, and even more difficult when high performance is required. Many mechanisms to achieve better performance in distributed programming have been proposed [3, 12, 13, 14, 19]; however, in practice these mechanisms are hard to utilize, and do not take into account the burden placed on programmers who already encounter difficulty in writing functionally correct programs. Furthermore, most of these mechanisms are expressed by special programming language constructs for ....

....client blocks the call until the server completes it [4] An asynchronous call does not block the client, and replies can be received as they are needed. To date, the decision on calling style is not the programmer s (for example, calls may be synchronous only [4] or they may be asynchronous only [2, 19, 24]) or the decision has to be made at module programming level by use of different library routines [8] If we let this decision be separate from RPC statement, the modules will remain reusable for different calling styles. Therefore, in devising requirements for a configuration level optimization ....

B. Liskov and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the ACM SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 260--267, June 1988.

....be coded to be part of the action. caller i = m;a i ; Deltab Deltacal ler i callee = X i2I a i Deltacal l procedure Delta l i ;b ; Deltacal lee System = Y i2I l i : caller) j(m: callee) nHS HS = i2I fa i ; b i g Example: The following is an encoding of call streams [LS88]. Here the caller does not wait for an acknowledgement. It continues its local processing (the action local processing) and is willing to accept an acknowledgement (the action b) when it has arrived. caller = m;a ; Delta(b Delta0 j local processing Deltacaller) 16 callee = ....

B. Liskov and L. Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In SIGPLAN Conference on Programming Language Design and Implementation, pages 260--267, 1988.

....a parameter (or the target object) of O 2 is a nonidentity result of O 1 . This is implicitly both a result dependency and an order dependency. This kind of dependency also includes the case where the execution of O 2 is conditional on the result of O 1 . Mechanisms such as Futures [16] Promises [12] and Wait by necessity [5, 6] allow order interdependent operations to be in progress concurrently. Mechanisms such as Batched Futures [3] and Responsibilities [9] go further in allowing result interdependent operations to be in progress concurrently. In order to allow functionally dependent ....

Liskov, B. and Shrira, L., "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", in Proceedings of the Sigplan'88 Conference on Programming Language Design and Implementation, pp. 260--267, Atlanta, Georgia, June 22--24 1988.

....standard CORBA AMI callback model. 1 The source code and documentation for TAO can be downloaded from www.cs.wustl.edu #schmidt TAO.html. Related work: The AMI polling model stems from research on programming language support for distributed computing. For instance, Futures [16] and Promises [17] are language mechanisms that decouple method invocation from method return values passed back to the caller when a method finishes executing. As with AMI Pollers, calls are invoked asynchronously, clients can rendezvous with a Future Promise to obtain reply values when they become available. ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems," in Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pp. 260--267, June 1988.

....has to wait for the response at every operation. Some previous work extended the RPC model to introduce an asynchronous mode and showed that the application requires the ability to explicitly specify its own synchronization needs. Thus a linguistic mechanism called a Promise is described by [ LS88] to support asynchronous calls. A Promise allows a caller to run in parallel with a call and to claim the results when they are available. The Mercury project [ LBG 88] presents a new communication model call stream mechanism which combines RPC with Message Passing. The sender may make ....

B. Liskov and L. Shriba. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 260--267, Atlanta, Georgia, June 1988.

....by Office of Naval Research and a grant from the Siemens Corporation. 1 INTRODUCTION Writing distributed programs is difficult for programmers, and even more difficult when high performance is required. Many mechanisms to achieve better performance in distributed programming have been proposed [3, 12, 13, 14, 19]; however, in practice these mechanisms are hard to utilize, and do not take into account the burden placed on programmers who already encounter difficulty in writing functionally correct programs. Furthermore, most of these mechanisms are expressed by special programming language constructs for ....

....client blocks the call until the server completes it [4] An asynchronous call does not block the client, and replies can be received as they are needed. To date, the decision on calling style is not the programmer s (for example, calls may be synchronous only [4] or they may be asynchronous only [2, 19, 24]) or the decision has to be made at module programming level by use of different library routines [8] If we let this decision be separate from RPC statement, the modules will remain reusable for different calling styles. Therefore, in devising requirements for a configuration level optimization ....

B. Liskov and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the ACM SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 260--267, June 1988.

....homogeneity) instead of dealing with heterogeneity. Fortunately, differences between domains have been considered in previous research, and mechanisms have been developed to help overcome the barriers imposed by heterogeneity. Many previous systems provided some form of interconnection capability [BDW89, HaMS88, HaNo86, JoRT85, LiSh88, MaKS89, NoBL88, Perr89, Snod89, WLRT91]. However, their focii were on the interconnection mechanisms themselves (such as data coercion operations or communication protocols) and not on the software engineering environment in which the mechanisms would be employed to solve large scale problems. There are some fundamental engineering ....

B. Liskov and L. Shira. Promises: linguistic support for efficient asynchronous procedure calls in distributed systems. Proc of SIGPLAN Language Design and Implementation, (June 1988).

....Object(s) meet the synchronization constraints. The Method Object is then bound to the current Resource Representation and the method is allowed to access update this representation and create a Result Handle. 3. Return result the final phase binds the Result Handle value, if any, to a future [18, 19] object that ######### ######### ##### ##### ####### ####### ####### ####### # ################# ##### ##### ######## ######## ####### ####### ############ ############ ################## ################## ################ ################ ######### ######### # ################# ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems, " in Proceedingsof the SIGPLAN'88Conferenceon Programming Language Design and Implementation, pp. 260-- 267, June 1988.

....that we retain the underlying RMI wire protocol and conformance with standard Java RMI. Our approach uses methods for overcoming latency issues in communication, by allowing asynchronous communication and delayed referencing of invocation result values, such as is found in Futures [30] Promises [16] and DRAMFs [10] Future objects delay any blocking on remote method invocation until the result is required by the Client. This is especially useful when a client is not interested in the result of a method invocation, but only in the invocation occuring, resulting in no unnecessary object ....

B. Liskov and L. Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In Proc. SIGPLAN'88 Conf. Programming Language Design and Implementation, pages 260--267, June 1988.

....future object is delayed until that future becomes determined. The concept of futures was first introduced in the context of the actor model [36] and also independently as the notion of promises in the context of parallel functional programming [37] Later, several languages and systems [35] 38] [39] [40] incorporated this concept in their computation models for supporting asynchronous operations. Moreover, futures can be passed from one object to another through invocation parameters, as in Mentat [40] Futures represent higher level abstractions as compared to the primitives described ....

Barbara Liskov and Liuba Shrira, ` Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems ', Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, 1988, pp. 260--267.

....from the process interaction world view [Evans 88] APOSTLE s model of mutability is based on that of Algol 68 [van Wijngaarden 75] i.e. only reference cells are mutable and all other objects are immutable. Methods are invoked asynchronously, and return values are recovered using promises [Liskov 88] If desired, methods can be invoked into the future using the at or after keywords. APOSTLE methods may wait for a period of simulation time to elapse or wait until a Boolean condition becomes true [Vaucher 73] APOSTLE objects may have more than one method running concurrently at any given ....

....: Ok Path monitor Ordering job by receiveTime state let job = method( Ok wait for (delay) endmethod endobject Figure 3.4: An example Object type and object expression. 43 3.4 Expressions 3.4. 1 Method invocation Method invocation in APOSTLE is asynchronous and uses promises [Liskov 88] A method is invoked using the invoke expression, which returns a promise. A promise is a place holder for the return value of a method. When a method completes, it sends its return value to the promise associated with it. Any expression (there can be more than one) that wishes to obtain the ....

B. Liskov & L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation, 2224 June 1988, Atlanta, Georgia, pp. 260-267.

....addition to being the first ORB with a standard Portable Object Adapter [15] TAO is the first ORB to implement the standard CORBA AMI model. Related work: The AMI polling model stems from research on programming language support for distributed computing. For instance, Futures [16] and Promises [17] are language mechanisms that decouple method invocation from method return values passed back to the caller when a method finishes executing. Similar to AMI Pollers, calls are invoked asynchronously, clients can rendezvous with a Future Promise to obtain reply values when they become available. ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems," in Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pp. 260--267, June 1988.

....a Rover server. To import an object, an application calls import and provides the unique identifier for the object, the session identifier, a callback, and arguments. In addition, the application specifies a priority that is used by the network scheduler to reorder QRPCs. Import returns a promise [53]. Applications can wait on this promise or continue computation. The callback will be invoked upon arrival of the imported object. The current implementation also has a load operation that is an import combined with a call to create a process. Using load, applications can import RDOs that need a ....

B. Liskov and L. Shrira, "Promises: Linguistic support for efficient asynchronous procedure calls," in Proc. SIGPLAN 88 Conf. on Progr. Lang. Design and Impl., Atlanta, GA, June 1988, pp. 260--267.

....to the client. Electra enhances the standard Environment class with three special operations. By the call type method below, clients specify whether an invocation will be performed synchronously (blocking) asynchronously (non blocking) or by an intermediary form using a promise abstraction [10] to synchronize with the invocation at a later point. C class Environment f public: Standard Environment interface. See OMG doc. 94 9 14: void exception(Exception) Exception exception( const; void clear( static Environment ptr duplicate(Environment ptr) static Environment ptr ....

....call works like the asynchronous one, however, by issuing the wait method on the Environment object, the caller is suspended until a reply is received from the server. When wait returns, the outF argument is defined. Thus, the Environment parameter acts like a promise object [10] in that it permits the caller to synchronize with the invocation at a later point, and thus to overlap communication with computation. 5.2.3 Non Transparent Group Invocation The next example shows the difference between transparent and non transparent multicast. By using CORBA sequences in ....

Liskov, B., and Shrira, L. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. ACM SIGPLAN Notices 23, 7 (July 1988).

....it once it has been supplied. The key point about responsibilities is that they may be sent between objects whilst still preserving their identity. This allows responsibilities to subsume the role of previous constructs for asynchronous RPC such as futures or promises [Yonezawa et al. 1987, Liskov and Shrira 1988] Furthermore, since responsibilities are first class values, they can be used in any context where other first class values, such as integers, are allowed. In particular the value held by a responsibility can itself contain responsibility values. We demonstrate how, as a result of this ....

....provide a non blocking operation to check whether or not a result has been received. RPC with futures retains the balanced request reply structure of RPC.Aswe have seen before, this is an advantage in terms of safety and ease of use, and a limitation in terms of flexibility. The promises mechanism [Liskov and Shrira 1988], which is similar to futures based RPC, records failures by recording exceptions in the promise object associated with a call. These exceptions are raised when an attempt is made to demand the result value from the promise object. Thus, failure handling can be cleanly integrated with both futures ....

Liskov, B. and Shrira, L., "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", in Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pp. 260-267, Atlanta, Georgia, June 22-24 1988.

.... of an asynchronous request may be discarded, or it may be later retrieved (from the activity object) Forking an asynchronous request and later making a rendezvous with its outcome is termed a deferred synchronous request , and is somewhat similar to the futures mechanism of [10] or promises of [15]. Asynchronous operations appear to be essential in a distributed environment, for which communication latencies are frequently high. Our environment currently provides extremely low level synchronisation support. Some programming languages provide synchronisation support as a part of their ....

B. Liskov and L. Shrira "Promises: Linguistic Support for Efficient Asynchronous Procedure Calling" Proceedings of the SIGPLAN-88 Conference on Programming Language Design and Implementation, June 1988, pp260-267.

....return values with tokens that block if they are dereferenced before the result has arrived. The token method has provided opportunities to overlap computation with communication, however we have not encountered cases compelling enough to introduce a more complicated mechanism such as promises [19]. 4.2. Eliminating Object and Function Dispatch Overhead Object dispatch is the process of mapping an object identifier to an associated object when a call request arrives at the server. 3 In our OORPC system, the mapping operation is provided by a directory of exported objects. 4 Object ....

B. Liskov and L. Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In Proceedings of SIGPLAN'88 Conference on ProgrammingLanguageDesign and Implementation. ACM, June 1988.

....Introduction Remote Procedure Call (RPC) 6] is perhaps the most popular paradigm used today to build distributed applications. Many RPC semantics have been designed and implemented in recent years to meet application specific requirements. Examples are synchronous RPC [6, 7, 8] asynchronous RPC [9, 10, 11], fault tolerant RPC [12] broadcast RPC [7, 8, 13] maybe RPC (no return RPC) 7, 8, 13, 14] RPC with atomic transactions [15] and RPC with call back mechanism [8, 13] With emerging applications like multi media conferencing and distributed real time applications, it is conceivable that even ....

B. Liskov and L. Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed System. In Proc. of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pages 260--267, June 1988.

....can refer to a single object or to an object group. A special Electra object known as the master trader [16] manages the identification names for a domain. In our model such domain normally comprises one LAN. Electra supports three kinds of RMC: asynchronous mode, synchronous mode, and promises [15]. In asynchronous mode, a thread issuing an RMC proceeds without awaiting the reply to the remote operation. In this case an upcall method can be specified, which will be invoked by the sender s run time system as soon as the reply (containing the RMC s return values) arrives. The upcall obtains ....

Liskov, B., and Shrira, L. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. ACM SIGPLAN Notices 23, 7 (July 1988).

....means more thread invocations and this will add additional overhead. The Kan system uses 4 thread inlining to reduce the unnecessary concurrency to achieve efficient multi threaded without sacrificing good sequential performance. 1. 4 Related Work During the past decade, many distributed systems([18, 19, 27, 39]) have been designed and implemented. In this section, we survey some of these systems. Aleph [19] is a collection of Java packages developed at Brown University that implements a simple, platform independent distributed shared memory. It supports distributed computations that run across networks ....

....across networks of heterogeneous workstations, and provides the ability to start threads on remote processors, to share objects among processors as well as inter processor synchronization, and simple transactions. However, neither guarded actions nor nested actions are implemented in it. Argus [27] is an experimental language system developed at MIT which supports the construction and execution of distributed programs. Argus is an extension of the programming language CLU. Argus supports nested atomic actions and asynchronous execution, but it does not allow the parent and the children to ....

B. Liskov and L. Shrira. Promise: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. Proc SIGPLAN'88 Conf. Programming language Design and Implementation, 1988.

....As the number of stores grows, algorithms must scale so that all the required actions can be performed in reasonable time. Many models of providing IPC have been proposed for constructing such applications, for example: message passing [12] remote procedure call (RPC) 4] and asynchronous RPC [20]. We choose to conduct our discussion in the context of RPC, but similar issues arise with the other mechanisms. RPC mechanisms have been built with many different objectives. For example, there are RPC mechanisms designed for heterogeneity [7] performance [3, 28, 18] flexibility [9] or ....

B. Liskov and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedingsof the SIGPLAN'88 Conferenceon Programming LnaguageDesignand Implementation, pages260--267, 1988.

....shortcomings of RPC [3] He introduced remote pipes, which allow for the asynchronous transfer of bulk data. Remote procedures and pipes can be combined in channel groups to enforce the ordering property. A more integrated approach is taken by Liskov, who introduced promises to express asynchrony [7]. Promises serve as placeholders for values that will exist in the future (when the actual result of an invocation arrives) They ensure ordered handling of requests. Batching is used to increase throughput. A similar approach is taken with the futures in the Cronus system, except that no ....

B. Liskov and L. Shrira, "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems" pp. 260-267 in Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation (June, 1988).

....window system incorporates asynchronous RPC mechanism[Dav92] Many of the calls in the X 11 interface are asynchronous. The Mercury communication system developed at MIT combines asynchronous and synchronous RPCs with and without replies in one single communication facility called a call stream [Cou94, Lis88]. These different forms of the communication are treated in a similar way by the servers they just receive invocations and return results. This approach allows the server design to be uninfluenced by the method of communication used by their clients. The clients can choose either the ....

....used by their clients. The clients can choose either the synchronous or the asynchronous mode of request to the servers. Three different forms of requests are available to the clients: ffl Synchronous RPC ffl Asynchronous RPCs without replies ffl Asynchronous RPCs with replies Liskov and Shrira[Lis88] have proposed a new data type called a promise to support asynchronous RPCs. Promises allow the clients to continue with other work during a call and subsequently to pick up results and exceptions from the call. 2.2 RMI and ARMI The RPC model, however, does not translate well into distributed ....

Liskov, B. and Shrira, L. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. In Proceedings of SIGPLAN'88 Conference Programming Language Design and Implementation, 1988.

....a call is asynchronous if the client thread returns immediately. In the latter case, the RPC system may include another system call that allows the thread to retrieve results later. Although synchronous is most commonly used, a number of systems provide an asynchronous option as well [ATK91, LS88, WNF90] ffl Orphan handling semantics specify how orphans that is, server computations associated with clients that have failed are dealt with. Orphans not only waste computing resources, but may also interfere with new calls issued by a recovered client. Options for dealing with orphans ....

B. Liskov and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the SIGPLAN '88 Conference on Programming Language Design and Implementation, pages 260--268, Jun 1988.

....execution are found in other contexts in computer science, including distributed computing, database transaction management, software analysis, and artificial intelligence. Delayed Results The idea that the evaluation of a needed result may be delayed is embodied in promises in the Argus system [21]. A promise is a placeholder for a result that will be computed and returned via asynchronous remote procedure call. One of the advantages of promises, as for provisional execution, is that the computation of the value can proceed in parallel with the program that needs the value. ....

Barbara Liskov and Liuba Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. Technical Report Programming Methodology Group Memo 60-1, Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, MA 02139, March 1988.

....systems (or, indeed, in any type of distributed systems) This being said, it is possible to counter latency, in two ways: Hide latency by overlapping execution with communication. Avoid unnecessary latency induced by limitations of the communication mechanism. Techniques such as Promises [Liskov and Shrira 1988], Futures [Walker et al. 1990] Waitby necessity [Caromel 1991, Caromel 1993] and Responsibilities [Detmold and Oudshoorn 1996a, Detmold and Oudshoorn 1996b] have demonstrated an effective means to exploit the first strategy whilst maintaining the simplicity of single threaded clients. This ....

....batch which correspond to the results of previous requests (within the batch) On the server, these placeholders are replaced by the values of the results of the requests as these are computed. It should be noted that this use of laziness is orthogonal to the laziness in systems such as Promises [Liskov and Shrira 1988], Futures [Walker et al. 1990] and Wait by necessity [Caromel 1991, Caromel 1993] These systems would still require four messages to perform the interaction and, hence, would provide little benefit; note however that it is feasible to add batching to Wait bynecessity [Caromel and Detmold 1995] ....

Liskov, B. and Shrira, L., "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", in Proceedings of the Sigplan'88 Conference on Programming Language Design and Implementation, pp. 260--267, Atlanta, Georgia, June 22--24 1988.

....by CML is a good base for distributed programming. Its support for low level I O is sufficient to build a structured synchronous interface to network communication (as was done in eXene) Higher level linguistic support for distributed programming, such as the promise mechanism described in [LS88] can be built using events to define the new abstractions. 4 Another example is Chet Murthy s reimplementation of the Nuprl environment [Con86] using CML. His implementation is structured as a collection of proof servers running on different workstations. When an expensive operation on a ....

Liskov, B. and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, June 1988, pp. 260--267.

....the code using the CopyArea operation must also scan the event stream for the acknowledgement. In eXene, where we have concurrency and events, we can handle this operation in a much more elegant way. Our solution is to implement CopyArea as an asynchronous RPC operation, also known as a promise [LS88] EXene provides an event valued function with the type val copyArea : arg type rectt list event where arg type is the type of the arguments that specify the actual operation. The event that is returned is the promise of the result. Figure 9.6 gives the implementation sketch of this operation, ....

Liskov, B. and L. Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, June 1988, pp. 260--267.

....and reveals several limitations. Section 4 introduces a novel language construct designed to avoid these limitations. This new construct takes the form of a new type constructor called a responsibility. This is a generalization of previous constructs such as promises, Liskov and Shrira [12] and futures, Walker et.al [20] A detailed example and the framework of Section 2 are used to assess responsibilities. Section 5 concludes the paper and explores future directions. 2 Assessing Communication Constructs The criteria used to assess communication constructs can be divided into ....

....user defined generic (template) types, typically provide a generic type, parameterized by the type of the result the future is to hold. However, these futures are not first class types: being purely local objects they can not be sent in messages. Promises: The promises type, Liskov and Shrira, [12], provides a mechanism similar to futures. A notable addition is the support for exception handling: an exception raised during service of the RPC or during com munication is sent back to the client and stored in the promise. This exception is re raised when the client attempts to demand the ....

Liskov, B. and Shrira, L., "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", in Proceedings of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pp. 260-267, Atlanta, Georgia, June 22-24 1988.

....ones. The similarity in performance to SUN RPC is not surprising; it simply reflects the fact that we use a protocol machine implementation similar to SUN RPC. 6 Related Work Much RPC work focuses on designing and implementing new RPC systems to provide new semantics and better performance [10, 8, 11, 12, 13, 14, 15, 16, 17]. Although our toolkit also provides some popular RPC semantics, it is aimed at providing mechanisms for RPC developers to prototype new RPC systems rapidly. The URPC toolkit achieves its flexibility by letting programmers match the requirements of different RPC semantics by providing their own ....

B. Liskov and L. Shrira. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed System. In Proc. of the SIGPLAN'88 Conference on Programming Language Design and Implementation, pages 260--267, June 1988.

....asynchronous RPC, using a mechanism called a call stream to guarantee that procedure calls and their return values reach their recipients in the same order that they were sent. Q [52] is an RPC mechanism that provides point to point communication between C and Ada programs. The promise approach [48] is similar to asynchronous remote procedure calls but uses the principle of lazy evaluation. In this approach, if a remote procedure call is made that should return a value of type t, the call immediately returns a placeholder, called a promise, to stand in for the true return value. This allows ....

Liskov, Barbara, and Shrira, Liuba. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the 1988 Conference on Programming Language Design and Implementation (SIGPLAN) (Atlanta, Georgia, June 1988), pp. 260--267.

No context found.

Barbara Liskov and Liuba Shrira. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the SIGPLAN'88 conference on Programming Language Design and Implementation, pages 260--267, 1988.

No context found.

LISKOV, B., AND SHRIRA, L. Promises: Linguistic support for efficient asynchronous procedure calls in distributed systems. In Proceedings of the ACM Conference on Programming Language Design and Implementation (Atlanta, Georgia, June). ACM SIGPLAN Notices 23, 7 (July 1988), pp. 260--267.

No context found.

Barbara Liskov and Liuba Shrira. Promises: linguistic support for efficient asynchronous procedure calls in distributed systems. In PLDI, pages 260--267, July 1988.

No context found.

Liskov, B. and Shrira, L., "Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems", in Proceedings of the Sigplan'88 Conference on Programming Language Design and Implementation, pp. 260--267, Atlanta, Georgia, June 22--24 1988.

No context found.

B. Liskov and L. Shrira, `Promises: linguistic support for efficient asynchronous procedure calls in distributed systems', Proc. SIGPLAN '88 Conference on Programming Language Design and Implementation, Atlanta, Georgia, June 1988.

No context found.

Liskov B and Shrira L. (1988) Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems, Proc. SIGPLAN Conference on Programming Language Design and Implementation, pp. 260-267.

No context found.

Liskov B., and Shrira L. Promises: Linguistic Support for Efficient Asynchronous Procedure Calls in Distributed Systems. Massachusetts Institute of Technology, Programming Methodology Group Memo 60-1, 1988.

First 50 documents  Next 50

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