|
Test Problem |
features tested |
Remark |
|
|
alloc_port() |
Two different kernels alloc ports |
|
|
ssend() |
Send to remote receiver |
|
|
asend() |
“ |
|
|
mrecv() |
Receive from remote sender |
|
|
guarded mrecv() |
Guarded receive from remote sender |
|
|
wait() |
Waits to a semaphore from different kernels |
|
|
signal() |
Signals to a semaphore from different kernels |
|
|
Preemptive scheduling |
|
|
|
sleep10() |
|
|
|
sleep() |
|
Describe each kind of error demonstrated by the test
cases. Insert the information here
and not somewhere else!
Briefly describe each test problem (here and not somewhere else!) does (e.g. multiplication of two matrices). Give the sample output you will demonstrate. Explain how the output tests the system calls used in it.
Again, insert your answers here!
Can you use the
Unix sleep call to implement the Xinu sleep10 call?
How did you handle
the problem of restoring interrupts when context switch occurs to a newly
crated process?
Why not use blocking
reads to get information from sockets?
How frequently
should you poll for socket input - give the advantages/disadvantages of polling
frequently/rarely, and justify the frequency you picked.
Why does
partitioning the port name space violate the transparency principle?
How can you make the Xinu IPC calls ( alloc_port, req_port, asend, ssend, mrecv ) efficient - in particular, how can you reduce the number of Unix messages a Xinu IPC call sends? (Hint: think caching or replication of data structures.) It may not be possible to make all Xinu IPC calls efficient in a single implementation, in which case, which ones have you favoured and why? For each of these calls, explain how many Unix messages may be sent.
Instead of
enclosing ctxsw within Disable and Restore, you could have ctxsw call Restore
before returning. What could go wrong under this approach?
Can disabling ctxsw
within Disable and Restore interfere with context switching to a newly created
process?
Attach the full code of the program(s) implementing the problems. Do not attach your implementation of the system calls.