DOC PREVIEW
UB CSE 421 - Project 2 - Multi-programming

This preview shows page 1 out of 3 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 3 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

Project 2: Multi-programmingIntroduction to Operating Systems CSE421Assigned: 2/28/2003 Due: 3/28/2003,11.59PMIn the second project you will design and implement appropriate support for multiprogramming. Youwill extend the system calls to handle process management and inter-process communication primitives.You will add this to the coded first project. Make sure you correct all the deficiencies in your firstproject before starting the second project. This solution for project1 will be covered as part of nextweek’s recitation.Nachos is currently a uniprogramming environment. We will have to alter Nachos so that each process ismaintained in its own system thread. We will have to take care of memory allocation and de-allocation.We will also consider all the data and synchronization dependencies between threads. You will firstdesign the solution before coding. Here are the details:1. Alter your general exceptions (non-system call exceptions) to finish the thread instead ofhalting the system. This will be important, as a run time exception should not cause theoperating system to shut down. You will most likely have to revisit this code several timesbefore your project is complete. There are several synchronization issues you will have tohandle during thread exit.2. Implement multiprogramming. The code we have given you is restricted to running one userprogram at a time. You will need to make some changes to addrspace.h, and addrspace.cc inorder to convert the system from uniprogramming to multiprogramming. You will need to:a. Come up with a way of allocating physical memory frames so that multiple programs can beloaded into memory at once.b. Provide a way of copying data to/from the kernel from/to the user’s virtual address space.c. Properly handling freeing address space when a user program finishes.d. It is very important to alter the user program loader algorithm such that it handles frames ofinformation. Currently, memory space allocation assumes that a process is loaded into acontiguous section of memory. Once multiprogramming is active, memory will no longerappear contiguous in nature. If you do not correct the routine, it is most likely that loadinganother user program will corrupt the operating system. 3. Implement the SpaceID Exec(char *name) system call. Exec starts a new user programrunning within a new system thread. You will need to examine the “StartProcess” function inprogtest.cc in order to figure out how to set up user space inside a system thread. Exec shouldreturn –1 on failure, else it should return the “Process SpaceID” of the user level program itjust created. (Note: SpaceIDs can be kept track of in a similar manner to OpenFileIDs of yourproject 1, except that you will want to keep track of them outside the thread.)4. Implement the int Join(SpaceID id) and void Exit(int exitCode) system calls. Join will waitand block on a “Process SpaceID” as noted in its parameter. Exit returns an exit code towhomever is doing a join. The exit code is 0 if a program successfully completes, anothervalue if there is an error. The exit code parameter is set via the exitcode parameter. Joinreturns the exit code for the process it is blocking on, -1 if the join fails. A user program canonly join to processes that are directly created by the Exec system call. You can not join toother processes or to yourself. You will have to use semaphores inside your system calls tocoordinate Joining and Exiting user processes. You will observe that this can be modeled assleeping barber IPC (inter process communication).5. Implement the int CreateSemaphore(char *name, int semval) system call. From the execvsystem call that you implemented in Project1 you would have realized that we will have toupdate start.s and syscall.h to add the new system call signatures. You will create a containerat the system level that can hold upto 10 named semaphores (this is very much similar to ourmailboxes from Project1). The CreateSemaphore system call will return 0 on success and –1on failure. The CreateSemaphore system call will fail if there are not enough free spots in thecontainer, the name is null, or the initial semaphore value is less than 0.6. Implement int wait(char *name) and int signal(char *name) system calls. Make sure youfollow the wait and signal as the mnemonics for these two and not down and up or Pand V. The name parameter is the name of the semaphore. Both system calls return 0 onsuccess and –1 on failure. Failure can occur if the user gives an illegal semaphore name (onethat has not been created).7. Implement a simple shell program to test your new system calls implemented as above. Theshell should take a command at a time, and run the appropriate user program. The shellshould “Join” on each program “Exec”ed, waiting for the program to exit. On return from theJoin, print the exit code if it is anything other than 0 (normal execution). Also, design theshell such that it can run program in the background. Any command starting with character(&) should run in the background. (Ex: &create will run the test program create program inthe background.)8. Create a user level solution to the producer/consumer problem. The solution should consist ofthree programs: a main level start program, producers and consumers. The main level startprogram should minimally prompt the user for the number of producers to “exec” and thenumber of consumers to “exec” as well as an iteration count for the producers and consumersand the size of the bounded buffer. The main start program will then Exec the producers andthe consumers and wait until all the processes are complete. Each producer should produce aunique character payload (ex: Producer 1 produces “a” and producer 2 produces “b” etc.).Producers and consumers should print their iterations in a clear and concise format. Note thatexec does not allow command line arguments. You may use mailbox from project1 as theshared buffer to take care of this problem.9. Design two user programs other than the items 7, and 8 above that can be run inside the shellto demonstrate the robustness of your overall project solution.10. Documentation (10%) Includes internal documentation, and external documentation asdescribed in Project1. Create a READE file and place it the code directory. Tar your codeand submit it as one file. Follow the directions given in Project1. We plan to run automaticplagiarism detection


View Full Document

UB CSE 421 - Project 2 - Multi-programming

Documents in this Course
Security

Security

28 pages

Threads

Threads

24 pages

Security

Security

20 pages

Security

Security

52 pages

Security

Security

20 pages

Load more
Download Project 2 - Multi-programming
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Project 2 - Multi-programming and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Project 2 - Multi-programming 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?