Bershad, B. N., Anderson, T. E., Lazowska, E. D., and Levy, H. M. 1990. Lightweight remote procedure call. ACM Transactions on Computer Systems 8, 1 (Feb.), 37--55.  Home/Search   Document Not in Database   Summary   Related Articles   Check

.... has been done in the last decade, most notably by Liedtke [20, 21] Ford [8] and Shapiro [31] Though the KeyKOS capability invocation mechanism [11] predates it, most of the current work on thread migrating IPC derives in some measure from the lightweight remote procedure call work by Bershad [2]. Work on packet filtering [26, 24, 6] is similar in flavor to the more restricted filtering performed by filtering indirectors. We are not aware of such filters being used to defer packet processing, nor do they appear to have been used to filter dynamically tagged messages. Use of registers to ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. In Proc. 12th Symposium on Operating Systems Principles, pages 102--113, Dec. 1989.

....cost of context switches could be reduced compared to present processors. This paper presents Legba, a new protection cache architecture, which is designed to reduce the granularity of protection, without limiting the processor s clock rate. Legba furthermore supports a protected procedure call [20,21] mechanism which allows a program to change its protection domain in a controlled manner without the need to enter the operating system (OS) kernel. This enables fast protected component invocation. The reminder of this paper is organised as follows. Section 2 presents related work, Section 3 ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. In Proc. 12th ACM SOSP, pages 102--113, Dec 1989.

....address space boundaries to make the remote procedure call and returns when it is complete. Handoff Scheduling implements this logical single thread by optimizing control transfers between two threads. A further refinement is to use a single thread of control to match the logical control flow [3, 26]. This thread directly executes the call in the remote address space and returns when the call is complete. Performance is improved because only the address space is changed; there is no need to switch threads in the operating system, eliminating the overhead of blocking and waking up the threads ....

....executes the call in the remote address space and returns when the call is complete. Performance is improved because only the address space is changed; there is no need to switch threads in the operating system, eliminating the overhead of blocking and waking up the threads involved in the handoff [3]. Hardware support for the address space change can further improve performance of this mechanism by eliminating the trap into and return from the operating system kernel [26] This technique effectively separates threads from address spaces, and thereby introduces some process control ....

[Article contains additional citation context not shown here]

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight Remote Procedure Call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

.... (see related work in Section 2 for more details) Finally, communication across process domain boundaries to a database server process provides protection, but such communication is orders of magnitude slower than access in the same process space, even with highly tuned implementations [8]. Due to this cost, an increasing number of systems give application code direct access to system buffers, including extensible systems [73] object databases [46, 3] and memory mapped or in memory architectures [41, 66, 70] In [75] Sullivan and Stonebraker investigate the use of hardware ....

B. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

....to a database server process provides protection, but such communication is orders of magnitude slower than access in the same process space, even An error occurs in a system when its behavior deviates from the behaviors allowed by its specification. with highly tuned implementations [BALL90] With multi gigabyte main memories now easily affordable, one can expect many OLTP databases to be fully cached, decreasing the impact of disk latency on performance and consequently increasing the relative impact of inter process communication. In [SS91] Sullivan and Stonebraker investigate ....

B. Bershad, T.E. Anderson, E.D. Lazowska, and H.M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

....to classic monolithic designs. Liedtke [Liedtke 95] has disputed this result by demonstrating microkernel implementations that dramatically lower the cost of domain crossings. However, he agrees that the crossing cost is key. There has been much work on improving the speed of domain crossings [Bersh 90] Ford 93] and on reducing the number of such crossings [Bogle 94] Condict 94] The problem is projected to get worse as hardware optimizations such as pipelining and caching increase the cost of context switches. Some researchers have proposed hardware support [Carter 94] and new software ....

Bershad B., Lightweight Remote Procedure Call, ACM Transactions on Computer Systems, No. 1, February, 1990 23

....to the server, and then back to the client, can add significant latency to the time taken for a message passing RPC to complete. Furthermore, the server may not be eligible to receive CPU time at the point of the invocation, increasing the latency further. Thread tunnelling [Wilkes79, Bershad90, Chase93] aims to reduce the latency and synchronisation costs associated with message passing on a intra machine call by switching the calling thread into the protection context of the server. This avoids the overhead of calling into the scheduler and waking the server thread. If the arguments ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight Remote Procedure Call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990. (p 77)

