CS 644 hw2 Operating Systems: from above Due midnight Sunday, Mar 7, 25 pts. To get started. 1. In the Comer book, please correct all instances of "create(x,200,...)" to "create(x,1000,...)" The second argument is the stack size and 200 bytes is way too small for a 32-bit machine (the PDP-11 was a 16-bit machine.) If you use 200, your process stacks will overlap and cause all sorts of mysterious behavior! 2. Build the semex program in ./semex/* and try it out on ulab and sf06. Study it and make the mutex work, so the output strings don't get mixed together. This program is based on example programs from Robbins and Robbins, "UNIX Systems Programming", Prentice Hall, 2003--a good book for UNIX and POSIX programming. Please use ulab for any Solaris multiprocess/thread programs-- especially if you use shared memory or named semaphores. They are persistent, i.e., don't go away automatically when you exit a program, so they can cause problems beyond your own environment. Be sure to run "ipcs" to see if you've accidentally left any shared memory or semaphore objects around and delete them with "ipcrm -m or "ipcrm -s " if necessary. (This is unnecessary if you stick with unnamed semaphores, used in semex.) 3. Also be aware of processes you make on UNIX once you start writing the multiprocess programs. Use "ps -x" and "kill " as necessary to clean them up. 4. When using the SAPCs, please use "musers" to check that noone is using more than 2 mtip processes. You can use "mkill" to kill off the older processes of any such users. Let me know of any problems you see in using the SAPCs. Assignment 1. Design a portable lock service: --same calling interface (API) on UNIX/Linux and Xinu, but necessarily different implementations --UNIX means Solaris (our UNIX hosts ulab, eris, etc.) If you have access to another UNIX platform, try it there too. --the service can provide a lock for one group of cooperating processes, then another lock for another group, or a second lock for the first group, but is not required to define an array of locks all at one time. Put the design doc in lock.txt. a. the external specification: API, what each call does as a service Turn this part into lock.h, with the descriptions of what each call does turned into comments. b. the internal specification: how it works. Write this in full sentences with names of relevant system calls as needed. 2. Use the services of 1. to write test programs that use as few #ifdef XINUs as possible, i.e., as portable as possible. Process creation is expected to be platform-specific. test1.c: main creates a lock, then two processes, A and B, which both execute function "worker", but with different arguments as needed to output differently. A locks the lock, prints an A, sleeps a sec, prints another A, unlocks, and B similarly with B's. This only tests a single lock however. Note that output buffering can make it difficult to see what is going on--you need to arrange to force the output out. It is usually sufficient to output a newline. test2.c: uses two pairs of worker processes, with A and B using one lock as in test1, C and D using another. Have A and B output "A\n" and "B\n", while C and D output " C\n" and " D\n", so we can see A vs. B in column 1 of the output, C vs. D in column 2. 4. Implement the services in lock.c. Use #ifdef XINU #else #endif to handle the platform dependence. Provide a Makefile to build UNIX and Xinu versions, for test program U, starting from the Makefile in $xuex. Put your lock service modules in the ld sequences. Late Work Each student has 5 late days "in the bank" to use in any pattern for the programming assignments of this course. To use late days, just put a README in your hwX directory stating when you expect to be done, and then, later, that you are done. The doneness day is determined by the most recent file written other than README itself. Below are the files you are expected to submit. Make a subdirectory named 'hw2' under your ~/cs644 directory for this work. lock.txt: section 1: external specification section 2: internals documentation test1.c: user program to test 1 lock as described above test2.c: your user program to test 2 locks lock.h: public interface to your lock package, platform independent lock.c: implementation of your lock package, using #ifdef XINU #else to get the right code compiled. Makefile: makefile that supports "make U=test1 test1.lnx", "make U=test2 test2.lnx" "make U=test1 test1" "make U=test2 test2" to make the 4 versions, and "make clean". These files will be collected automatically by a script so it is important these filenames are used. Any special instructions or notes should be documented in a file called "README" in your project directory. The collection script will automatically collect this file if it exists.