> Or is the sole distinction determinism vs non-determinism? How is non-determinism avoided in a parallel process (which, to my thinking, means a thread)? The

> Or is the sole distinction determinism vs non-determinism? How is non-determinism avoided in a parallel process (which, to my thinking, means a thread)? The distinction is much easier to understand in haskell because the language is expressive enough, but that blog post might have been too much information. Here's the standard haskell concurrency library: http://hackage.haskell.org/packages/archive/base/latest/doc/html/Control-Concurrent.html http://hackage.haskell.org/packages/archive/base/latest/doc/... It provides computations that can be forked on new threads, and primitives for communicating. The threads are scheduled by the runtime (non-deterministic semantics!) and I am free to write and run such a program on the single-core laptop in front of me (no parallelism!). In contrast take a look at Control.Parallel: http://hackage.haskell.org/packages/archive/parallel/latest/doc/html/Control-Parallel.html http://hackage.haskell.org/packages/archive/parallel/latest/... Here all the `par` function does is tell the runtime "it might be helpful to compute these in parallel" (parallelism!), but semantically `par x y` is simply `y` (the type or definition of `par` might not make sense to you, but that's not really important); there have been no new threads of control spawned (deterministic!). Now if I wanted to, I could write a library for a parallel function `map :: (a -> b) -> Array a -> Array b` say (parallelism!), and I might implement that in terms of the concurrency primitives from Control.Concurrent. I would consider that `map` to be an example of deterministic Parallelism, even though the implementation might be utilizing multiple non-deterministic threads of control (in the same way the `par` is parallelism despite being implemented on top of the runtime, OS/green threads, and all other sorts of magic.