Hacettepe University

Computer Science and Engineering Department

Advisers

:
:
Course
:
Subject
:
Environment
:
Programming Language :
Submission Date
:
Deadline
:

Asst. Prof. Dr. Kayhan IMRE,

Asst. Prof. Dr. Ahmet Burak CAN

R.A. Ali C
AGLAYAN
BBM342 Operating Systems
Multi-threaded Programming and Inter Process Communication in UNIX
POSIX compatible UNIX
ANSI C
26.03.2015
21.04.2015 23:59

Introduction

Operating systems provide a conceptual model consisting of sequential processes running in parallel. Processes can be created and terminated dynamically. Each process has its own address space.
For some applications, it is useful to have multiple threads of control within a single process.
These threads are scheduled independently and each one has its own stack, but all the threads in a
process share a common address space. Because threads share a common address space, they can
communicate and share data in this address space.
When multiple processes/threads try to reach same memory address, data consistency should be
protected. For consistency, if there is any writing operation, the read/write operations should be
organized with primitives such as locks, semaphores, monitors and messages. These primitives are
used to ensure that no two processes/threads are ever in their critical regions at the same time, a
situation leads to chaos.
The aim of this experiment is to make you familiar with some concepts of processes and threads
and have practical experience with multi-process and multi-threaded programming using UNIX and
POSIX facilities. You are expected to develop a (virtual) Multi-Printer Printing System in order to
get familiar with POSIX Threads and Inter Process Communication in UNIX operating environment.

2
2.1

Experiment
Problem Definition

In this experiment, you are supposed to develop a virtual multi-printer printing system. You are
responsible for using POSIX P-Threads (To add multi-threading capability to your programs on UNIX
machines, you should add pthread.h to C source code and link the executable with libpthread library)
and Inter Process Communication in UNIX.
The Printing Daemon and each of the Printers will be represented with distinct processes. The
Printing Daemon Process will be multi-threaded where each Printing Thread communicates with one
Printer Process via pipes. The Printing Daemon Process will also have threads for processing printing
requests. The Printing Daemon will manage a request buffer fed by the Request Acceptor Thread
and consumed by Printing Threads. The request buffer will be fixed sized. Accessing the buffer (for
both writing and reading) will require synchronization of threads. A schematic view of the system to
demonstrate the model explained above is given in Figure 1.
The Printing Daemon is started with three command line parameters. First one is for specifying
the name of the file which contains printing request descriptions. The second parameter is number of
printers in the system. And the third parameter specifies the size of the request buffer (in terms of
number of requests).
After starting, the Printing Daemon creates (forks) a new Printer Process and a pair of pipes for
each printer to communicate with it. The Printing Daemon also assigns a unique printer key for each
printer in creation. The key should be started with printer word and continued with any number
up to the number of printer in the system, e.g. if there are three printers, then the keys are printer1,
printer2, printer3. The Printing Daemon will also have a thread for each Printer Process to handle
printing requests.
As the Request Acceptor Thread starts its work immediately after the Printing Daemon is started,
it does not have to wait for any printer to be available. Its main concern is the status of the request
1

Figure 1: An Overview of the System.

buffer (whether its full or has remaining space). The format of the requests input file is simple: one
request per line where each request contains only the name (path) of the file to be printed.
A Printer Process gets the names of files to be printed within printing requests from the input
pipe. It opens the file and prints (appends) its contents to its output file. Name of the printer output
file is determined by adding an out extension to its printer id, e.g. printer1.out. Each Printer Process
reports back to the Printing Daemon the size of the file it printed (and any other relevant information)
as an indication of successful task completion.
The Printing Daemon also manages an output file in order to log its operations. Each line in the
output file contains a log of the printing operation complete, with the printer id, file name and file
size, e.g. printer1:/root/report.txt:93. Name of the log file is determined by adding a log extension to
the name of the requests input file, e.g. /root/requestSet01.txt.log.
As the buffer is fixed sized and static, it will need to be handled with a circular algorithm. (You
should understand that its just an array of request structures.) You should pay attention to correctly
managing the buffer for concurrent accesses.
2.1.1

The Way of Execution

The program will be executed with three command line arguments:

<Request Set File> <Number of Printers> <Buffer Size>
Usage example:
>gcc printer.c -o printer.exe -Wall -ansi -lpthread
>gcc daemon.c -o daemon.exe -Wall -ansi -lpthread
>./daemon.exe requestSet.txt 3 10

Figure 2: A sample request set file.

2.1.2

Request Set File

