COMP 3000 Lab 3 2010 Soln - Revision history

Praman: /* IPC */

2010-11-25T13:13:55Z

IPC

@@ Line 91: / Line 91: @@
 ===IPC===
 In this section, you will be modifying the program wait-signal to correctly compute the value of the matrix multiplication.
-# <b>Signals</b><br />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.
+# <b>Signals</b><br />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.<br /><br />A: There are a few ways of answering this:<br />• Count the number of signals received of a specific type and that is the value being passed back.<br />• As an improvement, use two signals, one which increments the placeholder and the other which flips (or increments) the value pointed to by the place- holder. This can be done for any base (but base 2 is most convenient).<br />• As an even better solution, use two signals, one represents a 0 bit being passed and the other represents a 1 bit. So, a sequence of SIGUSR1, SIGUSR1, SIGUSR2, SIGUSR1 may be translated as 1101.<br />
-# <b>Pipes</b><br />Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c 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?
+# <b>Pipes</b><br />Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c 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?<br />A: Changes to wait-signal.c:<br /><br />
-# <b>Shared Memory</b><br />Modify [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] to send data back to the main process using shared memory. You will need to use the functions shmget and shmat.

Praman: /* Fork & Exec */

2010-11-25T13:03:22Z

Fork & Exec

@@ Line 58: / Line 58: @@
 ===Fork & Exec===
-# 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.<br />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?<br /> If so, which one, and how would you implement userspace “wrappers” that would provide identical functionality for the other two calls?<br />If not, why are all three necessary? Explain.(For this question, ignore issues of binary compatibility.)
+# 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.<br /><br />A: Here are all the flags you could have listed:<br />• CLONE PARENT - Useful when one child wants to create another process but have it be a sibling instead of a child. In this way, a complex application can have a parent which takes care of administration and any of the children would be able to create additional processes that are also taken care of by the parent. If this flag did not exist, the child would have to ask the parent to create the new process.<br />• CLONE FS - chroot is often useful when you want to have processes only have access to a part of the file system. It restricts within the kernel what directories the program can access. If this flag is set, a server could be started with access to the entire file system and then after initialization access could be restricted to just those directories needed by the server during operation. As an example, a web server could be started and after it is running the parent could perform a chroot and the child would then be restricted to only the part of the file system containing files which should be displayed by the web server (there are security problems associated with open file handles when doing a chroot, but we do not discuss them here).<br />• CLONE FILES - If the child was to do work on a file handle, the parent (or dispatcher) could open files and then tell the child to operate on a specific file handle. Since file handles are simply integers, passing a file handle back and forth between processes only works if this option is enabled.<br />• CLONE NEWNS - Useful if you only wanted a new mounted drive to be accessible to certain processes. You could mount the drive in a new namespace and then all processes not in that name-space would not be able to access the mounted drive (since the drive would not be mounted in their name-space). It gives a way of protecting data on the drive when access permissions are not sufficient.<br />• CLONE SIGHAND - Allows a parent to catch signals that should be destined for the child process. This is especially useful when creating threads, where only one signal handler should be present for the group of threads (you don’t want different things happening depending on which thread generated the signal).<br />• CLONE PTRACE - Allows debugging of children created by a parent process which is also being debugged.<br />• CLONE VFORK - If a process wants to spawn off another program, it can use this option to block until the child has actually executed the new process. This prevents possible race conditions where the parent spawns off the child and then runs before the child has an opportunity to execute the replacement program.<br />• CLONE VM - Sharing memory space is one of the basic desired traits when creating threads. It allows two threads to operate on the same data (with appropriate locking mechanisms of course).<br />• CLONE PID - As it says, this is a hack. It allows creating a new process with the same PID so that when the parent exits, all other processes which refer to the process based on it’s pid will still be talking to the correct process.<br />• CLONE THREAD - This results in a thread which shares the PID of the process. It is useful in conjunction with the CLONE VM function to create multiple threads which all share the same process ID and memory space.<br />• CLONE SETTLS - Used by threading libraries. The description of this in the man page is not very clear.<br />• CLONE PARENT SETTID- Used by threading libraries, itmakes the kernel write information on the thread to a specific location in memory, which is useful for keeping track of the threads.<br />• CLONE CHILD SETTID - Used by threading libraries, it makes the kernel write information on the thread to a specific location in memory, which is useful for keeping track of the threads.<br />• CLONE CHILD CLEARTID - Used by threading libraries, it forces the kernel to write information to the thread data structure in the parent when the child exits.<br /><br />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?<br /> If so, which one, and how would you implement userspace “wrappers” that would provide identical functionality for the other two calls?<br />If not, why are all three necessary? Explain.(For this question, ignore issues of binary compatibility.)<br /><br />A: The key thing to note is that both sys clone() and sys fork() are implemented in terms of the same function, do fork(). To only expose one of these to userspace, you’d need to expose clone and implement the others it terms of it, because it is the system call that allows one to specify all of the arguments to do fork().<br />
 # 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===

