Ex.

3:
3.1:
a. Synchronous and asynchronous communication ANS: A benefit of synchronous
communication is that it allows a rendezvous between the sender and receiver. A disadvantage of
a blocking send is that a rendezvous may not be required and the message could be delivered
asynchronously. As a result, message-passing systems often provide both forms of
synchronization.
b. Automatic and explicit buffering ANS: Automatic buffering provides a queue with indefinite
length, thus ensuring the sender will never have to block while waiting to copy a message. There
are no specifications on how automatic buffering will be provided; one scheme may reserve
sufficiently large memory where much of the memory is wasted. Explicit buffering specifies how
large the buffer is. In this situation, the sender may be blocked while waiting for available space
in the queue. However, it is less likely that memory will be wasted with explicit buffering.
c. Send by copy and send by reference ANS: Send by copy does not allow the receiver to alter
the state of the parameter; send by reference does allow it. A benefit of send by reference is that
it allows the programmer to write a distributed version of a centralized application. Java’s RMI
provides both; however, passing a parameter by reference requires declaring the parameter as a
remote object as well
d. Fixed-sized and variable-sized messages ANS: The implications of this are mostly related to
buffering issues; with fixed-size messages, a buffer with a specific size can hold a known
number of messages. The number of variable-sized messages that can be held by such a buffer is
unknown. Consider how Windows 2000 handles this situation: with fixed-sized messages
(anything < 256 bytes), the messages are copied from the address space of the sender to the
address space of the receiving process. Larger messages (i.e. variable-sized messages) use shared
memory to pass the message.

3.2:
If the “at most once” and “exactly once” semantics are not supported by an RPC
mechanism, then it cannot be guaranteed that multiple occurrences won’t happen. This
can be problematic in cases where data is changed. A perfect example of a system that
must employ these semantics is a bank account. If these semantics weren’t used when
doing a deposit, for instance, then multiple deposits may be made when only one was
intended. The same applies for withdrawals. One possible use for a mechanism that has
neither guarantee would be for the purpose of an inquiry and to not change data. For the
bank account example, retrieving a balance or other information on the account would
work with such a system.
If the “at most once” and “exactly once” semantics are not supported by an RPC
mechanism, then it cannot be guaranteed that multiple occurrences won’t happen. This
can be problematic in cases where data is changed. A perfect example of a system that
must employ these semantics is a bank account. If these semantics weren’t used when
doing a deposit, for instance, then multiple deposits may be made when only one was
intended. The same applies for withdrawals. One possible use for a mechanism that has
neither guarantee would be for the purpose of an inquiry and to not change data. For the
bank account example, retrieving a balance or other information on the account would
work with such a system.
If the “at most once” and “exactly once” semantics are not supported by an RPC
mechanism, then it cannot be guaranteed that multiple occurrences won’t happen. This
can be problematic in cases where data is changed. A perfect example of a system that
must employ these semantics is a bank account. If these semantics weren’t used when
doing a deposit, for instance, then multiple deposits may be made when only one was
intended. The same applies for withdrawals. One possible use for a mechanism that has
neither guarantee would be for the purpose of an inquiry and to not change data. For the
bank account example, retrieving a balance or other information on the account would
work with such a system.
If the “at most once” and “exactly once” semantics are not supported by an RPC
mechanism, then it cannot be guaranteed that multiple occurrences won’t happen. This
can be problematic in cases where data is changed. A perfect example of a system that
must employ these semantics is a bank account. If these semantics weren’t used when
doing a deposit, for instance, then multiple deposits may be made when only one was
intended. The same applies for withdrawals. One possible use for a mechanism that has
neither guarantee would be for the purpose of an inquiry and to not change data. For the
bank account example, retrieving a balance or other information on the account would
work with such a system.
If the “at most once” and “exactly once” semantics are not supported by an RPC mechanism,
then it cannot be guaranteed that multiple occurrences won’t happen. This can be problematic in
cases where data is changed. A perfect example of a system that must employ these semantics is
a bank account. If these semantics weren’t used when doing a deposit, for instance, then
multiple deposits may be made when only one was intended. The same applies for withdrawals.
One possible use for a mechanism that has neither guarantee would be for the purpose of an
inquiry and to not change data. For the bank account example, retrieving a balance or other
information on the account would work with such a system.

