If there is any overhead to sharing memory, the performance of the system would increase if heavily used pieces of code were duplicated, perhaps in local memory associated with each processor, or in shared memory modules that, by agreement, are primarily used for each processor.
Fault tolerance may require that duplicate copies of everything be maintained in order to survive the failure of any particular memory module. Other reasonable answers should be accepted.
Part B: What system models are able to support shared files, what system models are able to support messages, and why or why not?
Given a network file system, any system model can support shared files, whether it is a uniprocessor, multiprocessor, distributed or network operating system. Note that a network file system embedded in a conventional operating system blurs the line between conventional operating systems and network operating systems -- in effect, one high level component of the system is distributed while the low levels are not.
Message passing as a primitive for interprocess communication can clearly be supported on any system, from the smallest uniprocessor to the most loosely coupled network of machines. This does not imply that message passing is necessarily possible under any particular operating system, but rather, it implies that it can be supported under any system model.
A system would be considered virtual memory transparent if applications that ran correctly on the same architecture without virtual memory ran without apparent changes when virtual memory was substituted for the physical memory expected by the program. Such things as insufficient real memory (leading to thrashing) would make the system non-transparent to a human user, and the virtual-memory may be non-transparent to hard real-time applications if even a single page fault caused a timing change in some critical parts of the code.
Part B: Relate the definition of transparency, as used by Tannenbaum, to the commonplace English definition of the word, and having done this, come up with a definition for the term opacity in the operating system context.
Tannenbaum's usage does not readily admit to an answer to this question, so almost anything sensible answer was acceptable here. In fact, the original definition of the term in computer science is not quite the same as Tannenbaum's definition. Transparency, in a hierarchically structured system, relates to the extent to which state changes that occur at a low level in the hierarchy are visible from higher levels in the hierarchy. Transparent hierarchically structured systems allow all states reachable in the low level system to be reached from the high level, while an opaque layer in a hierarchy prevents some state from being reached.
Transparency in a hierarchically structured system is desirable if it allows high-level user can make the system do anything the system would have been able to do under direct low-level control. On the other hand, transparency confirs risks -- a transparent system does nothing to prevent users from putting the system in an unsafe state. The layers in any hierarchically structured system are expected to offer abstraction, but in an opaque system, the layering also offers protection by preventing entry into unsafe states. Of course, opacity has the disadvantage that it may also prevent entry into desirable states.
Tannenbaum's usage of the term Transparency is not necessarily inconsistant with this usage, but he doesn't pin down his usage nearly as carefully, and as a result, as he says, the term becomes very slippery.
In a uniprocessor system, we build hierarchies that are very similar to protocol hierarchies. A calling sequence for a procedure is really nothing more than a protocol for communicating with that procedure, and when we package the low level interface to some abstraction behind an interface procedure, we're building a protocol hierarchy.
In the exam question, a protocol was required for using the low level interprocess communication primitives to communicate with a FIFO queue server process. A user of this protocol would probably ask for a higher level protocol, using client stubs named enqueue and dequeue to hide the use of low level primitives from user level applications.