CSCI 4320 (Principles of Operating Systems), Fall 2003:
Homework 2

Assigned:

October 3, 2003.

Due:

October 9, 2003, at 5pm. Not accepted past class time October 14.

Credit:

40 points.

Reading

Be sure you have read chapter 1 and chapter 2 up through section 2.4.

Problems

Do the following problems. You may write out your answers by hand or using a word processor or other program, but please submit hard copy, either in class or in my mailbox in the department office.

1. (5 points) Most Unix systems include some command that allows you to trace all system calls made by a process or command. Under Linux, this command is strace. For example, to trace all the system calls made during execution of the command ls -l and record the output in OUT, you would type

   strace -o OUT ls -l

   Your mission for this problem is to run strace for a command of your choice, capture the output, and then describe what some of it means. Specifically, I want you to pick at least four lines of the output using different system calls and briefly explain each of these lines, describing in general terms what the system call is supposed to do and what the parameters and return value mean. (So, you will turn in a printout of the output of strace with your homework. You can mark it up with numbers and then refer to these numbers in your explanation.)

   The man page for strace explains the general format of the output. To find out what the individual system calls do, you will need to read their man pages. Some of these are easy to find -- e.g., the first call is usually to execve, and man execve will tell you about it. Some are a little harder to track down -- e.g., man open produces information about an open command rather than a system call. man -k open produces a list of all man pages whose one-line descriptions include ``open'', and from this list one can perhaps guess that to look at the desired man page you need the command man 2 open. If the system call reported by strace ends in 64 (e.g., fstat64), the right man page can be found by removing ``64'' from the name (e.g., man fstat).

2. (5 points) Does a timesharing system need a process table? Why or why not? What about a personal-computer system in which only one process at a time can execute, that process taking over the whole machine until it is finished? Why or why not?

3. (5 points) Consider a computer that does not have a test-and-set-lock (TSL) instruction, but does have an instruction to swap the contents of a register and a memory word in a single indivisible action. Use such an instruction (call it SWAP) to write a routine enter_region like the one found in Figure 2-22 in the textbook, or explain why this is impossible.

4. (5 points) Consider the procedure put_forks in Figure 2-33 in the textbook. Suppose that the variable state[i] was set to THINKING after the two calls to test rather than before. How would this change affect the solution? (I.e., would it work as well as before? better? not as well?)

Programming Problems

Do the following programming problems. You will end up with at least one code file per problem. Turn in your code by sending mail to cs4320@cs.trinity.edu, with each of your code files as an attachment. If there's any question of which file(s) correspond to which problems, explain in the body of the mail message. Please use a subject line such as ``homework 2'' or ``hw2''. You can develop your programs on any system that provides the needed functionality, but I will test them on one of the department's RedHat 9 Linux machines, so you should probably make sure they work in that environment before turning them in.

1. (10 points) Figure 1-19 in chapter 1 of the textbook presents pseudocode for a simple command shell. Your mission for this problem is to turn this into a C or C++ program that runs on a Linux system. Your program should prompt the user for a command and command-line arguments (the prompt can be something simple, such as ``?'') and then run the given command with the given arguments. You can require that the user give the full path for the command, and you do not have to do sophisticated parsing of the command-line arguments (such as wildcard expansion, recognition of environment variables, etc., etc.). Here is a sample execution, terminated by control-C.

   [bmassing@Athena]$ ./simple-shell 
   ? ls
   Unable to find command
   ? /bin/ls
   Makefile  another  simple-shell  simple-shell.cpp  somefile
   ? /bin/ls -l
   total 28
   -rw-------    1 bmassing bmassing      119 Oct  3 08:02 Makefile
   -rw-------    1 bmassing bmassing        5 Oct  3 08:00 another
   -rwx------    1 bmassing bmassing    22035 Oct  3 08:15 simple-shell
   -rw-------    1 bmassing bmassing     1407 Oct  3 08:15 simple-shell.cpp
   -rw-------    1 bmassing bmassing        5 Oct  3 08:00 somefile
   ? /bin/ls junk
   /bin/ls: junk: No such file or directory
   ? 
   [bmassing@Athena]$
   

   You can add more functionality (searching a path for the command, doing more sophisticated parsing of inputs, exiting when the user types ``exit'', etc.). If you do, describe the added functionality in comments at the top of your code. I will give up to 5 extra points for significant extra features.

   Turning the pseudocode into code mostly involves defining appropriate data structures for the variables in the pseudocode and replacing the type_prompt and read_command functions with appropriate real code. Your first step should probably be to read the man page for execve to see what arguments it expects, and then figure out what you need to do to turn what the user types in into suitable input to execve.

   You will probably find that most of the code you write for this problem will be code to parse the input (accept a line of text and break it into a command and arguments). You can do this using C functions such as scanf, with the C++ string class, or whatever you prefer. If you use the C functions and fixed-size character arrays, try to make the program fail gracefully if the user supplies more input than your code has room to accept.

2. (10 points) The starting point for this problem is a simple C++/threads implementation threads-cr.cpp of the mutual-exclusion problem. Currently no attempt is made to ensure that only one thread at a time is in its critical region, and if you run it you will see that in fact it frequently happens that all the threads are in their critical region at the same time. Your mission is to correct this. You have two options:
   • Use the ``mutex'' library functions, which provide simple locking/unlocking. man pthread_mutex_init will tell you about these functions.

   • Write your own implementation of semaphores using the mutex library functions for locking, and then use this implementation to fix the mutual-exclusion program using (your) semaphores. This option is worth up to 5 extra points.

   Start by compiling the program and observing its behavior with different numbers of threads. To compile with g++, you will need the extra flag -pthread, e.g.

   g++ -o threads-cr -pthread threads-cr.cpp

   (On the RedHat 9 machines, this command produces a lengthy warning about one of the #included files. This message appears to be harmless. An updated version of the program that doesn't produce the message can be found in new-threads-cr.cpp. It produces other warnings on older systems.) Interestingly enough, the exact behavior of this program seems to depend both on the number of processors and on the release of the operating systems -- try it on one of the lab machines and then on one of the Dwarf machines to see what I mean. You may need to recompile when switching to a machine running a different release of the operating system.

   Then make your changes and confirm that the program now behaves as expected, i.e., when one thread starts its critical region no other thread can start its critical region until the first one finishes.