3.3:
The “exactly once” semantics ensure that a remore procedure will be executed exactly once and
only once. The general algorithm for ensuring this combines an acknowledgment (ACK) scheme
combined with timestamps (or some other incremental counter that allows the server to
distinguish between duplicate messages). The general strategy is for the client to send the RPC to
the server along with a timestamp. The client will also start a timeout clock. The client will then
wait for one of two occurrences: (1) it will receive an ACK from the server indicating that the
remote procedure was performed, or (2) it will time out. If the client times out, it assumes the
server was unable to perform the remote procedure so the client invokes the RPC a second time,
sending a later timestamp. The client may not receive the ACK for one of two reasons: (1) the
original RPC was never received by the server, or (2) the RPC was correctly received—and
performed—by the server but the ACK was lost. In situation (1), the use of ACKs allows the
server ultimately to receive and perform the RPC. In situation (2), the server will receive a
duplicate RPC and it will use the timestamp to identify it as a duplicate so as not to perform the
RPC a second time. It is important to note that the server must send a second ACK back to the
client to inform the client the RPC has been performed.

3.4:
a) A method of time sharing must be implemented to allow each of several processes to have
access to the system. This method involves the preemption of processes that do not voluntarily
give up the CPU and the kernel being reentrant
b)Processes and system resources must have protections and must be protected from each other.
Any given process must be limited in the amount of memory it can use and the operations it can
perform on devices like disks.
c) Care must be taken in the kernel to prevent deadlocks between processes, so processes aren't
waiting for each other's allocated resources.

3.5:
Actions taken by a kernel to context-switch between processes are -

1.The OS must save the PC and user stack pointer of the currently executing process, in response
to a clock interrupt and transfers control to the kernel clock interrupt handler

2.Saving the rest of the registers, as well as other machine state, such as the state of the floating
point registers, in the process PCB is done by the clock interrupt handler.

3.The scheduler to determine the next process to execute is invoked the OS.

4.Then the state of the next process from its PCB is retrieved by OS and restores the registers.
The restore operation takes the processor back to the state in which the previous process was
previously interrupted, executing in user code with user-mode privileges.

Many architecture-specific operations, including flushing data and instruction caches also must
be performed by Context switches
3.6:
The CPU current-register-set pointer is changed to point to the set containing the new context,
which takes very little time. If the context is in memory, one of the contexts in a register set must
be chosen and be moved to memory, and the new context must be loaded from memory into the
set. This process takes a little more time than on systems with one set of registers, depending on
how a replacement victim is selected
3.8:
Named pipes can be used to listen to requests from other processes( similar to TCP IP ports). If
the calling processes are aware of the name, they can send requests to this. Unnamed pipes
cannot be used for this purpose.
Ordinary pipes are useful in situations where the communication needs to happen only between
two specified process, known beforehand. Named pipes in such a scenario would involve too
much of an overhead in such a scenario.
3.9:

Short-term:(CPU scheduler)- selects from jobs in memory, those jobs which are ready to
execute, and allocates the CPU to them.

Medium-term - used especially with time-sharing systems as an intermediate scheduling level. A

swapping scheme is implemented to remove partially run programs from memory and reinstate
them later to continue where they left off.

Long-term (job scheduler) - determines which jobs are brought into memory for processing.

3.10

There are 8 processes created.

3.11:

A: 0; B: 2603; C: 2603; D: 2600.

3.12:

The result is still 5 as the child updates its copy of value. When control returns to the parent, its
value remains at 5.