[erlang-questions] Re: Classification of concurrency patterns

[Guy Wiener]

IMHO we need to distinguish between two things: Dependencies and Resources.

Dependencies in a pattern describe the process topology under optimal
circumstances.  For example, in pmap, there is no dependency between the
processes. In a pipe, each process depends on the previous. In a star,
processes depend on a central, long-running process, etc.

Resources, as Joe and Geoff mentioned, describe what is available to the
application - Namely, the number of processors and their network topology.

The actual instance of the application is the combination: Assigning
available resources according to the dependencies. Sometime there are
un-used processes (for example, if the pipe is shorter then the available
processors). Sometimes the actual assignment is less then the optimal (for
example, if there are more independent processes then available processors).

Guy.

On Tue, May 18, 2010 at 12:54 PM, Geoffrey Biggs
<geoffrey.biggs@REDACTED>wrote:

> On 18/05/10 18:46, Joe Armstrong wrote:
> > There's no point in expressing the concurrency in an algorithm if the
> > hardware can't do it anyway
> > (or perhaps there is?)
>
> I believe there is. It may not be directly applicable to hardware now,
> but it has a high chance of being applicable at some point in the
> future. Just make sure it's *implementable* now, even if we don't get
> all the benefits that having native hardware support would give, like
> true concurrency.
>
> The catch here is that your example of pmap breaking into different
> sizes depending on the number of cores is the anti-thesis of what a
> pattern should be. It's specifying implementation details. I think that
> the patterns should be more abstract than "the task is split up 4 times"
> - a better description is "the task is split up n times," with n
> determined by the pattern user for their specific needs - hopefully
> based on some benchmarking.
>
> Geoff
>
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>