....vsscs.utk.edu (Sathish S. Vadhiyar) dongarracs.utk. odu (Jack J. Dongarret) Preprint submitted to Elsevier Science 5 February 2003 1 Introduction Remote Procedure Call (RPC) mechanisms have been studied extensively and have been found to be powerful abstractions for distributed computing [1,2]. In RPC frameworks, the end user invokes a simple routine to solve problems over remote distributed resources. A number of RPC frameworks have been implemented and are widely used [3 11] In addition to providing simple inter faces for uploading applications into the distributed systems and for ....

B. Bershad, T. Anderson, E. Lazowska, H. Levy, Lightweight Remote Procedure Call, ACM Transactions on Computer Systems (TOCS) 8 (1) (1990) 37 55.

....address spaces are not shared, the data must be copied. For example, copying is necessary when two processes are on di#erent machines. Copying was the traditional approach to communication in RPC systems [12] although research has been aimed at reducing the cost of copying for same machine RPC [11]. Mach [1] for example, used copy on write and out of line data to avoid extra copies. Java s version of RPC, called remote method invocation (RMI [17] uses copying in its object serialization framework. If data copying is the only means of communication between processes, then memory ....

Bershad, B. N., Anderson, T. E., Lazowska, E. D., and Levy, H. M. Lightweight remote procedure call. ACM Transactions on Computer Systems 8, 1 (February 1990), 37--55.

....For example, a special path through the scheduler is used to minimize the cost of the two context switches. But same machine RPC in our system has not been as thoroughly worked over as intermachine RPC. Much better performance for same machine RPC is possible, as demonstrated by Bershad et al. [1], who achieve 20 times the latency of a local procedure call. Fortunately, their scheme for fast same machine RPC and our scheme for fast intermachine RPC fit together well in the same system. 1.1 Hardware and System Characteristics The Firefly multiprocessor allows multiple VAX processors ....

BERSHAD, B. N., ANDERSON, T. E., LAZOWSKA, E. D., AND LEVY, H.M. Lightweight remote procedure call. ACM Trans. Cornput. Syst. 8, i (Feb. 1990).

....patterns in high performance environments, we believe the flexibility provided by these two architectures is essential for satisfying the necessary security and performance requirements. A seminal work on Lightweight Remote Procedure Calls optimizes RPCs between processes on the same machine [2]. This concept could be incorporated in any high performance messaging layer, disabling all security encryption of the data when being sent to another processes on the same machine. The focus of our paper, however, is on RPCs that traverse the network. 7. CONCLUSIONS Because of the performance ....

Bershad, Brian et. al. "Lightweight Remote Procedure Call". ACM Transactions on Computer Systems, Vol. 8, issue 1, pages 37-55, February 1990.

....some design tradeoffs for a high performance RPC system, their networks were bandwidth limited and much slower than their hosts, a different environment than current day SANs. For example, their network latencies were milliseconds, 100 s of times larger than SAN latencies. Bershad et al. [1] implemented a high performance RPC system for local RPC s which appears to have been the basis for MSRPC s local RPC implementation. Bershad s LRPC improved the speed of local RPC s by a factor of three without impacting remote performance. Their design optimizations for crossing protection ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. In Proceedings of the Symposium on Operating Systems Principles, pages 102--113, 1989.

....with parameter objects, a per call quota for parameter data is used in JX. Another problem is that the object identity is lost during copying. Although parameter copying can be avoided in a single address space system, and even for RPC between address spaces by using shared communication buffers [7], we believe that the advantages of copying outweigh its disadvantages. The essential advantage of copying is a nearly complete isolation of the two communicating protection domains. The only time where two domains can interfere with each other is during portal invocation. This makes it easy to ....

B. N. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy. Lightweight remote procedure call. In Operating Systems Review, 23(5), pp. 102-113, Dec. 1989.

....Firefly RPC facility [32] uses a global buffer pool, which resides in memory shared among all user address spaces, whereas in the fbuf scheme presented by Druschel and Peterson [9] buffers are shared only across the members of a particular data path. In the LRPC scheme presented by Bershad et al. [3], client and server use privately shared memory for argument passing. The remapping approach uses move rather than copy semantics and is thus limited to situations where the client does not need further access to the data after the call. Also, revoking memory from an address space can be a costly ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. In Proceedings of the 12th ACM Symposium on Operating Systems Principles, pages 102--113. ACM Press, Dec 1989.

....isolation has proven its e#ciency (see [3] section 5) In our architecture, we monitored the cost of an absolute branch instruction with software based memory isolation and found that the increase of the execution time was only of 16.67 . We compared this inter process call with an optimised LRPC [4] implemented over hardware isolation in Think and found that the LRPC is more than 25 times slower than our mechanism. 4 Related work Compared to the OSKit [5] framework and set of libraries, Think provides a better flexibility since all components are independent. The Ka#eOS [6] project ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, Henry M. Levy. Lightweight Remote Procedure Call. In ACM Transactions on Computer Systems, Vol. 8, No. 1, February 1990, pages 37-55.

