User-Level IPC for Shared-Memory Multiprocessors: Cross-Address Space Calls without Kernel, Study notes of Operating Systems

Download User-Level IPC for Shared-Memory Multiprocessors: Cross-Address Space Calls without Kernel and more Study notes Operating Systems in PDF only on Docsity!

User-Level IPC for SMPs

• based on paper “User-level Interprocess

Communication for Shared-MemoryMultiprocessors”, Bershad et al.– mixed discussion about user-level threads and

user-level RPC

Cross address space calls

kernel

MT client

MT server

data transfer

Inter-Process Communication

•^

needs to be efficient – performance of systems dependsupon fast IPC mechanism

-^

typical ‘local’ IPC mechanisms– shared synchronization variables– shared memory

-^

typical ‘local’ or ‘remote’ IPC mechanisms– message passing

• both, including message queues, but also unstructured communication• remote procedure calls (RPC)

•^

our discussion will concentrate on ‘local’ communication

Remote Procedure Calls

•^

In RPC, communication between address spaces isstructured similarly to procedure calls

-^

An RPC runtime hides from higher layers addresscrossing, type checking, procedure parameter andresult transfers, etc…)

-^

From the caller’s perspective, RPC aresynchronous calls – can have different failuresemantics

-^

details in following lecture

URPC

•^

standard RPC is kernel-based– this is overkill for multi-threaded applications: argument

similar as for user-level threads: cost of trapping in thekernel, switching memory management context…

•^

URPC is specialization of RPC for a SMM

-^

Characteristics summary:– shared memory is used for passing arguments and results,

without kernel invocation

• address-space switching can be avoided or made less

frequent by lazy address-switch

• valuable for SMPs but also for uniprocessors running

multithreaded programs

IPC requirements

• processor reallocation• thread management• data transferHow to do these without kernel involvement?• first two effect a control transfer from one

address space to another

• is kernel involvement needed for all the

three requirements?

Integrity of data?

• who should do the mapping?• who should check what is being passed in

client’saddressspace the mailbox?

sharedmailbox

server’saddressspace

•^

authentication implied statically– mapping done once by kernel pairwise between client

and server

•^

correctness checked dynamically– on each call-return between client and server by URPC

runtime (runtime responsible for putting data inmemory buffers, inspecting type, range, etc…)

•^

upshot?– cross address space calls can be implemented without

involvement of the kernel – both send and receive canbe done within the user-level library…

• right?

•^

solution:– give P1 to some other ready in client (thread

management at user level)

• if server is already executing on P2 then use it to run

the server thread to handle the call i.e. keep the OS out!

-^

always possible to do this?– if an address space is under-powered then processor

reallocation may be necessary

• solution?

• lazy address switching
  • the scheduler prefers to schedule threads from

the same address space, until it really has togive processor to another address space

• client’s processor given to the server via the

kernel

• processor returned to the client by the server

upon completion of the call via the kernel

• the thread management system in each

address space does the voluntary loadbalancing

What would this mean for uniprocessors?

• the client address space keeps sending

requests (from different threads) and thereceiver(s) will only be scheduled after allrequests are sent!

Example

•^

Client has an editor with two thread T1 and T

-^

T1 invokes a procedure in a window manager,then upon return invokes a procedure in a filecache manager

-^

T2 invokes a procedure in a file cache manager

-^

Initially, the editor and window manager arerunning on two processors, the file cache manageris not scheduled on a processor.

-^

What is the sequence of events?

URPC design decisions

•^

processor reallocation without any schedulingdecision – amortize cost of kernel involvementover multiple cross-address space calls

-^

data transfer via shared memory– no kernel copying, no dynamic protection checking– message channels protected by polling style t&s locks

-^

user level threads– 100 times cheaper than kernel threads for context

switches