[Tutor] threading mind set

[Devin Jeanpierre]

On Sun, May 13, 2012 at 8:31 PM, Steven D'Aprano <steve at pearwood.info> wrote:
>> Using processes and message passing, using dataflow, actors or CSP,
>> parallelism and concurrency is far more straightforward. Not easy,
>> agreed, but then programming isn't easy.
>
> My argument is that once you move beyond the one-operation-after-another
> programming model, almost any parallel processing problem is harder than the
> equivalent sequential version, inherently due to the parallelism. Except
> perhaps for "embarrassingly parallel" problems, parallelism adds complexity
> even if your framework abstracts away most of the tedious detail like
> semaphores.

If you agree that embarrassingly parallel multithreaded frameworks are
easy, what do you think of dataflow programming? It is exactly the
same, except that you can have multiple tasks, where one task depends
on the output of a previous task. It shares the property that it makes
no difference in what order things are executed (or sequential vs
parallel), so long as the data dependencies are respected -- so it's
another case where you don't actually have to think in a
non-sequential manner. (Rather, think in a "vectorized" per-work-item
manner.)

http://en.wikipedia.org/wiki/Dataflow_programming

It should be clear that not all ways of programming multithreaded code
are equal, and some are easier than others. In particular, having
mutable state shared between two concurrently-executing procedures is
phenomenally hard, and when it's avoided things become simpler.

-- Devin