Department of Computer Science. COS 122 Operating Systems. Practical 3. Due: 22:00 PM

Transcription

1 Department of Computer Science COS 122 Operating Systems Practical 3 Due: 22:00 PM August 30, 2018

2 PLAGIARISM POLICY UNIVERSITY OF PRETORIA The Department of Computer Science considers plagiarism as a serious offence. Disciplinary action will be taken against students who commit plagiarism. Plagiarism includes copying someone else s work without consent, copying a friend s work (even with consent) and copying material (such as text or program code) from the Internet. Copying will not be tolerated in this course. For a formal definition of plagiarism, the student is referred to ais.up.ac.za/plagiarism/index.htm (from the main page of the University of Pretoria site, follow the Library quick link, and then click the Plagiarism link). If you have any form of question regarding this, please ask one of the lecturers, to avoid any misunderstanding. Also note that the OOP principle of code re-use does not mean that you should copy and adapt code to suit your solution.

3 Instructions In this module it is advised that you have a Virtual Machine(VM) to do all your practicals due to the nature of this course it is easy to mistakenly destroy your Operating System. For all practicals you must make use of a Linux VM. Follow the Upload and Demo instructions carefully at the end of the practical. All written answers must be in pdf format as no other formats will be marked. Only upload your source code, makefile, and supporting documents. Do not upload large, binary, or OS files. Keep your uploaded archive small. Upload your work in a zip or tar.gz file before 22:00 on the 13rd of September Bring your VM on a flash disk to your booked practical demonstration session in the week starting on the 17th of September, so you may be marked. On non-demo days, there will still be teaching assistants available in the labs to help you. Make use of a Makefile for your programs. You makefile must have these commands: # make # make run 2

4 Scenario One day you come home very chuffed with yourself because you have just bought a printer that allows you to print anything remotely. This printer also allows a number of users to combine parts of a file together to successfully print the full file. To test it out you find some ASCII art that you would like to print using your special printer. You decide to test out the feature that allows multiple users to combine a file together. This is achieved by having a client-server model set up where the server will (when requested) send a certain piece of the ASCII art to the requesting client. The Server Class The Server class is simply there to emulate a server in the client-server model/architecture and includes the following functions: Server(string filename, int threads) - This is the constructor and will read in a file specified by filename and split the content of the file into threads number of pieces and store it in an array called ascii. Keep in mind that the indexes start from 0 and not 1. Server - The destructor which deletes the dynamically allocated ascii array. getpiece(int piece) - A method which returns the piece (a string) from the ascii array specified by piece. Task 1 - Deadlock [9 Marks] This is NOT a Fitchfork task. In this task you are required to implement a number of functions in the file deadlock.cpp. This file can be downloaded from the CS website. The implementation of these functions should provide you with two deadlock situations. You will need to use threads when implementing these functions. You may use high level C++ threads OR pthreads for this purpose. You will also need to use some locking mechanism to achieve mutual exclusion between threads. The methods you need to implement are as follows: 1. printtoscreen(string toscreen) - Implement this function to deal with the race condition on stdout (i.e. printing to the screen). If multiple threads try and output to the screen concurrently, much of the text being output will collide with each other and create a line, or multiple lines, of difficult to interpret text. This is what is meant by the race condition on stdout. 2. output(string toprint) - This function writes the string toprint to a file called deadlock.txt. Before opening the file you will need to output, to the screen, the string Opening... and before writing to the file output, to the screen, the string Writing.... 3

