Recursive Splitting, Task Parallelism, and Discrete Event

The title of the Task Parallelism brought to mind many of the similar papers and patterns we have already discussed in the class, ones that talked about how to correctly leverage the splitting of large complicated tasks into ones able to take advantage of multiple processors. The paper did indeed end up discussing this, not to my surprise, but seemed to function more as an overview or index of other patterns, and a discussion of what is necessary to get them to work efficiently. It makes sense then that we have held off on reading this until now, as discussions of things like the Monte Carlo Simulation do require enough of a working knowledge to gain the full impact. Because this level of parallelism has to be kept in mind from the beginning in order to ensure that proper utilization occurs this pattern is firmly placed in the structural category. I don't think hardware is the issue here, the bigger hurdle seems to be that we engineers and developers are not properly creating the software to take full advantage of the hardware available, and as I've mentioned in earlier posts I'm not expecting this to change anytime soon without a concentration of effort to provide some tools.

The Recursive splitting paper made me question why we were assigned this paper. As it seems like yet another paper that discusses using a Fork Join framework to make computation faster, and I could swear we had already had at least one paper that discussed using recursive calls as the basis for producing new threads. Or maybe it's just that the frequent extolling of Fork-Join's low overhead, good switching, and safety have made it so that I automatically associate its use with any paper that begins discussing taking advantage of parallelism. I also question the use of insisting that this paper utilizes the Divide and Conquer pattern when the paper clearly says that it is that same class of problem that it is intending to solve.

For the Discrete Events paper, I would initially say that I have yet to work in a memory sharing environment, but have clocked a decent amount of time working with message passing systems, typically over networks. Since deadlocks can occur for many reasons, especially when we're waiting for tasks that can occur in different orders every time most systems would prefer to analyze expected runtimes for the various components that will allow for a sensible timout to be set. With the technologies that underlay most networks, busses, and similar message passing structures we should be able to trust that lack of returns in this reasonable amount of time is the result of failure and not inefficiency. Of course, this assumption won't work in all cases, such as ones where modules exist on multiple platforms and those platforms experience unexpectedly heavy loads. But in those cases the tasks may never finish, or may arrive too late anyway, so discarding and attempting again may alleviate these problems. Since an in-depth knowledge of the problem space and the solution possibilities exist already in the mind of the designer they should be able to recognize those few cases where the formal deadlock condition is preferred and plan accordingly, but I don't expect this to be a frequent thing.