For this exercise you should create your own implementation of a thread pool. In preparation for this exercise, you should change the ImageProcessorMT class so that it implements the Runnable interface. Your thread pool will manage threads that run your new ImageProcessorMTs. The thread pool class itself should also implement Runnable.
The thread pool should offer a constructor that receives the size of the thread pool as a parameter.
The thread pool has relatively simple functionality. It should be possible to submit a task
(i.e. an ImageProcessorMT) to the thread pool. This does not mean that the task will actually run yet, just that the thread pool is aware of it and keeps it in a waiting list. The number of ImageProcessorMTs that are added can exceed the number of threads available in the thread pool.
It should also be possible to start the thread pool. This means that the thread pool will then run as many ImageProcessorMTs as it can up to its size. For example, if the thread pool size is 5, but 10 ImageProcessorMTs have been added, it can only run 5.
When any ImageProcessorMT has terminated, a new one from the waiting list should be started by the thread pool (if one exists). The thread pool should continue to do this until the waiting list is empty, when it should itself terminate.
The thread pool should offer a join() method that causes the calling thread to wait until the thread pool has terminated.
Note that when you change ImageProcessorMT to implement Runnable, its run() method works the same way as it does in ImageProcessorST: it processes the image and then exits (terminating the thread). You might wish to add a boolean and a getter to ImageProcessorMT that signals that the run method has terminated, hence the result is available, and the thread pool can now run another thread (if the waiting list was not empty).
Exercise 2: Parallelising ImageProcessorMT
For this exercise you will take the existing ImageProcessorMT class and parallelise the filtering and greyscale operations. Remember, the ImageProcessorMT class itself should already now implement Runnable as a result of Exercise 1.
Parallelising these operations means simply ‘slicing’ the image data and giving each slice to a thread to work on. If there are two threads, for example, each would perform the filtering or greyscale operation on half of the image data. This means that the pixel data produced by all of the threads must be ‘reassembled’ at the end to create one array of pixel data as the result.
There are some practical limits to this approach. For example, if an image has dimensions 256x256 then, at
most, you can set 256 threads working on the image - one row of pixels each5. However, this might negate the benefits of parallelism due to the overhead introduced by the parallelisation. You should parametrise the number of threads created and experiment with the effect of changing the number of threads. To get your code working, make sure at first that it works with one thread before adding more.