COSI 131 Programming Assignment 1, Part Two
Due October 7th, 2019

As most medical advice goes, there is some good news and some bad news. The bad news is
that your work with the Unix-ish system is not yet complete. The good news is that you are very
close to completing the second part, and you will be given a completed version of Part 1,
regardless of whether you finished it. From this completed version of Part 1, you will not have
to modify too much code to complete this part of the project, but you will not be successful
without a clear mental picture of how threading works, and how threads can be started and
waited upon.

In the second part of the assignment, you will leverage your new knowledge about threads in
Java to make your REPL loop's components (its filters) execute in separate threads, thus
allowing the program run concurrently. Additionally, you will allow the commands to be
executed as background processes.

Part 1: Concurrent Filters

You will need to change the general structure of your program very little; however, your
Sequential classes will all have to be transformed into Concurrent counterparts (to be placed in
the concurrent package instead of the sequential package). Some of the changes and
considerations you will need to make are given below. This is not a complete list, but should
comprise enough to get you started, and thinking about the right pieces of code to create and
change. The description assumes that you understand how threads operate. If you have any
ambiguity about these concepts, please read about it online, in the textbook, or from the
lecture slides/notes before attempting to complete this assignment. These
reminders/ideas/questions should get you set up to do this portion of the assignment.

• ConcurrentFilters should implement the Runnable Interface. When will you call run()? 

• You will need to change the mailboxes for the filters from LinkedLists to a data structure
that supports concurrent operations (The LinkedBlockingQueue class is such a structure.

Read about it! Only proceed when you understand what will happen if a thread tries to

read from a blocking queue when it is empty.)
• You will have to wait for all (or the last) filter(s) to complete before printing out the " >"

prompt.
• Your REPL loop will have to create all filters before starting any of them (why?) 

• A reminder: creating threads != concurrency. How can we have sequential code using

threads?
• Your isDone() methods need a totally different approach now (why?)
• What happens if the threads process at totally different rates (1 : 10000x slower?)

Your resulting code should behave just like the sequential version that you have completed for
part 1, and the end user should have no idea that there is a difference. Since we already graded
you for this functionality, what will be grading you in this portion of the assignment is how your
code demonstrates your understanding of multi-threading techniques, and how you go about
accomplishing this task. There is a "correct" way to do it, and you will be graded upon how your
understanding of threads allows you to approach this "correct" ideal. Thus, it is HIGHLY
recommended that your code is clean, well named, well commented, and immediately clear to
someone who will determine your grade in the ten minutes they have to read over it. 


Part 2: Background Commands

After you have completed the above task, the final portion of the assignment is to support a
simple form of background processes. The following page can help you understand what
background processes are. After reading through this resource, it is highly recommended that
you play around with background processes on a UNIX console.

What you need to know link
Running background processes, Listing
background processes
http://www.ee.surrey.ac.uk/
Teaching/Unix/unix5.html

Your task is to allow the end user to run and list the background commands, and to kill any one
of the running background commands. You do not have to provide functionality that allows to
suspend a command, or to bring a command from background to foreground.

Whenever an end user types the “&” ampersand at the end of a command the REPL loop does
not wait for the entire command to complete but it directly prints out the “>” prompt to accept
new command while the previous ones might still be running. This allows your Unix-ish system
to execute commands in parallel. This is useful in cases where you have to execute long running
commands and you don’t want to wait for the previous commands to finish in order to start the
new ones. For example, suppose you have a big file of Amazon reviews and you would like to
create a file with the reviews that contain the phrase “amazing product” and a second file with
the reviews that contain the phrase “bad product”. You can accomplish that by executing the
following commands:

> cat Amazon-reviews.txt | grep amazing > amazing.txt &
> cat Amazon-reviews.txt | grep defective > defective.txt &
>

You know that these two commands will take a while to run and so you can have them running
in the background while you are still able to execute other commands.

Furthermore, the user should be able to monitor what commands are still running. This could
help to avoid exiting the Unix-ish system while there are still commands running. To do this you
need to create a new command “repl_jobs” which checks which of the background processes
are still alive and prints a list of the alive processes. For example:

> cat Amazon-reviews.txt | grep amazing > amazing.txt &
> cat Amazon-reviews.txt | grep defective > defective.txt &
> repl_jobs
1. cat Amazon-reviews.txt | grep amazing > amazing.txt &
2. cat Amazon-reviews.txt | grep defective > defective.txt &
>

The user should also be able to kill a specified command by providing the number that
“repl_jobs” assigned to it. For example, to kill the second command, user would do:

> kill 2

Commands "repl_jobs" and “kill” have to be part of your REPL and not a new concurrent
filter. They can only run as single commands, cannot be part of any command that involves
pipes and do not require any piped input and piped output. Command “repl_jobs” does not
require any arguments.

For this part, you are provided a Starter Kit that includes a solution of part one and a new set of
JUnit tests. You are allowed to use either the solution we provide to you or your own solution
but make sure you use the new set of JUnit tests. Please make sure to include Java Docs for
your code as it counts towards your grade.

Please submit your code by creating an archive (using zip) and upload it on LATTE.