Consider the problem of modifying the example thread manager to incorporate an approximation of Demos interprocess communication for communication between threads. To start you thinking along these lines, consider (and answer) the following questions:
Part A: What thread manager services would you eliminate from the existing code?
Thread semaphores (wait, signal, initialize) can be deleted.
Part B: What representation would you use for a Demos-style link? Does this representation require that links be stored in a link-table attached to each thread, or could links be freely intermixed with other data.
A link could be a tuple <t,b>, where t is a pointer to a thread description and b is a box number for that thread. Since the thread manager offers no security, we can omit access rights from links and users can embed links directly in their own data structures, with no need for a link-table attached to each thread.
Part C: Given your answers to the above questions, what thread manager services would you add. For each, document the calling sequence a C programmer would use.
thread_send( linkp, bufp, len ); linkp -- pointer to a link bufp -- pointer to a message buffer len -- length of the message buffer links may be directly embedded in the message buffer, so there is thread_receive( boxno, bufp, len ); boxno -- box number to receive from bufp -- pointer to a message buffer len -- length of the message buffer make_link( linkp, boxno ); linkp -- pointer to place to put a new link boxno -- box number link will receive from
We need to add a timeout on the receive primitive, so that the sender can retry a remote procedure call if no reply is received; this alone accounts for lost messages, and if the client tries an alternate server on the retry, it can also deal with server failures.
Part B: Consider the problem of having a backup server take over once it wins the election that permits it to do this after a primary server failure. What mechanisms does the Demos MP process migration scheme include that might aid in this, and what tools are missing that your server would need in order to use these mechanisms.
Demos MP includes an elaborate forwarding mechanism to support process migration, and if one server wishes to take-over from a failed server, we would need a way for the new server to deliberately enable this mechanism so it receives messages that would otherwise have been addressed to the failed server.