i) Can a server invoked by lightweight procedure calls control the degree of concurrency within it? ii) Explain why and how a client is prevented from calling arbitrary code within a server under lightweight RPC. iii) Does LRPC expose clients and servers to greater risks of mutual interference than conventional RPC (given the sharing of memory)?

Question

What will be an ideal response?

Answer 1

i) Although a server using LRPC does not explicitly create and manage threads, it can control the degree of
concurrency within it by using semaphores within the operations that it exports.
ii) A client must not be allowed to call arbitrary code within the server, since it could corrupt the server’s data.
The kernel ensures that only valid procedures are called when it mediates the thread’s upcall into the server,
as explained in Section 6.5.
iii) In principle, a client thread could modify a call’s arguments on the A-stack, while another of the client’s
threads, executing within the server, reads these arguments. Threads within servers should therefore copy all
arguments into a private region before attempting to validate and use them. Otherwise, a server’s data is
entirely protected by the LRPC invocation mechanism.