5 3. spin(int index) - Since the printer needs the pieces of the ASCII file in the order they need to be put on the page; this function needs to ensure that a thread only sends their piece to the printer in the correct sequence (specified by the threads indexes). Thus each thread will need to wait/spin until the piece of ASCII art that they have requested from the server is to be printed. Once a thread is able to send their piece to the printer you will need to gain lock access to do so. E.g: 3 threads are being used, so thread 0 has piece 0, thread 1 has piece 1 and thread 2 has piece 2. Thread 0 Thread 1 Thread 2 Calls spin but doesn t Calls spin and waits Calls spin and waits wait Gains lock access and Still waiting Still waiting outputs to deadlock.txt Releases lock access Gains lock access and Still waiting outputs to deadlock.txt Join Released lock access Gains lock access and outputs to deadlock.txt Join Released lock access Join 4. lock(int choice) - Use any type of locking mechanism of your choice. You may use a library for this or you may implement your own locking mechanism. Allow for locking either access to the server (choice == 1) or access to the printer (choice == 2). 5. unlock(int choice) - Use any type of unlocking mechanism of your choice. You may use a library for this or you may implement your own unlocking mechanism. Allow for unlocking either access to the server (choice == 1) or access to the printer (choice == 2). 6. main(...) - You should allow for 2 command line arguments: (a) The filename where the ASCII art is stored. (b) The number of threads to use. You will need to create the number of threads specified by the second argument. Based on their index (not the thread ID) you will need to call separate functions: eventhread(int index) for an even indexed thread and oddthread(int index) for an odd indexed thread. The indexes must start at 0, not 1. Before creating each thread, sleep for a random time between 0 and 4 seconds (this will allow both deadlock scenarios to occur on different executions). Please Note: You may not edit the eventhread and oddthread functions. 4

6 Every time you execute the program the contents of the deadlock.txt file must be overwritten. The two deadlock situations that can occur are shown in the output below (please ensure that your output looks similar): (b) Deadlock scenario 2 (a) Deadlock scenario 1 Task 2 [10 Marks - 6 FF, 4 in session] This IS a Fitchfork task but your code will also be checked in your marking session. The aim of this task is to remove the deadlock from the code implemented in Task 1. You will implement this in the file mutex.cpp which can be downloaded from the CS website. You may reuse your code in the implementation of the functions from the above task. Make sure your deadlock is gone before submitting this task, since deadlocked programs will not return feedback and many such uploads can cause the server to slow down. You have to submit this task to Fitchfork and the final upload slot. Fitchfork upload slots will open on Tuesday 4 Aug at 00:00 (midnight). Things to note before completing this task: 1. Please note that there is an added line to the eventhread and oddthread functions (in the catch). Do not remove any lines from these functions or you will be penalised. Hint: you may add lines to or move lines around within these functions. 2. The lines stated above throw a new exception after catching the 500 Internal Server Error. You are required to handle this newly thrown exception and unlock successfully to avoid the newly resulting deadlock. Don t forget that after handling this exception the thread still needs to send its piece of the ASCII art to the printer so that the art can be written to the file. Please note that this new exception may 5

7 be thrown multiple times during the same execution but will not happen every time you run your file (due to the probability of throwing the 500 Internal Server Error). 3. The file that you will need to write data to should be called mutex.txt. Your output should look similar to the following: (b) Mutex File Output (printer) (a) mutex.cpp Screen Output Task 3 [14 Marks - 9 FF, 5 in session] This IS a Fitchfork task but your code will also be checked in your marking session. In this task you will be implementing the functions in the msgpass.cpp file which you can download from the CS website. You may reuse your code in the implementation of the functions from the above task. Make sure your deadlock is gone before submitting this task, since deadlocked programs will not return feedback and many such uploads can cause the server to slow down. You have to submit this task to Fitchfork and the final upload slot. Fitchfork upload slots will open on Tuesday 4 Aug at 00:00 (midnight). This task still has the same scenario where each client can send their piece to the printer, however this time you decide to use a message queue to emulate message passing between the clients/threads. The idea is that after each client/thread has requested the 6

8 piece from the server, that piece, along with the client/thread index, will be sent (in this case by pushing them onto the message queue) to a single client/thread who is acting as a mediator for the print job. Once all pieces have been pushed onto the queue, the mediator client/thread will receive (in this case by popping the pieces off the message queue individually) all the messages and send them to the printer in reverse order. The Message struct This struct has been given to you in the msgpass.cpp file. The elements are as follows: 1. string payload - This is a string that will contain the piece of the ASCII art to print. 2. uint t ind - This is the thread index of the thread that is sending this message. The MsgPass Class This class has been implemented for you, however mutual exclusion has not been added for access to the message queue. Notice that there is an instance (called m) of this class already created for you in the file. Implement: You must implement mutual exclusion within this class for reading from and writing to the queue. Please keep the scenario above in mind when implementing this. The functions in this class are as follows: 1. MsgPass(uint upper b) - The constructor simply initialises an upper bound for the queue size. 2. void send(struct Message m) - This adds the message m to the message queue. 3. struct Message recv() - This removes and returns the first message in the message queue. 4. bool isfull() - Uses the upper bound specified in the constructor to check whether the number of messages in the queue has reached the upper bound and returns true if it has and false otherwise. 5. uint getsize() - returns the number of messages on the queue. 6. bool empty() - returns true if the queue is empty and false otherwise. Implementation You must implement all the empty functions in the msgpass.cpp file. You may reuse code from the previous task to complete them. Realise that the eventhread, oddthread 7

