csci4061/lab08-code/QUESTIONS.txt
Michael Zhang 041f660ccd
f
2018-01-29 17:28:37 -06:00

102 lines
2.6 KiB
Text

__________________
LAB 08 QUESTIONS
__________________
- Name: (FILL THIS in)
- NetID: (THE kauf0095 IN kauf0095@umn.edu)
Answer the questions below according to the lab specification. Write
your answers directly in this text file and submit it to complete Lab01.
PROBLEM 1 `server_em.c'
=======================
A
~
Examine the source code for `em_server.c'. Note of the 3 FIFOs that
are used: Requests, Completions, and Data. Describe what appears to
be the purpose of each from the server perspective.
B
~
What mechanism is used to notify clients that their request has been
filled and that data is ready on the Data FIFO?
C
~
How many clients have information on each of the FIFOs:
- On the Request FIFO?
- On the Completion FIFO?
- On the Data FIFO?
PROBLEM 2 `client_em.c'
=======================
Note that `read_AB.c' uses the same techniques as `sleep_print.c' to
set up signal handlers and shut down on receiving a signal.
A
~
Examine the `while()' loop in the client. When waiting for the server
to respond, does the client make use of busy waiting (polling),
interrupt-driven waiting, or something in between?
B
~
Experiment with changing the while() loop associated with server
responses. Time running 100 transactions using the provided
`run_simulations.sh' script as in
,----
| $> time run_simulation.sh 100 > xxx
`----
Note the timing. You may need to discuss with your TA how to interpret
the results of the shell `time' command which measures CPU utilization
for programs.
Comment out the `while()' loop associated with waiting and un-comment
the other `while()' loop. Re-run the above script invocation and
report the differences in timing.
PROBLEM 3 Protocol
==================
A
~
Describe the overall protocol used by the client and server to
communicate. Use the labels in the messages like `C SERVER' and `B
CLIENT' to help you organize the order what happens when and things
can happen in an unpredictable order.
B
~
In an initial version of the programs, the client used the following
line to wait for a server response.
,----
| raise(SIGSTOP);
`----
The `raise()' command sends a signal to the running process so that
the effect of this line is to stop the current process until a signal
to continue is received. This approach was found to fail in many
cases causing the entire system to stall.
Based on your understanding of the protocol above, WHY could simply
stopping the client process result a breakdown?
You may wish to uncomment and try this version in the code.