This is a an exam. You may consult your notes, any book, and the Internet. You may not speak with any person other than Jeff Ondich, electronically or otherwise, about the content of this exam. If you obtain relevant information from any source other than yourself, cite your sources clearly. Justify your answers. (Note that "justify your answers" implies "show your work.") Have fun.
Threads (10 points)
The sample program threads.c illustrates the use of POSIX threads, also known as pthreads. This particular sample uses pthread mutex variables (binary semaphores) to force strict alternation between two threads. Note that sharing memory between pthreads via global variables is considerably simpler than doing so using shmget and its pals.
Take a look at another sample program that consists of kbcolors.c, kbhit.c, and kbhit.h. If you compile this program with "gcc -Wall -o kbcolors kbcolors.c kbhit.c -lpthread", you'll end up with a program that prints a color name every second or two. If you type a letter (r for red, b for blue, g for green, y for yellow, o for orange, or q for quit), the message changes to the new color (or the program quits if you type q). Note that the kbhit() and readch() functions are designed to enable your program to obtain keyboard input without requiring the user to hit the Enter key. If you wish to study kbhit.c, you may, but I won't be asking you to understand how it works--just how to use it.
With these programs in hand, your job is to write a two-threaded program. One thread, which would typically be characterized as a "worker thread," should generate prime numbers until it's time to quit. The other thread should keep an eye on the keyboard, and as soon as the user types a q, shut down the program, including both threads and the parent process.
This separation between computation and user communication makes both threads simpler, and thus easier to write, understand, and maintain.
Call your program threads.c and submit it in the usual way. You don't need to submit copies of kbhit.h and kbhit.c.
Memory (14 points)
Suppose a 32-bit OS uses a paged virtual memory system with page size 32KB. Suppose the paging is managed by a two-level page table system whose top-level table has 512 entries. Suppose further that each page table entry (top-level or second-level) consists of 32 bits, and that the top-level page table is loaded into physical memory at the time the program is launched.
Consider the strange little program addressreport.c. This program includes local variables, string literals, dynamic memory allocation via malloc, and a recursive function whose stack frames are made artificially large by a big fat array of characters. The purpose of the program is to give you an idea of where in virtual memory all of these sorts of objects are placed by the compiler and run-time system on whatever computer you use to test the program. For this exercise, study, compile, and run the program on a Unix-based system (e.g. Linux or Mac), and then:
Easy points (3 points)
Please tell me a joke.
Files (12 points)
On a Unix system, create a file called aaa. Then create a hard link bbb to aaa (using the command "ln aaa bbb"), create a soft link ccc to aaa ("ln -s aaa ccc"), and finally delete aaa ("rm aaa"). Then:
Based on the description of the Unix V7 i-node as described on page 322 of Tanenbaum, what is the maximum file size? Explain your answer.
Deadlock (12 points)
Do problem 18 on p.464 of Tanenbaum.
Do problem 22 on p.464 of Tanenbaum.
Therac-25: something you should know about (10 points)
The Therac-25 incident is arguably the worst disaster in the history of software. You can learn all about it in An Investigation of the Therac-25 Accidents, Nancy Leveson and Clark S. Turner, IEEE Computer, Vol. 26, No. 7, July 1993, pp. 18-41. (Here's another link to the same paper.) If you wish, you may also look for other information on Therac-25 in books or on the Web.