COMP SCI 2005 - Systems Programming - Assignment 4: Thread Exercises
Assignment 4 - Thread Exercises
This assignment is designed to test your understanding of threads, mutexes and signalling. Download the following files: slow_functions.h slow_functions.c part2.c You will need to include them in your compilation. You will write your own part1.c and modify part2.c .
Part 1 - Threads (25%)
Within "slow_functions.c" there are two "slow functions". The first, requires a second to 'generate data'. It then increments a counter guarded by a mutex. If the counter reaches 10, it prints "W ork Done". The second prints a message "Start 2", then waits for 2 seconds before printing "End 2". The goal is to get the "W ork Done" string to land in between "Start 2" and "End 2". Start 2 Work Done End 2 You are to write a file "part1.c". You may do what you like in this code (part1.c) but you must call both "slow functions" AND you may not modify "slow_functions.c" . Additionally , you may not call slow_functions1 unless slow_functions2 has been called - the code prevents it from working! Herein lies the challenge. To get the correct order of print statements (above), you need to run slow_function1 ten times. However , the first time you run slow_functions1 must be after you have run slow_functions2 (because there is a mutex initialisation needed). Both Start 2 and End 2 are in slow_function2. Hence, you need to somehow run slow_function1 ten times in between starting slow_function2 and finishing slow_function2. Keep in mind that you only have 2 seconds and yet slow_function1 requires 1 second to run. Sounds impossible right?
Threads are your friend.
Part 2 - Signalling and Mutexes (50 %)
Having solved a fairly small threading task, now it is time to try to get threads to communicate well. Like part 1, this section relies on functions found in "slow_functions.c". Again, you may not modify this file. You will also be provided with part2.c. This file contains two functions (where you will do your work) and a main (which you will leave unmodified - well, you are allowed to add stuf f before and after the // ### DO NOT MODIFY sections, but please don't make it a big "if (false)" or something ridiculously like that. The main function does the following: It reads input from a file (i.e. ./P ART2 < input_file). It then starts two threads: writer and reader . Your job is to write the contents of these two functions. writer The goal of writer is simple. It must call bad_write (found in slow_functions.c) once for each line of input. reader The goal of reader is simple. It must call bad_read (also found in slow_functions.c) once each time something is written by bad_write . Now here is the trick. bad_read and bad_write both access a single buf fer and both have some arbitrary delays in them. This means that simply having two threads trying to write to the buf fer and read from it simultaneously will never give you the right output. bad_read replaces anything it reads from the buf fer with garbage text so beware. Fortunately whenever bad_write writes, it sets a flag and whenever bad_read reads it sets it back. You can access this flag via get_written (it is hidden in slow_functions.c ) so this can help you get the timing right. So mutexes will be your friend here. You will have to decide how best to use them. Moreover , mutexes are likely to be insuf ficient. You will probably need some wait conditions (maybe two) to make sure the two threads play well with each other to get the desired output.
Part 3 - Style (25 %)
Of the code you write, make sure it is well commented and formatted. You should know the drill by now.
Submission
Makefile I am going to do the following: 26/05/2023, 16:04 Assignment 4: Threads make part1 make part2 ./PART1 ./PART2 < input_file It is up to you to ensure your Makefile (which is required) will handle this sensibly . Do not forget that threaded programs need -pthread as a flag and that you will need to include slow_functions.c in your commit/compilation. SVN This assignment is basically like every other assignment you’ve ever done in CS... but just as a reminder: The handin key for this exercise is: assignment4. The following SVN commands will enable you to make a repository for this assignment. Please note the following: Perform these steps in the order written once only! Replace aaaaaa, where it appears in the commands, with YOUR student id. Some commands are long — they must be typed on one line. Use the Unix “cd” command to change to the place where you want your exercise directory to be stored, then type these commands: svn mkdir --parents -m "spc assignment4 start" s1/spc/assignment4 (creates this directory in your svn tree) (change the a1xxxxxx and 20YY) (checks out a working copy in your directory) You can now begin work. You can add a file to the repository by typing the commands: svn add NAME-OF-FILE svn commit -m "REASON-FOR-THE-COMMIT" where “reason-for-the-commit” should be some brief text that explains why you changed the code since the last commit. Note that you only need to add a file once — after that, SVN will “know” it is in the repository . You are now ready to commence working on the exercise. The files you handin must include:
- Your C source files as specified above.
- A Makefile that will compile your C sources as specified above. Make sure you commit your files frequently , in case you have an accident. The University’ s SVN repository is very reliable, and is backed up regularly — your computer probably is not... Regular
submission is also a good defence against plagiarism by others, since the submissions are dated. We will test the behaviour of your scripts using an automated tester . The tester is thorough, and will find places where your scripts do not work correctly . If it finds an error , it will of fer a (vaguish) hint. To encourage you to test your own work, the tester will not be fully available in the first few days before the exercise deadline.
The websubmission system will award up to 6 marks automatically . We will manually check the code for style and commenting. Note that we reserve the right to deduct marks if your code does anything egregious or games the system to obtain marks.
