Homework 12 Solutions

22C:116, Spring 1999

Douglas W. Jones
  1. Parts A and B: Servers in the Amoeba system should all support the following operations, all but the last are listed in Fig 14-5; for each operation, the comments provide the answer to part B:
    Age
    This may apply to objects or to the entire class implemented by the server. Tannenbaum's description doesn't make this clear, nor is it clear that the distinction really matters.

    Touch
    This clearly applies to a single object, and one interpretation is that Touch reverses the effect of Age.

    Copy
    Destroy
    Restrict
    These clearly apply to individual objects

    GetParams
    Setparams
    These apply to the entire class, not to individual objects

    Info
    This is the analog of GetParams, but it applies to one object

    Status
    Like GetParams, this applies to the server or class as a whole. The difference between Status and GetParams is somewhat arbitrary, since any status condition of a server could be encoded as a parameter.

    Create
    Although not in Tannenbaum's table, this must be present for any server that actually implements a class of dynamically allocatable objects. Clearly, the semantics of this requires that you direct the create operation at the class, and it should return the created object.

  2. Each Amoeba remote procedure call requires only one translation step to convert a service name to the physical address of a process because processes may not migrate during a remote procedure call. The caller's kernel can inform the called thread's kernel of the caller's physical address using a field in the call message, and once the first message is exchanged, the caller's kernel and the called kernel may keep the addresses they have used for the duration of the interchange. Only if migration were allowed during the RPC exchange, as was the case in the DEMOS/MP scheme, would a new name to address translation be required with each message passed.

  3. If you wanted to use mark-sweep garbage collection for all resources in some class in amoeba, each user process would be required to have some thread ready to accept messages indicating the start of a marking phase, and on receipt of such a message, this thread would be obligated to touch each object for which that process holds a capability. The Amoeba servers are obligated to support the touch operation, but amoeba only approximates the requirement stated here with the somewhat vague requirement that each user must occasionally touch any object the user wishes to see preserved.

  4. A Mach exception handler is a thread; on receipt of an exception notice from the port of the process it is handling, it must receive access to the thread management capability for the thread that raised the exception. Using this capability, it can (by messages to the thread management server) request a copy of the thread's registers, make changes, and then update the thread's registers before restarting the thread. The exception handler must also have access to the thread's memory address space, either directly (if the handler runs in that address space) or indirectly (perhaps using the process management capability for that thread.

    To force the delivery of a UNIX-style signal to the thread that raised the exception, the handler must make changes to the thread's registers and memory region that simulate a call to the signal handler. The details of this simulation depend on the instruction set and the calling conventions for external functions, but on a steriotypical machine, this simulation might involve pushing the PC on the thread's stack (using the thread's SP register), then setting the thread's PC to the handler address.