Homework 1 Solution

CS 318

1. (15 pts.) Consider a single processor timesharing system which supports a large number of interactive users. Each time a process gets the processor, the interrupt timer is set to interrupt after the quantum expires. Assume that each process has the same quantum.
   1. What would be the effect of setting the quantum at a very large value, say 10 minutes? What sort of process behavior(s) would preclude this effect?

      From a user's perspective, the system would appear to be extremely overloaded. There would be very long waits for responses from the system. I/O bound processes would tend to obscure this effect.

   2. What would be the effect if the quantum were set to a very small value, say a few processor cycles (machine instructions)?

      Too many of the processor's cycles would be used for the overhead inherent in context switching. Response times would be less than in the previous case, but turnaround times would be much greater than the ideal.

   3. Obviously, an appropriate quantum must be between the values previously mentioned. If you could vary the quantum, how would you determine when you had chosen the ``right'' value? What factors make this value right from the user's standpoint? What factors make it right from the system's standpoint?

      When users stopped complaining about response and turnaround times. When quantums are adjusted so that users are happy with these times, each user feels that they have the machine to themselves. From the system's standpoint, we want to minimize overhead and maximize job throughput.

2. (15 pts.) In Unix, a signal is an abstraction of an interrupt. Non-privileged users are permitted to install their own signal handlers. Recall that interrupt handlers are run in supervisor mode.
   1. Explain why it would be a very bad idea to permit a user's signal handler to run in supervisor mode.

      A user then could write a signal handler which, for instance, halted the system, thus circumventing system security.

   2. Assuming that the mechanism used to invoke a signal handler places the CPU in supervisor mode, suggest a way (by writing pseudo-code) to safely run user's signal handlers. (Hint: assume that the CPU has a UserMode machine instruction which places the machine in user mode.)

      Construct the system so that the following wrapper is called in response to a signal. This wrapper places the system back in user mode then invokes the user's signal handler. This preserves system integrity.

      userSignalHandlerWrapper(argList)
      {
         userMode;
         invoke the user's signal handler, passing argList;
      }
      

3. (20 pts.) An alternative to the TAS instruction is the FAI (Fetch And Increment) instruction. Here are its semantics:

   int FAI(int& val)
   {
      return val++;   // Performed atomically.
   }
   

   Devise a solution to the critical section problem for n processes using this instruction. Instead, model your solution on the manner in which a bakery, for instance, serializes customer service by means of a number dispenser. Prove that your solution meets the three criteria of a solution to the critical section problem. Solutions which treat the FAI instruction as a ``glorified'' TAS instruction will be down-graded. Likewise, simple ports of the bakery algorithm will be down-graded.

   // Global variables.
   
   int current = 0;
   int next = 0;
   
   
   mutexbegin()
   {
      int myTicket = fai(next);
   
      while (current != myTicket)
         ;
   }
   
   
   mutexend()
   {
      ++current;
   }
   

   If n is less than MAXINT (usually the case), this will work even in the face of integer overflows.

   Correctness:

   1. Mutual exclusion: Observe that each process gets a unique, sequential value for myTicket (due to the semantics of fai) and that current has a unique value at each moment in time. If we assume that mutual exclusion is violated and that two processes are executing simultaneously in their critical sections, we derive a contradiction.

   2. Progress: Since myTicket values are meted out in a sequentially ascending order, some waiting process has the ``next ticket'' and it will be that process' turn when the process in its critical section executes mutexend() and increases current. A process not interested in entering its critical section will not hoard a ticket value and, hence, will not participate in the decision as to which process next enters its critical section.

   3. Bounding waiting: If there are n processes, a process' ticket number is at most n-1 greater than the value of current. After waiting a finite amount of time for each of the n-1 processes in before it, this process will be able to enter its critical section.