Praman: /* Processes */

2010-11-25T12:45:40Z

Processes

@@ Line 31: / Line 31: @@
 ===Processes===
-#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.
+#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.<br /><br />A: include/linux/sched.h<br /><br />
 # 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.
 ===Fork & Exec===

Praman: /* IPC */

2010-11-25T12:36:30Z

IPC

← Older revision		Revision as of 12:36, 25 November 2010
Line 23:		Line 23:
	# <b>Shared Memory</b>		# <b>Shared Memory</b>
	## 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?<br /><br />A: The lower 9 bits of the shmflg value.<br /><br />		## 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?<br /><br />A: The lower 9 bits of the shmflg value.<br /><br />
	## The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.<br /><br />A:• Read,Write and Execute for the Owner<br />• Read andWrite for the Group<br />• No permissions for everyone else<br /><br />		## The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.<br /><br />A:<br />• Read,Write and Execute for the Owner<br />• Read andWrite for the Group<br />• No permissions for everyone else<br /><br />
	## 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?<br /><br />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.<br /><br />		## 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?<br /><br />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.<br /><br />

Praman: /* IPC */

2010-11-25T12:35:47Z

IPC

← Older revision		Revision as of 12:35, 25 November 2010
Line 20:		Line 20:
	# <b>Pipes</b><br />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.		# <b>Pipes</b><br />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.
	## What happens to file descriptors across an <tt>exec</tt> 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.<br /><br />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).<br /><br />/* exec-parent.c /<br />#include <stdio.h><br />#include <unistd.h><br />#include <fcntl.h><br />int main(int argc, char argv[], char envp[])<br />{<br />int fd;<br />char child_argv[2];<br />char fd_string[10];<br />fd = open("foo", O_RDONLY);<br />/* close(fd); / / Enable this to see exec_child fail! /<br />snprintf(fd_string, 10, "%d", fd);<br />child_argv[0] = fd_string;<br />child_argv[1] = NULL;<br />execve("./exec-child", child_argv, envp);<br />fprintf(stderr, "Exec failed!\n");<br />return(-1);<br />}<br /><br />/ exec-child.c /<br />#include <stdio.h><br />#include <stdlib.h><br />int main(int argc, char argv[], char *envp[])<br />{<br />char buf[512];<br />int count,fd;<br />fd = atoi(argv[0]);<br />printf("FD = %d\n", fd);<br />count = read(fd, buf, 512);<br />if (count > 0) {<br />printf("First %d bytes of foo:\n", count);<br />write(1, buf, count);<br />} else {<br />printf("Read of foo failed!\n");<br />}<br />printf("Done!\n");<br />return(0);<br />}<br /><br />		## What happens to file descriptors across an <tt>exec</tt> 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.<br /><br />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).<br /><br />/* exec-parent.c /<br />#include <stdio.h><br />#include <unistd.h><br />#include <fcntl.h><br />int main(int argc, char argv[], char envp[])<br />{<br />int fd;<br />char child_argv[2];<br />char fd_string[10];<br />fd = open("foo", O_RDONLY);<br />/* close(fd); / / Enable this to see exec_child fail! /<br />snprintf(fd_string, 10, "%d", fd);<br />child_argv[0] = fd_string;<br />child_argv[1] = NULL;<br />execve("./exec-child", child_argv, envp);<br />fprintf(stderr, "Exec failed!\n");<br />return(-1);<br />}<br /><br />/ exec-child.c /<br />#include <stdio.h><br />#include <stdlib.h><br />int main(int argc, char argv[], char *envp[])<br />{<br />char buf[512];<br />int count,fd;<br />fd = atoi(argv[0]);<br />printf("FD = %d\n", fd);<br />count = read(fd, buf, 512);<br />if (count > 0) {<br />printf("First %d bytes of foo:\n", count);<br />write(1, buf, count);<br />} else {<br />printf("Read of foo failed!\n");<br />}<br />printf("Done!\n");<br />return(0);<br />}<br /><br />
	## Compile and run [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/pipe.c 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?<br /><br />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		## Compile and run [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/pipe.c 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?<br /><br />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.<br /><br />
	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.<br /><br />
	# <b>Shared Memory</b>		# <b>Shared Memory</b>
	## 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?<br /><br />A: The lower 9 bits of the shmflg value.<br /><br />		## 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?<br /><br />A: The lower 9 bits of the shmflg value.<br /><br />

