[erlang-questions] How to Name Concurrency Patterns

Richard A. O'Keefe ok@REDACTED
Thu Feb 20 22:03:56 CET 2014


On 20/02/2014, at 8:58 PM, Ulf Wiger wrote:

> Perhaps it should be called "concurrency-oriented patterns" instead? Strictly speaking, a pipe isn't about concurrency so much as serialization/chaining (and can be executed without any concurrency at all),

Well, UNIX pipelines are a good way to introduce the issues of
 - unbounded buffer -vs- bounded buffer
 - multiple reads and/or multiple writers
   (two or more concurrent processes can write to the same pipe,
   chunks smaller than PIPE_BUF -- somewhat misleadingly named --
   are atomic, bigger chunks maybe interleaved)
   (two or more concurrent processes can read from a pipe;
   presumably PIPE_BUF also applies to reading although I've
   never seen this stated)
 - flow control
 - why popen(cmd, mode) allows mode = "r" and "w" but not "r+" or "w+"

> A pattern I don't see mentioned often is what I might call 'orchestrator', where one process is assigned the responsibility for the overall 'script', dispatches tasks to workers and collects the results.

Turns out that's a sequential OOP pattern:
http://codereview.stackexchange.com/questions/25435/sequential-execution-orchestrator-pattern

Where do you draw the line (or indeed, is there any point in
drawing a line) between this and Master/Worker?

> I would say that pmap() is a simple orchestrator pattern, and a good opportunity to explain both supervision and selective receive.

pmap is a simple master/worker case where all the workers are
doing the same kind of job.






More information about the erlang-questions mailing list