SlideServe
Télécharger Obtenir Pro
Menu
Accueil Pro
Préférences
ApparenceLight Aide et commentaires
© SlideServe · v2026

Lightweight Remote Procedure Call

pmarable avatar
pmarable
21 diapositives · 301 Views · Jan 03, 2020

Lightweight Remote Procedure Call. BRIAN N. BERSHAD, THOMAS E. ANDERSON, EDWARD D. LASOWSKA, AND HENRY M. LEVY UNIVERSTY OF WASHINGTON. PRESENTER: ALIREZA GOUDARZI Jan 27, 2010 alirezag@cecs.pex.edu CS 533 , Winter 2020 , John Walpole.

Lightweight Remote Procedure Call - slide 1
01 / 21Lightweight Remote Procedure Call
1 / 17

Télécharger la présentation

Lightweight Remote Procedure Call
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation

  1. Lightweight Remote Procedure Call BRIAN N. BERSHAD, THOMAS E. ANDERSON, EDWARD D. LASOWSKA, AND HENRY M. LEVY UNIVERSTY OF WASHINGTON PRESENTER: ALIREZA GOUDARZI Jan 27, 2010 alirezag@cecs.pex.edu CS 533 , Winter 2020 , John Walpole "Lightweight Remote Procedure Call" by B. N. Bershad, T. E. Anderson, E. D. Lazowska, and H. M. Levy, Proceedings of the 12th Symposium on Operating Systems Principles, pp. 102-113, December 1989. 

  2. Waves of Computing Paradigms Centralized Limited capacity , expensive , hard to manage , low reliability …. Distributed You are here Virtualization & Cloud Ubiquitous computing

  3. Distributed Computing • Each machine run a monolithic kernel OS • Distributed application talk to each other • Machines ( OS ) talk to each other OS OS Machine Machine OS OS Machine Machine RPC: Inter-machine communication with abstraction of a procedure call. • Domain of protection is an entire machine • OS internally is one piece

  4. Emergence of Microkernel in OS From Wikipedia : http://en.wikipedia.org/wiki/Architecture_of_Windows_NT Modularity correctness hit the kernel atmosphere

  5. Microkernel Implications • Separate components • Separate protection domains • Might or might now sharing the same address space • Component inter-comm. in a shared memory  conventional IPC What’s wrong with that ?

  6. IPC • way too much coupling between components • Logic and semantics of components are exposed • Defies the purpose of modular design • Difficult to use • Control flow transfer is awkward ? You are here What’s the problem?

  7. THE BIG PROBLEM • Control flow transfer • Data transfer • Separate address space • On a same memory space

  8. RPC • Syntax of a procedure call • Semantics of a procedure call • But!....

  9. RPC : Control Flow / Data Transfer Server Client Kernel 4 context switch , 4 buffer copy , expensive access validation , expensive stubs Expensive scheduling Different naming but gist of it is that these are separate address spaces ( might be in the same shared memory or not ) and to give them access to the data you have to copy the data back and forth Any Alternatives?

  10. Protected Procedure Call • Each object is protected with an Access Control List (ACL) • Different objects can access each other if their have the right permission to another object. • Then an object can call a procedure if it has sufficient right to do so. • But….

  11. Protected Procedure Call • It is just a procedure call. • Within a single address space • address space / protection domain => NO REAL IPC

  12. Solution Lightweight Remote Procedure Call Efficiency of protected procedure call + IPC semantics of remote procedure call =

  13. Lightweight-RPC : The Middle Way • Observations in RPC systems : • Most communications are not cross-machines • Most attributes are simple not complex • LRPC as a RPC exploiting the single machine boundary.

  14. Main Gains • Simple control transfer ( b/w addr. spaces) • Simple data transfer ( b/w addr. spaces) • Simple stubs ( low overhead ) • Designing with single-machine-concurrency in mind.

  15. LRPC Call: Control Flow TransferProcedure Call ( hand-off scheduling) • Semantics imply we can safely bypass scheduler ! Why? • We can invoke the server procedure with only one formal call !!! How?

  16. LRPC: Call Client Server Stub Stub 2- Copy of Param. 4-upcall P-ID 1- call A-Stack Kernel L-Stack E-Stack U-thread + Server Stack 3 – prepare the context

  17. LRPC Call : Multiprocessor • TLB miss problem in server domain • CPU context caching in multiprocessor system • CPU idles on server / client domain • CPU context migration is cheaper than flushing and reloading TLB • No locks only one for each A-stack queue in client stub.

  18. LRPC: Binding • How does validation work? ( call / return ) • How does client find the server? • How does kernel allocate and manage memory?

  19. LRPC Binding: Client Import Client Server 2- listening Stub Stub 3- request 3- response 4- binding 1- registration PDL Binding O A-Stack Kernel L-Stack E-Stack

  20. Special Cases • Between Machine Calls • Complex/Large Params. • Termination

  21. Q & A You are here