COMP 3000 Lab 3 2010 Soln

Part A (Mandatory)

Processes and Threads

1. The program threads.c is a multithreaded producer/consumer program. Unfortunately it consumes faster than it produces, resulting in an error. Why does it not print the same number every time?
   
   A: This has to do with the fact that we have two processes running on a system without any sort of locking mechanism. This results in a race condition. If both processes ran for exactly the same amount every time you ran them, then the race condition would always appear at the same value. Unfortunately, this is not the case. There are a number of factors in a modern system which can affect the running time of a process. They include:
   (a) Other processes on the system
   (b) Hardware (which interrupts the CPU to get serviced)
   (c) The CPU, memory, cache
   Because of this, the scheduling of the two processes may look more like the diagram below, where the read lines indicate the servicing of an interrupt request. In order to always stop at the same number every time, each interrupt service would have to take exactly the same amount of time, and the processes would never be allowed to have their running time shortened or lengthened by even a few clock cycles. Being strict on execution time down to the clock cycle is not feasible on modern systems.
   
   
2. The program passstr.c is a multithreaded program using the clone function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?
   
   A: The program is blocking by busy waiting on the first character in the string. Busy waiting is bad because it ties up system resources needlessly. Furthermore, it is looking at the first character in the string, which means if a process switch happened after the first character was written but before the rest of the string was written, then only the first part of the string would be displayed on the string (since the consumer would read the string before it was all completely there).

Fork & Exec

1. What is the difference between the clone and the fork function call?
   
   A: The Clone function call is a much more powerful version of the fork system call. In fact, the functionality of the fork function call can be implemented with the clone function call. The clone function call, however, contains additional options which make it possible to create threads. The threads have the option of sharing file handles, memory spaces and other kernel resources.

IPC

Examine the program given in wait-signal.c. It multiplies two matrices together using the standard trivial algorithm (which also happens to be a n3 algorithm). It spawns off a child process to compute the value of each element in the resulting matrix. The program has a problem, however, in that it fails to pass the resulting values back to the parent process in order to give the right result. In this section, we will examine various methods for passing data between processes.

1. Signals
   Signals can be sent to each process running on the system. Signals, however, don’t allow the passing of any data along with the signal. Therefore, they are most useful for triggering actions.
   
   1. The kill command actually sends signals to processes. What signal does the kill command by default send to a process?
      
      A: The signal SIGTERM signal is normally sent unless a different signal is specified on the command line.
      
      
   2. Modify the wait-signal-1.c file to use the signal function to install the signal handler instead of the sigaction function call. You can have it install the child handler alt signal handler instead of the child handler signal handler. What line did you add to install the signal handler to child handler alt?
      
      A: signal( SIGCHLD, child handler alt );
      
      
   3. Modify the wait-signal.c file to ignore the abort signal. What line did you have to add to do this?
      
      A: signal( SIGABRT, SIG IGN );
      
      
2. Pipes
   Pipes (also called FIFO’s) allow two processes to communicate through a file handle. One process writes data into a file handle and the other process can then read that data out through a related but different file handle.
   1. What happens to file descriptors across an exec call? Write a small program that tests this behavior, i.e. that opens a file, calls execve, and then the new program attempts to read from the previously opened file descriptor. Explain how this program behaves.
      
      A: Below is the source for a “parent” and “child” execve programs (note there is only one process used by these programs!). The exec parent program opens the file foo and then passes the file descriptor number to exec child via its argument list. exec child reads up to the first 512 bytes of this file and writes them to standard out (fd 1). Note the file descriptor remains open (and if the fd is closed before the exec then the child fails).
      
      /* exec-parent.c */
      #include <stdio.h>
      #include <unistd.h>
      #include <fcntl.h>
      int main(int argc, char *argv[], char *envp[])
      {
      int fd;
      char *child_argv[2];
      char fd_string[10];
      fd = open("foo", O_RDONLY);
      /* close(fd); */ /* Enable this to see exec_child fail! */
      snprintf(fd_string, 10, "%d", fd);
      child_argv[0] = fd_string;
      child_argv[1] = NULL;
      execve("./exec-child", child_argv, envp);
      fprintf(stderr, "Exec failed!\n");
      return(-1);
      }
      
      /* exec-child.c */
      #include <stdio.h>
      #include <stdlib.h>
      int main(int argc, char *argv[], char *envp[])
      {
      char buf[512];
      int count,fd;
      fd = atoi(argv[0]);
      printf("FD = %d\n", fd);
      count = read(fd, buf, 512);
      if (count > 0) {
      printf("First %d bytes of foo:\n", count);
      write(1, buf, count);
      } else {
      printf("Read of foo failed!\n");
      }
      printf("Done!\n");
      return(0);
      }
      
      
   2. Compile and run pipe.c. Notice how data is sent through the pipe by writing to one end of the pipe in the child and reading from the other end of the pipe in the parent. Also notice how the message Finished writing the data! is never displayed on the screen. The problem has to do with the SIGPIPE signal. What is the problem?
      
      A: When the parent closes the pipe, the child is sent a SIGPIPE signal when it tries to write to the pipe and the default action for a SIGPIPE signal is to terminate the program, hence the printf never runs. The program had another bug in that there was a while(1) loop which would have run forever had the process not been killed by the SIGPIPE signal. The while(1) loop, however, does not explain why the child died at all and the fact that the child exited at all should have been an obvious clue as to what was happening.
      
      
