Description
What is a print server?
• Consider a single globally shared printer queue that all processes and threads can read
from or write into. The print queue has a finite size of 30 print jobs.
• Producer-Consumer problem: user processes versus consumer threads.
• The user processes act as producers and add print requests into the queue. Each print
request is characterized by it’s size (in bytes). Each user can submit upto 30 print jobs;
use a random number generator to determine the number of jobs for each user. For each
print job, use another random number generator to find the size (in bytes) of that print
request (between 100-1000 bytes).
• The different printers serve as consumers and run on different threads. Each such printer
can process a print job and removes it from the global print queue.
• The main process will read the command line to determine the parameters, start the
producer processes and consumer threads, and acts like an interactive command console.
It also initializes the print queue but cannot modify it after initialization.
• The command line parameters include: (i) number of producer (user) processes, and (ii)
number of printer (consumer) threads. Use nanosleep() or sleep() utilities to simulate a
random delay (between 0.1 – 1sec) between two successive print jobs submitted by the
same user. The user process inserts the print request into the global print queue;
additional book-keeping parameters are allowed to be inserted. Hence, use a struct for the
producer print request and the global queue will be an array or linked list of structs;
similarly, use a struct for the consumer to process a print request. The producer processes
cannot remove anything or update a currently existing print request from the queue.
• Each of the printer threads will process one print request at a time depending on their
availability for as long as the queue is not empty. You need three semaphores (i) to check
if the queue is full, (ii) to check if the queue is empty and (iii) for reading/writing the
same queue element. You need to initialize these semaphores before starting the
processes/threads. Since the semaphores need to be shared between the processes and
threads, set them up on shared memory. Use your implementation of counting
semaphores from Assignment-2 for the counting semaphores needed in this exercise.
If you face problems with the semaphores on shared memory, use the named semaphores
method shown here: https://stackoverflow.com/questions/8359322/how-to-sharesemaphores-between-processes-using-shared-memory
This approach uses sem_open() calls instead of sem_init(). It is quick and easy.
No need to create shared memory separately for your gate1/mutex1 or gate2/mutex2 or
the buffer_mutex variables. You still need shared memory for the “value” field of the
triplet of variables that implement your counting semaphores though.
• The main process needs to figure out when all print requests have completed and then
deallocate the global print queue; also deallocate the semaphores. The printer threads can
only exit after all print requests have completed. You may have to use messaging
between threads to signal them to complete or this can be simply handled by semaphores.
• Print out the results after all threads have completed. Specifically, we want how many
print jobs and of what size each were sent to the print server by the user processes. Then
for each printer (i.e., consumer thread), we want to check how many print jobs (and
bytes) were actually processed.
• Use a signal handler in your code to ensure graceful termination of the threads on
receiving a ^C from the console.
• Finally, turn in a report to show the execution times of your code as a function of the
number of users (producers) and printers (consumers). Also, report the average waiting
times for all the print jobs as a function of these metrics for BOTH the LIFO and FIFO
queue implementations. Additionally, mention which portions of your code are not
working in the report.
The global print queue: two implementations are needed.
• First use the global count concept for producer/consumer problems from Assignment-2
(maintained by the variable buffer_index). This is essentially the LIFO queue.
• Next use the FIFO queue implementation from Assignment-2.
Note: Late assignments will lose 5 points per day upto a maximum of 3 days. Code must compile and execute
on the class Linux server.
Deliverables:
Output format:
For each job enqueued/dequeued, print out the following:
Producer added to buffer
Consumer dequeue <process-id, job_size> from buffer
Also print out the total execution time and average waiting time at the end of your code.
Report format:
1) First give an outline of the working portions of your code. For each part not functioning list them
out.
2) Second: show the following: (a) logic used to identify the terminating condition, (b) how were
the semaphores and other book-keeping variables shared between processes and threads, (c)
what was done in the signal handler for graceful termination and (d) how did the LIFO and FIFO
implementations differ in terms of your usage of either the buffer_index variable or in/out
pointers (or some other method that you may use for the FIFO queue).
3) Third: show two sample runs of your code one for LIFO and other one for FIFO. Just copy-paste
the code output from the server.
4) Finally, show the execution time and average waiting plots for LIFO and FIFO for different values
of number of producer processes and number of consumer threads. Plots will be good to show
here or you can simply use a table format; vary both #producers and #consumers.
5) Two options:
a. 3-D graph: you will just have a single 3-D graph for LIFO, and another 3-D graph for FIFO
to report execution times.
b. 2-D graphs: 5 different graphs are needed for #producers = 2, 4, 6, 8, 10 respectively. In
each graph, plot execution time VS number of consumers (varied as 2, 4, 6, 8, 10) for
LIFO and for FIFO. So each 2-D graph will have two lines, one for LIFO and other one for
FIFO.
Turn-in:
Submit two versions of your code: one for LIFO, other one for FIFO. Keep the output format (from
above) the same for both implementations. Additionally, submit the report. All files must be uploaded
through Canvas.
Bonus points:
You can get 10 bonus points if you implement the extension where each queue element is controlled by
a separate binary semaphore. You need 30 additional binary semaphores to do this. Show the execution
time improvements (if any) for this case.