9 and spin functions have been removed and two new functions have been added. The two functions are as follows and either all or some of the code in these functions need to be implemented: 1. passalong(int index) - This function requests the piece of the ASCII art from the server and constructs the message (using the Message struct) to be sent and placed on the message queue. You must simply create a new message, initialise the variables of the message with the piece and the thread index. The send has been given to you. 2. getandwrite() - This function is called from the passalong function (by the mediator thread) and should receive all the messages from the message queue and print them in reverse order based on t ind. Remember: The mediator thread (to print the final result) must be called after all threads have finished adding their messages to the message queue. Your output should look similar to the following: (b) MsgPass File Output (printer) (a) msgpass.cpp Screen Output Important! You have to use the specified C++ program names. You have to create and upload a makefile. You need to upload task2 and task3 to the corresponding Fitchfork upload slots. 8

10 Task 4 - Theory on Deadlock and Mutual Exclusion [8 Marks] In this task you are required to answer the following questions in a summarized form. You should be able to answer these questions in person during the demo session as well. (a) In Task 1 explain the two forms of deadlock that occurred and explain why they occurred? (b) Assume that when implementing the tasks above the c++ mutex library was used ( Referring to the scenario throughout this practical, what is the main potential problem that can, although rarely, occur when using this mutex library? (c) In your implementation of mutual exclusion in Task 2 how did you stop the deadlocks in Task 1 from occurring again? (d) In Task 3, why was it important to lock access to the message queue? (e) With reference to the Readers/Writers problem in the book, why would you say that the message queue implementation in Task 3 is not necessarily seen as the typical Readers/Writers problem? (f) Assuming there was no locking mechanism for reading from the queue, why would it be a problem if multiple clients/threads were to concurrently receive messages from the message queue in Task 3? 9

11 Upload Instructions As it would be impractical to upload your Virtual Machine to the CS website for the practicals, you are required to submit your code and answers to the written questions: Upload all your tasks in a zip or tar.gz file to the Practical 3 assignment slot on the COS 122 course website before 22:00 on Monday 13 September No late submissions will be accepted. Upload your Fitchfork tasks in a zip or tar.gz file to the corresponding Prac 3 task slots on the assignments website before 22:00 on Monday 13 September No late submissions will be accepted. Please make sure that you do this as there have been a number of queries saying that they have not uploaded to Fitchfork as well as the normal upload slot. You have to demo what you uploaded to the COS 122 course website. All written answers must be in either txt or pdf format no other formats will be marked. Every file you submit should contain your name, surname, and student number at the top of the file in comments. Only upload your source code, makefiles, and supporting documents. upload large, binary, or OS files. Keep your uploaded archive small. Do not Failure to upload your work will result in 0 marks being awarded for your practical. Demo Instructions At the demo, we will check your uploaded work. Only students who have uploaded on time will be allowed to demo. You may only demo during the slot where you are booked. You should be able to demo the practical within Virtual Box. This practical must be marked by a tutor or teaching assistant during your booked practical demonstration sessions. You have to be there at the start of the session until you get marked. If you come just before the session ends you will not get marked. You have a limited time to demo approximately 8 minutes. Please ensure that your VM is running before you get marked to speed up the process. If your program doesn t compile due to syntax errors you will get 0 marks. If your program receives a runtime error you will lose marks. If your program still has deadlock for Task 2 and/or Task 3 you will lose marks. 10

12 You have to be prepared to answer any question(s) the teaching assistant or tutor may ask you. You should not have to waste time looking for the answer. Make sure that you sign the attendance register for the session and ensure that the teaching assistant has entered your mark on the mark sheet correctly. Failure to demo your tasks will result in 0 marks being awarded for those tasks. Total: [41] 11