Praman: /* IPC */

2010-11-25T12:34:49Z

IPC

← Older revision		Revision as of 12:34, 25 November 2010
Line 19:		Line 19:
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />A: signal( SIGABRT, SIG IGN );<br /><br />		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />A: signal( SIGABRT, SIG IGN );<br /><br />
	# <b>Pipes</b><br />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.		# <b>Pipes</b><br />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.
	## What happens to file descriptors across an <tt>exec</tt> 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.<br /><br />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).<br /><br />/* exec-parent.c /<br />#include <stdio.h><br />#include <unistd.h><br />#include <fcntl.h><br />int main(int argc, char argv[], char envp[])<br />{<br />int fd;<br />char child_argv[2];<br />char fd_string[10];<br />fd = open("foo", O_RDONLY);<br />/* close(fd); / / Enable this to see exec_child fail! */<br />snprintf(fd_string, 10, "%d", fd);<br />child_argv[0] = fd_string;<br />child_argv[1] = NULL;<br />		## What happens to file descriptors across an <tt>exec</tt> 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.<br /><br />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).<br /><br />/* exec-parent.c /<br />#include <stdio.h><br />#include <unistd.h><br />#include <fcntl.h><br />int main(int argc, char argv[], char envp[])<br />{<br />int fd;<br />char child_argv[2];<br />char fd_string[10];<br />fd = open("foo", O_RDONLY);<br />/* close(fd); / / Enable this to see exec_child fail! /<br />snprintf(fd_string, 10, "%d", fd);<br />child_argv[0] = fd_string;<br />child_argv[1] = NULL;<br />execve("./exec-child", child_argv, envp);<br />fprintf(stderr, "Exec failed!\n");<br />return(-1);<br />}<br /><br />/ exec-child.c /<br />#include <stdio.h><br />#include <stdlib.h><br />int main(int argc, char argv[], char *envp[])<br />{<br />char buf[512];<br />int count,fd;<br />fd = atoi(argv[0]);<br />printf("FD = %d\n", fd);<br />count = read(fd, buf, 512);<br />if (count > 0) {<br />printf("First %d bytes of foo:\n", count);<br />write(1, buf, count);<br />} else {<br />printf("Read of foo failed!\n");<br />}<br />printf("Done!\n");<br />return(0);<br />}<br /><br />
	execve("./exec-child", child_argv, envp);<br />fprintf(stderr, "Exec failed!\n");<br />return(-1);<br />}<br />/* exec-child.c /<br />#include <stdio.h><br />#include <stdlib.h><br />int main(int argc, char argv[], char *envp[])<br />{<br />		## Compile and run [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/pipe.c 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?<br /><br />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
	char buf[512];<br />int count,fd;<br />fd = atoi(argv[0]);<br />printf("FD = %d\n", fd);<br />count = read(fd, buf, 512);<br />if (count > 0) {<br />printf("First %d bytes of foo:\n", count);<br />write(1, buf, count);<br />} else {<br />printf("Read of foo failed!\n");<br />}<br />printf("Done!\n");<br />return(0);<br />}<br /><br />		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.<br /><br />
	## Compile and run [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/pipe.c 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?<br /><br />
	# <b>Shared Memory</b>		# <b>Shared Memory</b>
	## 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?		## 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?<br /><br />A: The lower 9 bits of the shmflg value.<br /><br />
	## The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.		## The permissions must be specified as a value. By reading the manpage of chmod, determine what the permission 0760 means.<br /><br />A:• Read,Write and Execute for the Owner<br />• Read andWrite for the Group<br />• No permissions for everyone else<br /><br />
	## 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?		## 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?<br /><br />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.<br /><br />

	==Part B (Optional)==		==Part B (Optional)==

Praman: /* IPC */

2010-11-25T12:29:50Z

IPC