....isolation has proven its e#ciency (see [2] section 5) In our architecture, we monitored the cost of an absolute branch instruction with software based memory isolation and found that the increase of the execution time was only of 16.67 . We compared this interprocess call with an optimised LRPC [3] implemented over hardware isolation in Think and found that the LRPC is more than 25 times slower than our mechanism. 4 Related work Compared to the OSKit [4] framework and set of libraries, Think provides a better flexibility since all components are independent. The Ka#eOS [5] project proposes ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, Henry M. Levy. Lightweight Remote Procedure Call. In ACM Transactions on Computer Systems, Vol. 8, No. 1, February 1990, pages 37-55.

....and therefore no code is generated. Finally, for an absolute branch (such are used in interprocess calls) the segment matching induce an increase of 16.67 , which is very competitive compared to the cost of IPC through hardware isolation. We compared this interprocess call with an optimised LRPC [11] and found that the LRPC is more than 25 times slower than our mechanism. We then monitored the runtime for two significant algorithms. We first sorted 100000 integers with the bubble sort algorithm and found 56970 ms without segment matching and 116280 ms with it, resulting in multiplying the ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, Henry M. Levy. Lightweight Remote Procedure Call. In ACM Transactions on Computer Systems, Vol. 8, No. 1, February 1990, pages 37-55.

....choices lead to trade o s between exibility, portability, and performance. A number of previous works has focused on the development of high performance RPC mechanisms either for single processors or for tightly coupled homogeneous parallel computers such as shared memory multiprocessors [12, 13, 14, 15]. A contribution of those works is to achieve high performance by providing RPC mechanisms that map directly to low level O S and hardware functionalities (e.g. to move away from implementations that were built on top of existing message 8 passing mechanisms as in [16] By contrast, our work on ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight Remote Procedure Call. ACM Transactions on Computer Systems (TOCS), 8(1):37-55, 1990.

....the data stored at the server or otherwise interfere with the server s operation. However, crossing a domain boundary can be expensive. If the client and server are distinct processes running on the same machine, each call requires a context switch, which is much slower than a direct function call [1]. When the client and server are running on separate machines, and need to communicate across a network, the cost of a context switch is even worse. In previous work, Bogle [3] presented a mechanism, called batched futures, for sending calls to the server in batches. Normally, each call is sent ....

....: env sum) i to(closure c, int start, int stop) for(int j : start; j =stop; j ) c.F(c. env, j) ITERATOR Figure 6 5: Iterator and closure CLOSURE var body function obj F(env, val) env var) val eval(env body) METHOD FOREACH iterator METHOD args[1] . METHOD args[i] ARG ref func I(closure cl, cl.F(cl.env, val) env Figure 6 6: Foreach Node 49 Performance Results This chapter presents the results of measurements that demonstrate the efficiency of the BCS mechanism. The first set of experiments compares BCS to ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1), February 1990.

....are inherently more costly than others. For example, Bershad has argued that a cross address space procedure call has an inherent cost that is about 20 times greater than that of a local procedure call, while the best implementations of cross network procedure call are about 100 times as costly [3]. We should not be surprised to find similar differences in the costs of local and remote invocation. However, we believe that successful mechanisms will have the property that their costs fall almost entirely on those that use them. Programs and components that do not use an advanced facility ....

Bershad, B. N., Anderson, T. E., Lazowska, E. D. and Levy, H.M. "Lightweight Remote Procedure Call". Trans. Computer Systems 8, 1 (February 1990), pp.37-55.

....lack of hardware support (i.e. a counterpart to a system trap) available on the Sun 3 75. Note that by combining UKRPC with KURPC, one gets a user to user RPC (LRPC) time of approximately 244 tsec in the null argument case, which is comparable to LRPC times reported elsewhere in the literature [2]. I I MC68020 I I No Arguments I 1871 I One IOData (128 bytes) Argument I 240 I I Two nl: Arguments, nl: result I 2471 Table 3: KURPC Performance (sec) Finally, we measured the round trip performance of Lipto s network RPC service suite. This is interesting for two reasons. First, this suite ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37 55, Feb. 1990.

