Due: Tuesday October 7 at 11:59pm
Each question is worth 5 points. When a question asks you to describe or explain, your answers can be relatively brief. The [name] tags give scholarly attribution to authors of other OS textbooks who wrote the question (you do not need those textbooks to be able to answer the question, though). You may type or handwrite your answers.
You will submit your homework electronically via gradescope. Once you have logged in, follow these general instructions for uploading your homework (we will post to piazza when gradescope is ready for submissions).
a) Set value of timer
b) Read the clock
c) Clear memory
d) Turn off interrupts
e) Switch from user to monitor (kernel) mode
On Unix, two signals that cannot be caught and handled by an application are SIGKILL and SIGSTOP.
a) SIGKILL immediately terminates a process. What is a scenario that motivates having the OS make it impossible for an application to handle SIGKILL?
b) SIGSTOP immediately pauses a process (which can later be resumed with SIGCONT). Why is it safe (in terms of application correctness) for an application to be arbitrarily paused using SIGSTOP?
Below is a small C program that prints the passage of time in seconds using the simple Unix alarm interface (see man 2 alarm on ieng6):
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
volatile int seconds;
void handler (int signum) {
seconds++;
alarm (1); // schedule next SIGALRM
}
int main (int argc, char *argv[]) {
int last = seconds = 0;
signal (SIGALRM, handler); // SIGALRM is the timer signal
alarm (1); // schedule SIGALRM handler callback, arg is # of seconds
while (1) { // normally we would do useful work instead of spinning
if (last != seconds) {
printf ("%d sec\n", seconds);
last = seconds;
}
if (last == 5) return 0;
}
}
a) What is the output of this program? To verify your answer, you can create a file on ieng6, copy the code into it, and then compile and execute it:
$ ssh account@ieng6.ucsd.edu [do _not_ prep for CSE 120, we need to use the normal system compiler] $ cc q5.c [assuming you put the program contents into q5.c] $ ./a.out
b) Generally it is not possible to predict how long a program will take to execute by inspecting its code. However, for this program we can. Approximately how long does it take to execute? (You can run it on ieng6 with time ./a.out, and for more info about the output from time see man 1 time.)
#include <unistd.h>
#include <signal.h>
#include <stdio.h>
volatile int seconds;
void handler (int signum) {
seconds++;
alarm (1); // schedule next SIGALRM
}
int main (int argc, char *argv[]) {
int last = seconds = 0;
signal (SIGALRM, handler); // SIGALRM is the timer signal
alarm (1); // schedule SIGALRM handler callback, arg is # of seconds
while (1) { // normally we would do useful work instead of spinning
if (last != seconds) {
printf ("%d sec\n", seconds);
last = seconds;
}
if (seconds == 5) return 0; // line changed from problem 5
}
}
Only one line is changed from Problem 5: the "if (...) return 0" statement in the while loop. When executing the program, sometimes the program prints out "n sec" four times and sometimes five times. Briefly explain why. (Again you can compile the program and experiment with it, although you may need to run the program a handful of times to see different outputs.)
#include <stdlib.h>
int main (int argc, char *arg[]) {
fork ();
if (fork ()) {
fork ();
} else {
char *argv[2] = {"/bin/ls", NULL};
execv (argv[0], argv);
fork ();
}
}
a) How many total processes are created (including the first process running the program)? (Note that execv is just one of multiple ways of invoking exec, see man 3 exec for all possibilities.) You do not need to provide an explanation.
b) How many times does the /bin/ls program execute?
[Hint: You can always add debugging code, compile it, and run the program to experiment with what happens.]