Operating Systems 2020W: Assignment 3
Please submit the answers to the following questions via CULearn by 14:30 PM on Wednesday, March 25, 2020. There are 20 points in 6 questions.
Submit your answers as a gzipped tarball "<username>-comp3000-a3.tar.gz" (where username is your MyCarletonOne username).
The tarball you submit must contain the following:
- A plaintext file called "<username>-comp3000-a3-solutions.txt" containing your solutions to all questions, including explanations. Further details are provided below.
- The source code for the requested programs.
- Makefiles for building your code. (You should make separate directories for the userspace programs and the kernel modules, as they have distinct Makefile requirements.)
- A README.txt file listing the contents of your submission and explaining how to build everything.
No other formats will be accepted. Submitting in another format will likely result in your assignment not being graded and you receiving no marks for this assignment. In particular do not submit an MS Word, OpenOffice, or PDF file as your answers document!
Empty or corrupted tarballs may be given a grade of zero, so please double check your submission by downloading and extracting it.
Don't forget to include what outside resources you used to complete each of your answers, including other students, man pages, and web resources. You do not need to list help from the instructor, TA, or information found in the textbook.
Contents of Plaintext File
The plaintext file you submit with your assignment must include a detailed explanation of your reasoning for all questions.
For coding questions, explain the changes you made to the original file, including why and how these changes work. Your explanations should make reference to the source file you include with your submission. You may wish to include diffs against the original code to augment your explanation. Your grade for coding questions will be based partly on the provided explanation, and partly on whether your code compiles, runs, and does what it is supposed to do.
For all questions, answers should be detailed and reflect an understanding of course material.
Creating a Gzipped Tarball
You can create gzipped tarballs on the course VM with the command tar cvzf dest.tar.gz source.
For example, if my name was John Doe and I had an assignment folder named johndoe-a3,
I could create a gzipped tarball of that folder as follows:
tar cvzf johndoe-comp3000-a3.tar.gz johndoe-a3
Before submitting your assignment, you should test to see that your gzipped tarball actually has the correct contents. Following the above John Doe example, I can extract my tarball by running tar xvzf johndoe-comp3000-a3.tar.gz
and then inspect the contents.
Questions
- [4] Create 3000pc-fifo-consumer.c and 3000pc-fifo-producer.c, two separate programs that do the same thing as 3000pc-fifo.c's consumer and producer, respectively. They should communicate using a named pipe specified as the last command line argument, and you should remove unneeded arguments and code. (So 3000pc-fifo-consumer should take a count, con_interval, and pipe filename as arguments, while 3000pc-fifo-producer should take a count, prod_interval, and pipe filename as arguments.) Explain briefly the relationship between your two new programs and the original, outlining what changes you had to make.
- [4] A classmate was discussing 3000pc-rendezvous.c and said "I don't understand why that rendezvous program has to be so complicated, it should just use regular ints rather than those weird semaphores." To try and answer your classmate's question, do the following to create and analyze 3000pc-rendezvous-simple.c on a VM with at least two cores (check /proc/cpuinfo):
- [1] Remove all the pthread_ and sem_ declarations and replace them with standard C types (or structs of standard C types). (If you remove the includes for semaphore.h and pthread.h, these will become compilation errors that you can then fix.) Hint: you don't need anything fancy.
- [1] Remove all pthread_ function calls, replace with functions of your own design. For semaphores, when sleeping just busy wait (loop forever until the condition is met). For condition variables, do short sleeps in between checking the condition, e.g., usleep(1000).
- [1] Run multiple tests. Does your modified program run correctly? Be sure to test with no pauses and lots of events (at least 10,000, preferably many more). How did your modified program behave compared to the original?
- [1] Is your modified program handling concurrency properly? Specifically, is your replacement code good enough to replace the pthead_ routines? Discuss in light of your results and what we have discussed regarding concurrency.
- [4] Create 3000pc-rendezvous-thread.c by changing 3000pc-rendezvous.c to use two threads in one process, rather than two processes. Use pthread_create() to create the thread rather than fork(), and replace the mmap() with malloc(). Be sure to make the producer run in the new thread. Explain what you changed. Use the source for thread_example.c below to see how to create threads. Note the declaration of thread_start() and how parameters are passed.
- [2] Answer the following questions on the ones module:
- What code in the ones module causes /dev/ones to be created?
- What command(s) could you use to create a file ones-copy that would provide access to the character device of /dev/ones?
- [4] Create a new kernel module yourtask.c, based on newgetpid.c, that creates a character device /dev/yourtask. When you write a PID value (such as 5112) to /dev/yourtask, on the next read it returns one of the following strings:
- Task 5112 is yours!
- Task 5112 belongs to uid 1200!
- Task 5112 is yours but acts as 1200!
- Task 5112 is 1200's but acts as you!
The appropriate answer should be determined by the values of the given process's (task's) uid and euid when compared to the uid and euid of the process reading /dev/yourtask. (Your solution gets two points for handing the write correctly and two points for handling the read correctly.)
- [2] Would it have been harder to make /dev/yourtask report usernames rather than uids? Explain, outlining at least one strategy for outputting usernames rather than uid's.
Code
/* thread-example.c
simple example program that creates one thread
*/
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <unistd.h>
typedef struct params {
int x;
} params;
void *thread_start(void *args)
{
params *p = (params *) args;
printf("Thread starting! Argument is %d\n", p->x);
return NULL;
}
int main(int argc, char *argv[])
{
params *p;
int error;
pthread_t tid;
p = (params *) malloc(sizeof(params));
p->x = 25;
error = pthread_create(&tid, NULL, thread_start, p);
if (error != 0) {
fprintf(stderr, "Could not create thread\n");
}
sleep(1);
printf("Main finished.\n");
return 0;
}