Visual Studio 2013 is not successfully compiling ACE on the Windows machines in Urbauer 218, so you should please use Visual Studio 2012 for this assignment.
Playfunctionality concurrently as in lab 2 (we'll call this program the
Directorprogram), and a separate project for a
Producerprogram that interacts with the user and with various
Directorprograms that have registered with it;
Producerprogram, declare and define a
Producerclass that can interact with the user to display status and receive commands, and can interact with the
Directorobject in each of one or more running
Directorprogram processes, to coordinate the initiation and termination of one or more plays at once on one or more host computers;
Producerprogram that can initialize a
Producerobject, run its event loop, and handle any exceptions or other events that may occur;
Director's program, all of which the
Directorshould scan in order to size its thread pool accordingly;
Producerprograms so that even while other activitie are in progress they can send, receive, and process information across sockets, iostreams, etc.;
Director's program's process; and
Producerprograms, so that if the user hits Ctrl-C the signal is caught and the program can then initiate an appropriate termination protocol, including performing necessary actions in order to notify other programs, release resources, and shut down gracefully.
If you are working in a different team for this lab than in a previous lab, you are allowed to reuse code from any of your earlier lab solutions though if you do that you should please add comments acknowledging contributions from anyone who is not on your current team (and noting in which previous lab their contributions were made), to the code you submit.
Make separate copies of the (source and header) code files from lab 2 that you are using for this
assignment, and put them into the directory where your new project for the
keeps its own source files, before adding them to that project. Not only can this (1) avoid confusing
Visual Studio (with regard to which files to build, where to find the object files from them, etc.),
but it also makes it easier to ensure (2) you have all the files when packaging up your solution to submit
it, and makes it easier (3) to revert to a previously stable code base if a change you are trying doesn't
pan out well.
In this assignment, you will again work with input files in similar formats as in the previous lab 2 assignment, but instead of working with a single script, multiple script files should be able to be specified and used.
For example, a program might be given two script files, partial_hamlet_act_ii_script.txt and partial_macbeth_act_i_script.txt for the first parts of Act II from William Shakespeare's "Hamlet, Prince of Denmark" and Act I from William Shakespeare's "Macbeth" respectively (text obtained from the Literature Page web site at http://www.literaturepage.com/read/shakespeare_hamlet.html), with corresponding configuration files hamlet_ii_1a_config.txt, hamlet_ii_1b_config.txt, and hamlet_ii_2a_config.txt for the first script file and macbeth_i_1_config.txt, macbeth_i_2a_config.txt, and macbeth_i_2b_config.txt for the second.
As in the previous labs, each scene fragment's configuration file gives the name of each character in the scene fragment along with their corresponding part file, e.g., Polonius_hamlet_ii_1a.txt and Reynaldo_hamlet_ii_1a.txt in hamlet_ii_1a_config.txt, Polonius_hamlet_ii_1b.txt and Ophelia_hamlet_ii_1b.txt in hamlet_ii_1b_config.txt, King_hamlet_ii_2a.txt and Queen_hamlet_ii_2a.txt and Rosencrantz_hamlet_ii_2a.txt and Guildenstern_hamlet_ii_2a.txt in hamlet_ii_2a_config.txt, FIRST_WITCH_macbeth_i_1.txt and SECOND_WITCH_macbeth_i_1.txt and THIRD_WITCH_macbeth_i_1.txt and ALL_macbeth_i_1.txt in macbeth_i_1_config.txt, MALCOLM_macbeth_i_2a.txt and DUNCAN_macbeth_i_2a.txt and SOLDIER_macbeth_i_2a.txt in macbeth_i_2a_config.txt, and LENNOX_macbeth_i_2b.txt and MALCOLM_macbeth_i_2b.txt and DUNCAN_macbeth_i_2b.txt and ROSS_macbeth_i_2b.txt in macbeth_i_2b_config.txt.
To complete this assignment please perform the following tasks:
Directorprogram (starting with your lab 2 solution) as follows, to support multiple plays:
argv) as the port and ip address (respectively) on which it should connect to a
Producerobject, (3) treats the third command line argument (
argv) as the minimum number of threads that the program should use in its thread pool, and (4) treats each command line argument after that as the name of a script file that it should load, parse, and use.
If an incorrect number of command line arguments is given, the program should print out a helpful usage message as in:
cout << "usage: " << argv <<
"<port> <ip_address> <min_threads> <script_file>+" << endl;
Directorshould parse all of the script files and their configuration files to determine the maximum number of character parts that appears in any consecutive pair of scene fragments in any of the plays in the list: as in lab 2 the
Directorshould then take the maximum of that value and the value from the third command line argument, and create that many
Directorprogram should first connect a socket to a
Producerprogram using the port and ip address given in the first and second command line arguments, and then wait reactively for further instructions from the
Produceraccording to the instructions below.
Producerprogram as follows:
Producerclass that can reactively (1) interact with the user via the
coutstandard input and output streams; (2) listen for and accept (on a port whose number is either a default value or one that is provided to its constructor) socket connections from
Directorobjects running in other threads or processes; and (3) interact with those
Directorobjects over the socket connections.
Producer should present the user with a numbered menu of plays that are available from the
Director objects connected to it and a status indicator for each play that says whether it is
available, unavailable (due to its director being in the midst of performing another play) or in progress,
and should refresh that list whenever a play is started, completes, or is stopped, or a
object connects or disconnects.
Producer should accept and dispatch commands from the user of the form
<action> [<number>] where the recognized actions are <quit>
(which should terminate the
Producer program), <start> followed by the numer of a
currently available play (which should tell the appropriate director to start that play), or
<stop> followed by the numer of a play that is currently in progress (which should tell
the appropriate director to stop that play).
argv) and if more parameters are provided simply issues a helpful usage message like the following before returning a unique non-zero error code for that case:
cout << "usage: " << argv << "[port]" << endl;
Otherwise the main function should construct and open a
Producer object and run its
event loop until the program is terminated by the user.
Directorprogram so that it uses a port number value (either the one provided to it on the command line, or a default one if the provided value was 0) and IP address (either the one provided to it on the command line or a default one such as the local host or another address if the provided value was 0.0.0.0) to establish a socket connection to a running
After identifying its list of plays, the
Director should send that list over the socket to the
Producer, and then should await a command to start a play, and when receiving a command naming one
of the plays it currently has available should start that play and then notify the
the play has started.
Similarly, once the play completes, the
Director should notify the
Producer that the play
has finished (and that the
Director is now available to perform another play or that one again)
Producerthat the play should be stopped, by issuing a command of the form <stop> followed by the numer of a play that is currently in progress. The
Producershould notify the
Directorimmediately that the play should be stopped.
Director should listen reactively for stop commands from the
Producer even while
a play is in progress, and upon receipt of a stop command should immediately communicate that to the
Player threads which in turn should stop performing the play, release resources and reset information
as appropriate, and return to a quiescent state in which they are ready to start another play if asked to do so.
For example, you may want to have the
Director set a stop flag in the
Play object, which
the threads then can detect, and also have the
Director notify any threads that may be waiting on a
condition variable, as in the thread interruption examples from the course text book.
Once all of the threads have stopped and are reset and quiescent, the
Director should then immediately
Producer that the play has stopped, and the
Producer should refresh its menu of
options to indicate to the user that the play is now available to be performed.
Directorprocess, the process should catch and handle that signal as follows. The signal handler that catches the signal should simply mark a flag indicating that the program has been interrrupted, which one or more of the threads in the program should check semi-frequently - the idea is to do as little processing as possible in signal context, and to perform the shut-down activities in the context of a regular thread.
When the shut-down flag is detected, the stopping protocol described above should be performed, the
Director should tell the
Producer that it is shutting down, and then all threads
should release resources and terminate, and the program should end gracefully.
The producer should simply remove the plays from that
Director from its list, and should then
update the menu it shows to the user.
Producershould send a termination message to each
Directorthat is registered with it, wait for the acknowledgement from each
Director, and have each of its threads release resources and terminate, after which the
Producerprogram should end gracefully.
Director should listen reactively for termination messages, and upon receipt of a termination
message should perform the shut-down protocol described above (as though it was being shut down because of
a Ctrl-C signal).
Producerprocess, a signal handler should catch the signal should again simply mark a flag which one or more of the threads in the program should check, and when the shut-down flag is detected, the termination protocol described above should be performed (as though it was being shut down because of a <quit> command).
Please make sure to test your program with different combinations of plays running and available, and generating various start, stop, and termination events under those different conditions. Please make sure that your solution does not freeze up (deadlock) or suffer obvious (i.e., more than a second or two) delays in its operation or in the handling of events, that you don't see any output corruption or program crashes (which may indicate the presence of race conditions), and that the output generated is correct. Please also make sure that when a play is stopped the various objects involved with it are reset into a state where they can re-start that same play, perform another play, etc.
In particular, all lines that do appear should be delivered, they should be delivered in order with respect to each other and with respect to the other lines by other characters in the scene fragement, and the program should not experience deadlock or even undue delays due to missing or misordered lines.
One approach to this would be to have each
Player sort their structured line data by number (thus also
trivially solving the issue of lines being scrambled in the part definition file), and then inform the
of all the contiguous ranges of their line numbers. The
Director then could match up all the ranges
from all the
Players, identify any gaps in the line numbers, and then implement a protocol such that
when a gap is reached the
Director simply advances the current line counter to the start of the next range
Player is ready to recite.
How you design this is up to you, though you should please test your solution thoroughly to ensure that whether or not lines are missing the program performs correctly in all other features as well as in the ones for extra credit. Please make sure to document your design decisions, and your rationale for them, as well as describing how you implemented this extra credit portion, in your project report under a section that is clearly identified as being for the extra credit portion.
You may request other options for extra credit, which I will approve if they are of similar complexity and of similar relevance to the assignment. Please send me e-mail with any such proposals and any that I accept will be posted here and in an e-mail that I'll send out to all students in the course.
The following additional extra credit options have been accepted and approved so far:
However you design your approach, please provide both a detailed explanation of your implementation, and a rationale for how it avoids deadlock and delivers all the lines that are available, in your project report.
The first section of your ReadMe.txt file should include:
The second section of your ReadMe.txt file should provide detailed instructions for how to:
The third section of your ReadMe.txt file should provide a reasonably detailed description of how you evaluated your solution, including the kinds of configuration and character part files you used and their formats (including well formed and badly formed content, misordered lines, etc. to test how your program handled those variations), and any other scenarios that you tested that you consider important.
Please be thorough in writing up your project report, as it will be worth a full letter grade (10 percent) of the assignment overall.
firstname.lastname@example.org a single .zip file attached containing:
#if ! defined (MY_FILE_H)
// body of the header file
#endif /* defined MY_FILE_H */
new) and/or write exception safe code (e.g., using the RAII idiom) - please don't let an exception escape main uncaught, though.