....performance. The faster I O devices now available benefit in terms of performance and or 31 functionality by appropriately tailored OS support for communication. Much work has been done on IPC over the past 15 years, either to enrich the primitives, or purely for performance reasons e.g. [Birrell84, Karger89, Bershad90, Schroeder90, Liedtke93, Johnson93]. This work is relevant to the provision of QoS isolated traffic streams, because any system with protection boundaries on the data path needs to ensure that IPC does not become a bottleneck, as argued in [Hsieh93] 2.3.1 Lightweight IPC The early work on RPC [Birrell84, Schroeder90, Johnson93] ....

....no thread of control associated with the server code. The server captures the calling client s thread and uses it to run its code within its own protection domain. This is very similar to the protected procedures provided by the CAP computer and described previously in Section 2.3.2. Taos LRPC [Bershad90] presents a full IPC implementation, complete with binding phase. Control is transferred by trapping to the kernel, which provides CAP like ENTER and RETURN system calls to invoke operations on an interface once bound. Arguments are passed by copying them onto a special A stack, which is mapped ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February

....range of memory a process is allowed to access. The permission entries in the TLB can also be used to restrict memory accesses, provided that only the kernel is allowed to manipulate TLB entries. Calls between protected domains are handled by the kernel through a remote procedure call mechanism, [3, 4]. 3.3 Software Fault Isolation Software fault isolation, or sandboxing [28] was introduced to avoid the high costs incurred by placing untrusted code in its own address space and accessing it via remote procedure calls. The untrusted code is modified to include address checks before each ....

....proof of safety on the shoulders of the code producer. It is for this reason that proof carrying code will most likely remain out of use for some time. Interpretation and placing untrusted code in hardware protected memory segments are wellunderstood and implemented in contemporary systems, [18, 16, 3]. Software fault isolation requires a special program to be run by the user, to insert the bounds checking, but it imposes no restrictions on the code producer other than leaving a few unused registers, which can be easily handled by the compiler. In contrast, proof carrying code requires ....

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

....component to a given usage context. This approach can lead to considerable performance gains, by eliminating from the general code all aspects not related to that precise context. Specialization has been performed manually by adapting critical program components to the most common usage patterns [5, 28, 29]. Manual specialization improves performance, but has a limited applicability, because the process is error prone. Recently, tools have been developed to automatically specialize programs [1 3, 7, 8, 18, 19] Applications of program specialization are emerging in a number of fields, including ....

B.N. Bershad, T.E. Anderson, E.D. Lazowska, and H.M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

....server are not propagated to the rest of the operating system. An erroneous server is simply terminated by the kernel. The multi server system achieves su#cient fail safety, but the performance is sacrificed because the overheads of inter process communication (IPC) and context switches are large [3, 7]. The performance of this cross domain communication has been improved 6 in recent years [22] The Chorus operating system [38, 37] allows users to download the extension modules created as the user level servers into the kernel without recompiling them. This approach achieves both su#cient ....

Bershad, B. N., T. E. Anderson, E. D. Lazowska, and H. M. Levy, "Lightweight Remote Procedure Call," ACM Transactions on Computer Systems, vol. 8, pp. 37--55, Feb. 1990.

