Task Parallelism, Recursive Splitting, Discrete Event

Task Parallelism

1.- When you first saw this pattern title, did you feel like you knew the subject beforehand? After reading the pattern, did you confirm your impression or did it surprise you? how?

The title gives a pretty good idea on what to expect. I knew the pattern will describe a solution that consists of dividing a problem into a series of task and solving then concurrently. I did not directly think about defining tasks with data distribution as a primary concern.

2.- In what category falls this pattern?

I am not sure how to classify this pattern. In order to produce the tasks, this pattern can use both the structural pattern and/or computational patterns that describe the problem.

3.- What platform do you have more experience programming parallel applications on? And what Task Management Mechanism? (Jobs over Networks, OS Processes, SW Task Queue, HW Task Queue)

I am working on a prototype to convert a sequential I/O firmware to a parallel application on an embedded I/O adapter consisting of 2 powerPC cores. I have not done much yet that I can share. I am still in the process of getting embedded Linux to boot on the platform before I start to change the current application.

5.- Do you think that this patterns requires you to learn more about hardware platforms in order to make a correct implementation?

The pattern requires the user to have an understanding of both the application’s concurrency characteristics and the hardware platform characteristics in order to arrive at the solution. I think this is good idea because many systems do not perform at their full potential because the programmers only focus on understanding one side. I worked in a system where knowing the cache replacement algorithm of the CPU allowed us to make changes in the application that led to a urge performance improvement. In parallel programming I believe that a good solution is not possible without a good understanding the parallel hardware characteristics.

Recursive Splitting

This pattern describes a solution to problems that can be recursively decomposed in a series of independent tasks. The recursive splitting problems can be solved in parallel hardware by having nodes work concurrently on different recursively generated task. The major issue to be addressed while applying this pattern is to come up with a choice of splitting that make efficient use of the hardware resources to produce the solution. The author mentions the tradeoff between getting greater efficiency by selecting larger base cases, versus getting greater opportunity for concurrency by selecting small base cases. The author provides good explanations on how to implement the solution and states the cases where the solution is not applicable. The premise for the pattern to work is to recursively generate more than one task per tasks. So problem like selection sort where only one task is recursively generated are not applicable.

Discrete Event:

This pattern is similar to the Event-based except that here, more consideration is given to ordering constraint and a solution is given that provides a simple way of dealing with the constraints. I agree with the author that often the best approach to deal with deadlocks is to use timeouts. I work on a real time system where we use timeouts to make the system predictable. It is easier to implement and works very good in our environment.