This file includes the name of the documents1 which are going to print. You are going to process
this file to feed buffer by the name of documents. Each document name is separated by a new line.
The format is as follows:
< file name 1 >
< file name 2 >
< file name n >
A sample request file is shown in Figure 2.
2.1.3

Printer Output File

As explained above, a printer process gets the names (relative paths) of files to be printed within
printing requests from the input file. It opens the document files and prints (appends) its contents
to its output file. Name of the printer output file is determined by adding an out extension to its
printer id, e.g. printer1.out.
A sample printer output file is shown in Figure 3.
2.1.4

Log File

The Printing Daemon manages an output file in order to log its operations. The result of printing
requests will be printed to this log file. Each line in the log file contains a feedback of the printing operation complete, with the printer id, requested file name (relative path) and file size, e.g.
printer1:/root/report.txt:93.
1

Names of documents are meant to be relative paths (attention not full path!)

Figure 3: A sample printer out file which includes the contents of all the requested documents.
Log file name is determined by adding an log extension to the name of the requests input file, e.g.
requestSet.txt.log
According to above definitions a sample log file is given in Figure 4.
Further examples which give more details will be provided at the courses FTP site and via Piazza.

2.2

Report

You should write a short report with 2-3 pages which gives an overview of your solution. The
length of your report should not exceed 3 pages. The structure of report is described below:
Solution, describe details of your solution. Explain the points at which you use condition
variables and mutexes. Also explain your proposal for essential data structures and parameters
of threads.
References, give the references you used throughout your work at the end of your report.

2.3

Submission

The submissions will be accepted only by http://submit.cs.hacettepe.edu.tr. The submit

should be done until 21/04/2015 23:59 for all sections. Submission format is as follows:
<student id>.zip(example: 21521512.zip)
[src daemon]
daemon.h
daemon.c
[src printer]
printer.h
printer.c

Figure 4: A Sample log file.

[report]
report.pdf
[etc]
requestSet.txt
printer1.out
printer2.out
printer3.out
requestSet.txt.log
README.txt

Grading

Your Experiment results will be evaluated with the following rules. They are fixed. They will never
be changed. Hence obey these rules. Before you contest your grade re-evaluate yourself with these
rules.
The source code of program have 90 points: 20 points for Coding Convention and Design,
10 points for Code Comments and 60 points for Execution.
The report have 10 points.
Your final grade will be calculated depending on the execution of your program. To be able to
get full points from report and other parts of source code, you should get at least 30 points from
execution(30/60).
As understood from grading you should model your system accurately. Attributes and functions
names must be understandable. You should write plenty of comment lines in your code.

Notes
These notes are very important please read them and obey them.
Use understandable names for your attributes and functions.
You are responsible for a correct model design of your program. Your design should be accurate.
Obey general software engineering principles.
You should use threads, mutexes and pipes.
The described model does not contain all the implementation details. You should determine the
communication protocol between the two processes, parameters to pass to threads and how to
pass them. You may further enhance the model by adding new threads if you really think that
it makes sense. (Dont feel an obligation to add new threads! They can turn into threats against
you!)
The request set file, number of printers and buffer size will be taken as command line arguments.
Take care about the formats of output files explained above.
No submissions except Submission System of Computer Engineering Department
will be accepted. Do not send your experiment with emails.
Do not miss the deadline. No submissions will be accepted after 21.04.2015 23:59.

Respect your adviser office hours: Tuesday, 13:30-16:30 (R.A. Ali C

AGLAYAN).

For every question or problem please contact with your adviser R.A. Ali C
AGLAYAN.
Do not
contact with teachers of experiment directly.
You can send email to your advisers email alicaglayan@cs.hacettepe.edu.tr.
You can ask your questions via Piazza ( https://piazza.com/hacettepe.edu.tr/spring2015/
bbm342) and you are responsible for the course page.
The assignment must be original, INDIVIDUAL work. Duplicate or very similar
assignments are both going to be punished.
Save all your work until the experiment is graded.

References
sletim Sistemleri, Prof.Dr. Ali Saatci.
[1] Bilgisayar I
[2] http://www.ibm.com/developerworks/library/l-pthred/
[3] http://www.ibm.com/developerworks/library/l-posix1/
[4] http://www.ibm.com/developerworks/library/l-posix2/
[5] http://www.ibm.com/developerworks/library/l-posix3/
[6] http://www.ibm.com/developerworks/library/l-memory-leaks/
[7] http://www.cs.cf.ac.uk/Dave/C/node32.html
[8] ftp://ftp.cs.hacettepe.edu.tr/pub/dersler/BBM3XX/BBM342_IS/Project2/resources