[erlang-questions] How to Name Concurrency Patterns

[Pieter Hintjens]

Messaging patterns are not always the same as concurrency patterns, IMO.

The main concurrency patterns I've seen are:

- one ventilator sending jobs to multiple identical workers, with
results coming back to one sink (map-reduce, possibly)
- multiple clients talking to one broker talking to multiple service
workers (service oriented architecture)
- asynchronous objects, where each object is an independent actor
thread (typical in some APIs)
- full cluster, with each node connected to each other node
- multiple listeners receiving information and then sending requests
back to central services (e.g. stock trading platform)

And the main messaging patterns are:

- information distribution (publish-subscribe)
- workload distribution (many variations)

The ZeroMQ Guide has a whole set of patterns with names, including
reliability patterns.


On Wed, Feb 19, 2014 at 11:10 PM, Joe Armstrong <erlang@REDACTED> wrote:
> Very Nice
>
> More like this please.
>
> /Joe
>
>
> On Wed, Feb 19, 2014 at 11:08 PM, Dmitry Kolesnikov <dmkolesnikov@REDACTED>
> wrote:
>>
>> Hello,
>>
>> Long time ago, I was looking into async message queue patters.
>> I found namomsg tutorial is very nice it depicts most common patterns
>> http://tim.dysinger.net/posts/2013-09-16-getting-started-with-nanomsg.html
>>
>>
>>
>> Best Regards,
>> Dmitry
>> >-|-|-(*>
>>
>> > On 19 Feb 2014, at 23:14, Joe Armstrong <erlang@REDACTED> wrote:
>> >
>> >
>> >
>> > Hello, I'm giving a course in distributed and parallel programming in
>> > Erlang ...
>> >
>> > Next week I'll be talking about common concurrency patterns, I was
>> > talking with the course adviser, and I rattled off the names of a few
>> > concurrency patterns that were well-known and easy to explain. I said
>> > I'll do PUB-SUB, pipeline, map-reduce, parallel map, and so on.
>> >
>> > At this stage the course adviser said that a) things like PUB-SUB
>> > would not be familiar to the students and that b) It would take more
>> > than 5-10 minutes to explain PUB_SUB.
>> >
>> > At this stage I thought "pity these patterns don't have well-known
>> > names".
>> >
>> > What I'd like is to make a catalog of "well-known" concurrency
>> > patterns.  I'd like to name them, and describe them informally, and
>> > give the example code in Erlang.
>> >
>> > For example, here's how I might describe PUB-SUB.
>> >
>> > == PUB-SUB
>> >
>> >    - There are a number of named channels
>> >    - You can post messages to a channel ie Publish the message (the PUB)
>> >    - You can subscribe to a channel (The SUB)
>> >    - If you are currently subscribed to a channel you will be sent all
>> > messages
>> >      sent to the channel.
>> >
>> > A rudimentary version of this is about 25 lines of Erlang. A full
>> > version with load balancing, removing bottlenecks etc. would be a lot
>> > longer, but that's not the point. The basic concurrent structure can
>> > be explained in a few lines and named.
>> >
>> >
>> > Pipeline is another example: The output of the first process is the
>> > input to the next process and so on...
>> >
>> > Now I start having problems.
>> >
>> > Suppose I want to generalize a regular map.
>> >
>> > To be precise. Suppose map(F, L) means [F(I) || I <- L]
>> >
>> > pmap(F, L) is parallel map (easy) all the F(I)'s are computed
>> > concurrently.
>> >
>> > pmap(F, L, Max) behaves like map(F,L) with at most Max F(I)'s computed
>> > concurrently.
>> >
>> > What should this be called? "Pool of workers"
>> >
>> > There seem to be things with well-known names "Load-balancer"
>> > "map-reduce" etc.
>> >
>> > Then there are things that we know of but that are not named. For
>> > example my DNS resolver has two DNS names DNS1 and DNS2.  If DNS1 is
>> > broken the resolver tries DNS2 - what is concurrency pattern called
>> > (Pool of responders) or what?
>> >
>> > The other day I suggested that for fault tolerance it was much easier
>> > to let the client go to multiple machines rather than use an expensive
>> > load balancer and fail-over system on the server - but there was no
>> > convenient name to capture this idea.
>> >
>> > There sees to be no accepted terminology here - so I'd appreciate any
>> > suggestions you have as to the names of common currency patterns that
>> > you use together with definitions of what the names mean.
>> >
>> > Cheers
>> >
>> > /Joe
>> >
>> > _______________________________________________
>> > erlang-questions mailing list
>> > erlang-questions@REDACTED
>> > http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>