← Older revision		Revision as of 12:29, 25 November 2010
Line 15:		Line 15:

	# <b>Signals</b><br />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.<br />		# <b>Signals</b><br />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.<br />
	## The <tt>kill</tt> command actually sends signals to processes. What signal does the kill command by default send to a process?		## The <tt>kill</tt> command actually sends signals to processes. What signal does the kill command by default send to a process?<br /><br />A: The signal SIGTERM signal is normally sent unless a different signal is specified on the command line.<br /><br />
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.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?		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal-1.c 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?<br /><br />A: signal( SIGCHLD, child handler alt );<br /><br />
	## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal-1.c wait-signal-1.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />		## Modify the [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/wait-signal.c wait-signal.c] file to ignore the abort signal. What line did you have to add to do this?<br /><br />A: signal( SIGABRT, SIG IGN );<br /><br />
	~~Note~~: ~~The file names may have been switched. Try using the wait-signal1.c for part 2 and wait-~~signal~~.c for part 3 - --[[User:AbsMechanik\|AbsMechanik]] 15:11~~, ~~5 October 2010 (UTC~~)
	# <b>Pipes</b><br />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.		# <b>Pipes</b><br />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.
	## What happens to file descriptors across an <tt>exec</tt> 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.		## What happens to file descriptors across an <tt>exec</tt> 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.<br /><br />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).<br /><br />/* exec-parent.c /<br />#include <stdio.h><br />#include <unistd.h><br />#include <fcntl.h><br />int main(int argc, char argv[], char envp[])<br />{<br />int fd;<br />char child_argv[2];<br />char fd_string[10];<br />fd = open("foo", O_RDONLY);<br />/* close(fd); / / Enable this to see exec_child fail! */<br />snprintf(fd_string, 10, "%d", fd);<br />child_argv[0] = fd_string;<br />child_argv[1] = NULL;<br />
			execve("./exec-child", child_argv, envp);<br />fprintf(stderr, "Exec failed!\n");<br />return(-1);<br />}<br />/* exec-child.c /<br />#include <stdio.h><br />#include <stdlib.h><br />int main(int argc, char argv[], char *envp[])<br />{<br />
			char buf[512];<br />int count,fd;<br />fd = atoi(argv[0]);<br />printf("FD = %d\n", fd);<br />count = read(fd, buf, 512);<br />if (count > 0) {<br />printf("First %d bytes of foo:\n", count);<br />write(1, buf, count);<br />} else {<br />printf("Read of foo failed!\n");<br />}<br />printf("Done!\n");<br />return(0);<br />}<br /><br />
	## Compile and run [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/pipe.c 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?<br /><br />		## Compile and run [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/pipe.c 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?<br /><br />
	# <b>Shared Memory</b>		# <b>Shared Memory</b>

Praman: /* Fork & Exec */

2010-11-25T12:19:21Z

Fork & Exec

← Older revision		Revision as of 12:19, 25 November 2010
Line 8:		Line 8:
	===Fork & Exec===		===Fork & Exec===

	# What is the difference between the <tt>clone</tt> and the <tt>fork</tt> function call?		# What is the difference between the <tt>clone</tt> and the <tt>fork</tt> function call?<br /><br />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===		===IPC===

Praman: /* Processes and Threads */

2010-11-25T12:17:59Z

Processes and Threads

← Older revision		Revision as of 12:17, 25 November 2010
Line 3:		Line 3:
	===Processes and Threads===		===Processes and Threads===

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c 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?<br /><br />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:		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c 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?<br /><br />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:<br />(a) Other processes on the system<br />(b) Hardware (which interrupts the CPU to get serviced)<br />(c) The CPU, memory, cache<br />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.<br /><br />
	(a) Other processes on the system		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?<br /><br />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).
	(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.

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?<br /><br />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===		===Fork & Exec===

Praman: /* Processes and Threads */

2010-11-25T12:14:05Z

Processes and Threads

← Older revision		Revision as of 12:14, 25 November 2010
Line 3:		Line 3:
	===Processes and Threads===		===Processes and Threads===

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c 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?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/threads.c 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?<br /><br />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: 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		(a) Other processes on the system
	(b) Hardware (which interrupts the CPU to get serviced)		(b) Hardware (which interrupts the CPU to get serviced)
Line 11:		Line 9:
	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.		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.

	# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?		# The program [http://homeostasis.scs.carleton.ca/~soma/os-2010f/lab3/passstr.c passstr.c] is a multithreaded program using the <tt>clone</tt> function call. What is wrong with the way this program blocks, waiting for the string to arrive in the buffer?<br /><br />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===		===Fork & Exec===