On Sun, May 13, 2012 at 8:31 PM, Steven D'Aprano <st...@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 _______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: http://mail.python.org/mailman/listinfo/tutor