Description
Introduction
In this programming assignment, we try to further improve the performance of the client by
reducing the thread management overhead required to handle the worker threads. We do this
by replacing the collection of worker threads by a single event handler: Instead of creating a
large number of worker threads and having each handle a separate request channel, in this
programming assignment we have a single event handler thread manage all the channels for
data communication with the data server. (The communication over the control channel is
still handled by the main thread of the client). You are to improve on the client program
from PA4 as follows:
Instead of spawning multiple worker threads, and have each thread separately communicate
to the data server, spawn a single event handler thread, which handles all data request
channels.
Please use your PA4 as the starter code.
The Assignment
You are to write a program (call it client.cpp) that first forks of a process, then loads the
provided data server, and finally sends a series of requests to the data server. The client
should consist of a number of request threads, one of reach person, one event handler thread,
and a number of statistics threads, one for each person. The number of persons is fixed to
three in this PA (Joe Smith, Jane Smith, and John Doe). The number of data requests per
person is to be passed as arguments to the invocation of the client program. As explained
earlier, the request threads generate the requests and deposit them into a bounded buffer.
The size of this buffer is passed as an argument to the client program. The client program is
to be called in the following form:
./client -n <requests/person> -b -w
A few Points
A few points to think about:
• The magic to have a single event handler thread manage multiple request channels is
to use the select() system call. We would decouple the RequestChannel::cwrite()
and cread() pair. Instead, the we would send cwrite() on all channels and then
try to do cread() on them. But, each channel would take a random time to return
with some data from the server (i.e., because the server puts a random delay before
1
CSCE 313
each). Therefore, we need to read the data in the “correct” sequence and the select()
function will help us with that.
The select() call monitors multiple file descriptors and returns to indicate the file
descriptor(s) that show activity. In this way you can have a single thread handle
multiple file descriptors, i.e. multiple request channels. This is different from PA4,
where we had a separate thread for each request channel.
• Have either the main thread or the event handler thread create the request channels
before the event handler thread starts issuing select calls.
• Since the select call uses file descriptors, we have to make the file descriptors used to read
and write data to the request channel accessible to the user. The class RequestChannel
now provides two functions (read fs() and write fs() that return the read and write
file descriptor of the request channel, respectively. These file descriptors can be used to
monitor activity on the request channels. If activity has been detected on the read file
descriptor, only then your code may read the data by calling RequestChannel::cread().
In addition, the next request from the request buffer can be sent to the request channel
using RequestChannel::cwrite(). Note that, in PA4, we could just issue the cread()
without considering all these and wait for the data to arrive. This was alright, because
even with one thread stuck in a cread(), other threads would make progress.
What to Hand In
• Submit the solution directory containing all files and also a makefile.
• Analyze the performance of your implementation in a report, called report.pdf. Measure
the performance of the system with varying numbers request channels and sizes of the
buffer. How does the performance compare to your implementation in PA4? Does
increasing the number of request channels still improve the performance? If so, by
how much? Is there a point at which increasing the request channels does not further
improve performance? Submit a report that compares the performance to that of your
solution in PA4 as a function of varying numbers of request channels (i.e., worker thread
in the case of PA4).
Reading Resources
For understanding the select() function, read from http://beej.us/guide/bgnet/. This
will also be useful for the next programming assignment.
Rubric
1. Event handler thread (30 pts)
• Priming the channels (i.e., sending initial requests): 10 pts
2
CSCE 313
• Re-preparing the fd set during every iteration or using a backup: 10 pts
• Proper termination (showing histogram at the end): 10 pts
2. BoundedBuffer (10 pts)
3. Not having global variables (10 pts)
4. Cleaning up fifo files and all dynamically allocated objects (10 pts)
5. Correct counts in the histogram (20 pts)
6. Report (20 pts)
• Should show plots of runtime under varying n, b, w. Especially, we want to see
variations in b (range [1, 200]) and w (range [1, 500]) after setting n = 10K at least.
• Compare the shape of the runtime curve with that of PA4. Do you see any
difference? Why?
3
