Homework Assignment #8 [55 points + 10 points extra credit]

Overview

In this assignment we enhance the ics432imgapp application in three ways:

• Use java.util.concurrent.ArrayBlockingQueue
• A shared producer-consumer setup for all jobs
• Multiple processor threads for using multiple cores

In this assignment you have to use GitHub Issues as follows:

• When a question in the assignment asks you to create a specific issue, do so in your repo
• For each commit that directly pertains to that issue, reference the issue number (e.g., #132) in the git commit message. (A single commit could reference multiple issues, but that should be relatively rare.)
  • If you forgot you can amend a previous commit message.
• You are welcome and encouraged to create your own issues as well.
• You can close an issue whenever you are confident that you have addressed it.

How/What to turn in

• After creating a release named 1.4 in the Github repo, a code snapshot for release 1.4, as downloaded from GitHub. This the code you will be graded on.

Question #1 [20 pts]: Using an ArrayBlockingQueue

Create and address the following GitHub issue:

Issue Title: Using an ArrayBlockingQueue for Producer-Consumer

Issue Label: enhancement

Issue Description:

• Replace the homegrown producer-consumer buffer by an ArrayBlockingQueue from java.util.concurrent
• Remove the “Multithreading” Checkbox, and make it so that job executions are always multithreaded
• Remove the “#images in RAM” Slider; instead make it the the producer-consumer buffers can contain at most 16 elements. Also, set the heap space (back) to something large in the pom.xml (e.g., “<option>-Xmx4G</option>”)

Note: From this point on, you can use whatever you want in java.util.concurrent. But keep in mind that higher abstractions can be sometimes convenient and sometimes cumbersome.

Question #2 [35 pts]: Using a single producer-consumer setup for all jobs

One issue with our current application is that concurrently running jobs each use their own producer-consumer setup, so threads will compete for I/O, RAM, and compute hardware. Furthermore, setting a bound on the number of images in RAM doesn’t work across jobs. Instead, we want to have all jobs use a single producer-consumer setup.

Create and address the following GitHub issues:

Issue Title: Shared Producer-Consumer buffers

Issue Label: enhancement

Issue Description: Make it so that all jobs use the same producer-consumer setup:

• Only three threads for all jobs: a reader thread, a processor thread, and a writer thread
• A single producer-consumer buffer “between” the reader thread and the processor thread
• A single producer-consumer buffer “between” the processor thread and the writer thread

Note: With this implementation, jobs will be executed in first-come-first-served fashion, which is fine. That is, no two jobs will run at the same time.

Note: The above will likely require some re-engineering as now producer-consumer buffers will contain work units that belong to different jobs. Likely a good idea for a work unit to have a reference to its job.

Note: It’s ok for one reader thread, one processor thread, and one writer thread to run forever, as long as they don’t proliferate. Don’t forget to call setDaemon(true) on those threads so that the application can terminate even though these threads are still running.

Todo: In your README file, explain where in your code the threads and the single producer-consumer setup are created.

Question #3 [10 pts - EXTRA CREDIT]: Using multiple processor threads

We all have multi-core machines, so it makes sense to process images in parallel!

Create and address the following GitHub issues:

Issue Title: Multiple processor threads

Issue Label: enhancement

Issue Description: Add a Slider to the Main window that makes it possible to select an integer between 1 and N, with a step size of 1, with some informative label like “#threads”. N is the number of cores (as returned by Runtime.getRuntime().availableProcessors()).

Just like the “Quit” button, this slider is only enabled if no Job window is open.

If the slider’s value is X, then X processor threads are used in the application.

Note: When the user changes the value in the slider, either processor threads are terminated (in case of a decrease) or new processor threads are created (in case of an increase).

Todo: Using the application, apply the Invert, Solarize, and Oil4 filter to the set of 25 jpg sea urchin images on Laulima using 1, 2, 4, and N processor threads (where N is the number of cores on your machine, i.e., the maximum value of the slider), and record the job execution times. As usual, do this on a quiescent machine. In your README file report on the acceleration factor with respect to the execution with 1 processor threads. Your answer should be formatted as a table such as (the numbers below are completely made-up and not realistic):

                Invert          Solarize        Oil4   
1  thread       1.00x           1.00x           1.00x
2  threads      1.40x           4.33x           1.79x
4  threads      2.20x           2.33x           5.19x
12 threads      4.49x           3.33x           3.79x

In your README file briefly discuss the results. For each filter give reasons for how the acceleration factor varies with the number of cores.

Warning: Runs a few “warm-up jobs” in the app before doing your timings.