3. Shared Memory
   1. Shared memory regions are controlled by the kernel to prevent other processes from accessing the memory without permission. Like files in Unix, the shared memory regions are given read, write and execute permission. These permissions are specified in the call to shmget. Where in the arguments to shmget are the permissions specified?
      
      A: The lower 9 bits of the shmflg value.
      
      
   2. The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.
      
      A:
      • Read,Write and Execute for the Owner
      • Read andWrite for the Group
      • No permissions for everyone else
      
      
   3. What number is going to be required in order for two processes owned by the same user to be able to read and write to the shared memory?
      
      A: 0600 Any additional bits set represent a potential security issue in that additional processes not owned by the user may be able to interfere with the shared memory. The execute permission is not required in this question.
      
      

Part B (Optional)

The following exercises are optional.

Processes

1. From class, you know that the process descriptor contains numerous information about a running process on the system. The task structure in Linux is called struct task struct. By examining the source of the Linux kernel, determine what source file this structure is defined in. The grep command may be useful in locating the correct file.
   
   A: include/linux/sched.h
   
   
2. Figure 6.3 (page 213) in your textbook contains a list of common elements found in a process table. Determine at least one variable in the Linux task structure which is related to each element listed in Figure 6.3. You may omit address space and stack.

Internal process name	pid
State	state
Owner	uid, euid, suid, fsuid, gid, egid, sgid, fsgid
Execution Statistics	sleep avg, last ran, utime, stime, nvcsw, nivcsw
Thread	thread info
Related Processes	parent, real parent, group leader
Child Processes	children

Fork & Exec

1. Examining the flags that can be passed to the clone function call. Choose 5 flags and describe a situation in which each of them would be useful.
   Find the portion of the Linux kernel that implements the fork, clone, and vfork system calls for i386 systems. Based upon this code, could Linux instead just have one of these system calls?
   If so, which one, and how would you implement userspace “wrappers” that would provide identical functionality for the other two calls?
   If not, why are all three necessary? Explain.(For this question, ignore issues of binary compatibility.)
2. File descriptors 0, 1, and 2 are special in Linux, in that they refer to standard in, standard out, and standard error. Does the Linux kernel know they are special? Explain, referring to appropriate parts of the Linux kernel source.

IPC

In this section, you will be modifying the program wait-signal to correctly compute the value of the matrix multiplication.

1. Signals
   Describe in words how you might modify the wait-signal program to correctly pass back the value computed in the child to the parent using only signals. Remember that signals do not allow data to be passed back and forth. Also keep in mind that there are only around 32 signals that can be sent to a process. You do not have to implement your answer, only describe what you would do.
2. Pipes
   Modify the wait-signal.c program to pass the appropriate matrix data back to the parent via a pipe. Remember that you will also have to pass back the x and y locations that the data should be put in. What is your updated main function?
3. Shared Memory
   Modify wait-signal.c to send data back to the main process using shared memory. You will need to use the functions shmget and shmat.