....network calls. An alternative, slightly more optimized approach would have been to simply combine a CORBA module for the rule engine with the other modules for the Benefit Manager application in the same server. When multiple modules exist in the same server, a form of optimized, lightweight RPC [Bershad90] is often used. This results is what is essentially a local function call. While this reduces the data copying and network overhead, it does not address the needless marshalling of data between module boundaries. Since the workflow of rule processing is such that one segment of C code (the ....

Bershad, B.N., Anderson, T.E.., Lazowska, E.D., Levy, H.M., "Lightweight Remote Procedure Call". ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

....like any other resource in Escort, are owned by either a protection domain or a path. This means that the lifetime of a thread is bound by the lifetime of its owner, and as a consequence, threads cannot directly migrate between owners. Keep in mind that the motivation for migrating threads [10] is to allow a single execution context to cross multiple protection domains, but this is already supported in Escort by the explicit path abstraction. In a well designed configuration, thread migration between owners e.g. from one path to another or from one protection domain to ....

....only via predefined channels as represented 80 in our module graph makes arguing about and achieving high levels of security easier. We extend this idea by providing global QoS guarantees in the form of paths, and therefore, enable such a system to deal with denial of service attacks. LRPC [10] and migrating threads [30] are similar to Escort s thread model. Without the path abstraction, however, a migrating thread can be stopped only by destroying all the protection domains it crosses. This makes it substantially more difficult to defend against denial of service attacks. 81 CHAPTER ....

B. N. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy. Lightweight remote procedure calls. ACM Transactions on Computer Systems, TOCS, 8(1):37--55, February 1990.

....IPC message data from multiple user buffers and protocol headers. The ability to use Impulse to construct contiguous shadow pages from non contiguous pages means that network interfaces need not perform complex and expensive address translations. Finally, fast local IPC mechanisms like LRPC [5] use shared memory to map buffers into sender and receiver address spaces, and Impulse could be used to support fast, no copy scatter gather into shared shadow address spaces. 7 Acknowledgments We thank Al Davis, Bharat Chandramouli, Krishna Mohan, Bob Devine, Mark Swanson, Arjun Dutt, Ali ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, Feb. 1990. 32

....than in earlier CISC processors [1] Thus, sophisticated approaches are required to provide such run time confinement at acceptable cost. One possibility is to reduce the overhead caused by crossing domain boundaries. The obvious way to achieve this is to reduce the cost of crossing the boundary [4]. An alternative is to avoid crossing the boundary for every call. Futures are commonly used to increase concurrency by allowing a client to continue execution after making a request of a server, not blocking until the value of the future is required. It is possible to combine the concept of ....

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

No context found.

Bershad, B. N., Anderson, T. E., Lazowska, E. D., and Levy, H. M. 1990. Lightweight remote procedure call. ACM Transactions on Computer Systems 8, 1 (Feb.), 37--55.

No context found.

Bershad, B., Anderson, T., Lazowska, E., and Levy, H. Lightweight Remote Procedure Calls. In ACM Transactions on Computer Systems, pp. 37--54, February 1990.

No context found.

B. N. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, Feb. 1990.

No context found.

Brian Bershad, Thomas Anderson, Edward Lazowska, and Henry Levy. Lightweight Remote Procedure Calls. In ACM Transactions on Computer Systems, pages 37--54, February 1990.

....problems: Architectural performance barriers. The performance of kernel based synchronous communication is architecturally limited by the cost of invoking the kernel and reallocating a processor from one address space to another. In our earlier work on Lightweight Remote Procedure Call (LRPC) [10], we show that it is possible to reduce the overhead of a kernel mediated cross address space call to nearly the limit possible on a conventional processor architecture: the time to perform a cross address LRPC is only slightly greater than that required to twice invoke the kernel and have it ....

BERsu^, B. N., ANdErSOn, T. E., L^zowsr:^, E. D., ^N LEVY, H M. Lightweight remote procedure call. ACM Trans. Comput. Syst. 8, I (Feb. 1990), 37-55. Also appeared in Proceedings of the 12th ACM Symposium on Operating Systems Principles, Dec. 1989.

No context found.

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. In Proc. 12th ACM SOSP, pages 102--113, Dec 1989.

No context found.

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. In Proc. 12th ACM SOSP, pages 102--113, Dec 1989.

No context found.

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. In Proceedings of the 12th ACM Symposium on OS Principles, pages 102-113. ACM, December 1989.

No context found.

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight Remote Procedure Call. In Proceedings of the 12th ACM Symposium on Operating System Principles, volume 23(5), pages 102-13, December 1989.

No context found.

B. N. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

No context found.

Bershad, B. N., Anderson, T. E., Lazowska, E. D. and Levy, H. M. "Lightweight Remote Procedure Call". Proc. 12th ACM Symp. on Operating Systems Prin., Litchfield Park, AZ, December 1989, pp.102-113.

No context found.

B. N. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990.

No context found.

B. N. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37-55, February 1990.

No context found.

B.N. Bershad, T.E. Anderson, E.D Lazowska, and H.M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1), February 1990.

No context found.

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight Remote Procedure Call. In Proceedings of the 12th ACM Symposium on Operating Systems Principles, 1989.

No context found.

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37--55, February 1990. 29.

No context found.

Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy. Lightweight remote procedure call. ACM Transactions on Computer Systems, 8(1):37-- 55, February 1990.

No context found.

B. N. Bershad, T. E. Anderson, E. D. Lazowska and H. M. Levy, `Lightweight remote procedure call', ACM Transactions on Computer Systems, 8, (1), 37--55 (1990).

No context found.

B. Bershad, T. Anderson, E. Lazowska, and H. Levy. Lightweight remote procedure call. In Proceedings of the Twelfth ACM Symposium on Operating System Principles, pages 102-113, Dec. 1989.

No context found.

B. N. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy. Lightweight Remote Procedure Call. A CM Transactions on Computer Systems, 8(1):37-55, February 1990.

No context found.

Bershad, B. N., Anderson, T. E., Lazowska, E. D. and Levy, H. M. Lightweight remote procedure call. ACM Transactions on Computer Systems 8 (1): 37-55, 1990.

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