[erlang-questions] Classification of concurrency patterns

[Mariano Guerra]

On Wed, May 12, 2010 at 5:32 PM, Vlad Dumitrescu <vladdu55@REDACTED> wrote:
> Hi AJ,
>
> On Wed, May 12, 2010 at 21:34, AJ Heller <aj@REDACTED> wrote:
>> @Vlad: While I empathize with you, I do think the distinctions are
>> important. Taking myself as an example, I can still look at most of
>> the GoF patterns and argue that they're each a special case of the
>> Strategy Pattern (though I've learned to stop arguing about this). To
>> people that work with these patterns on a daily basis, the nuances
>> between the patterns are significant. So even though I don't yet grasp
>> many of the nuances myself, I can appreciate that other people do. So
>> long as there are significant differences between appropriate uses,
>> strengths, and pitfalls for a pattern and its variation, I'd argue
>> that the variation probably deserves its own entry in the list. Even
>> if they all still look like divide and conquer to me :) .
>
> I don't disagree. The only item that really isn't a separate one is #4
> (identical jobs) which is identical to #1 - it only happens that the
> number of jobs is the same as the number of processing units that I
> have available here and now. On most other machines it would be
> classified as #1.

I think that the first is a reference to a job where there is only one
result and the job is divided to handle different parts and then
recombine them.

for example you are rendering one frame with ray tracing and divide
the rendering in N horizontal parts and then recombine the result to
get the full frame.

the number 4 is more like having to render 24 frames to make 1 second
of an animation, you divide the rendering, but you get 24 different
results, you don't have to combine them later*

* except if you want to make a video, maybe this is not a good example
after all :D