CS372: Solutions for Homework 5

Problem 1

Consider a uniprocessor kernel that user programs can trap into using system calls. The kernel receives and handles interrupt requests from I/O devices. Would there be any need for critical sections within that kernel?

Yes. Assume a user program enters the kernel through a trap. While running the operating system code, the machine receives an interrupt. Now, the interrupt handler may modify global data structure that the kernel code was trying to modify. Therefore, while there is only one thread that runs inside the kernel at any given time, the kernel may not be re-entrant if access to global data structures is not protected through the use of appropriate mutexes.

Problem 2

System Calls vs. Procedure Calls: How much more expensive is a system call than a procedure call? Write a simple test program to compare the cost of a simple procedure call to a simple system call ("getpid()" is a good candidate on UNIX; see the man page.) (Note: be careful to prevent the optimizing compiler from "optimizing out" your procedure calls. Do not compile with optimization on.)

Run your experiment on two different hardware architectures and report the results.
Explain the difference (if any) between the time required by your simple procedure call and simple system call by discussing what work each call must do (be specific). [Note: Do not provide the source code for your program, just the results].

Hint: You should use system calls such as gethrtime() or gettimeofday() for time measurements. Design your code such that the measurement overhead is negligible. Also, be aware that timer values in some systems have limited resolution (e.g., millisecond resolution).

Solution : A system call is expected to be significantly more expensive than a procedure call (provided that both perform very little actual computation). A system call involves the following actions, which do not occur during a simple procedure call, and thus entails a high overhead:

A context switch
A trap to a specific location in the interrupt vector
Control passes to a service routine, which runs in 'monitor' mode
The monitor determines what system call has occurred
Monitor verifies that the parameters passed are correct and legal

For your experiment, you should measure the total time for a large number of system/function calls, and then find the average time per call in order to overcome the course resolution of your timing functions. For example, here's a sample code for measuring the time taken for a simple system call and a simple function call:

#include <sys/time.h>
#include <unistd.h>
#include <assert.h>

int foo(){
return(10);
}

long nanosec(struct timeval t){ /* Calculate nanoseconds in a timeval structure */
return((t.tv_sec*1000000+t.tv_usec)*1000);
}

main(){
int i,j,res;
long N_iterations=1000000; /* A million iterations */
float avgTimeSysCall, avgTimeFuncCall;
struct timeval t1, t2;

/* Find average time for System call */
res=gettimeofday(&t1,NULL); assert(res==0);
for (i=0;i<N_iterations; i++){
j=getpid();
}
res=gettimeofday(&t2,NULL); assert(res==0);
avgTimeSysCall = (nanosec(t2) - nanosec(t1))/(N_iterations*1.0);

/* Find average time for Function call */
res=gettimeofday(&t1,NULL); assert(res==0);
for (i=0;i<N_iterations; i++){
j=foo();
}
res=gettimeofday(&t2,NULL); assert(res==0);
avgTimeFuncCall = (nanosec(t2) - nanosec(t1))/(N_iterations*1.0);

printf("Average time for System call getpid : %f\n",avgTimeSysCall);
printf("Average time for Function call : %f\n",avgTimeFuncCall);
}

Sample output on a linux machine :

> gcc -O0 testtime.c -o testtime
> ./testtime
Average time for System call getpid : 394.778015
Average time for Function call : 15.080000

Problem 3

When an operating system receives a system call from a program, a switch to the operating system code occurs with the help of the hardware. In such a switch, the hardware sets the mode of operation to supervisor mode, calls the operating system trap handler at a location specified by the operating system, and allows the operating system to return back to user mode after it finishes its trap handling. Now, consider the stack on which the operating system must run when it receives the system call. Should this be a different stack from the one that the application uses, or could it use the same stack as the application program? Assume that the application program is blocked while the system call runs.

Most compilers set the stack pointer to be at the beginning of the stack area when a function is called. Thus, automatic
variables are found underneath the location to which the stack pointer is pointing to (except for the HP PA-RISC, in which
the stack grows upward). Thus,

When an interrupt occurs, the kernel has no idea as to how many automatic variables the user program has allocated on the stack Therefore, it cannot just set the stack pointer past the current call frame of the use program, because it does not know where are the call frame limits. As such, the kernel must use a different stack to execute the interrupt handling routine.
On a multiprocessor, executing on the user stack allows another active user thread (on a different processor) to modify the stack and forcing the kernel to fail (maliciously, or unintentionally).
If the current stack is allocated on the user program's heap (such as in user-level thread packages), then the kernel code can cause a stack overflow and start destroying data in the user's address space.