3 ms·
Concurrency is when you have multiple threads of control. Parallelism is when you are doing more than one thing at the same time. Multiple threads of control m
by thirsteh 14y ago
Concurrency is when you have multiple threads of control. Parallelism is when you are doing more than one thing at the same time.
Multiple threads of control may do things in parallel.
Another good explanation: http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/ http://ghcmutterings.wordpress.com/2009/10/06/parallelism-co...
- goostavos 14y agoYep.. I don't understand. Concurrency is not parallelism, yet.. parallelism requires concurrency...? I read through your linked article and didn't understand, I read through the linked article and... I still don't understand! >Now I can hear you object, but isn’t concurrency required to implement parallelism? Well, yes, it is, but concurrency is also required to implement sequentiality too! What am I missing here? Is parallelism just a well structured concurrency? 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)? From my Java/Python mind, the load balancer dispatcher/worker/channel-listener seemed very similar in construction to what you would do with a Thread (or Process) and a synchronized Queue. What makes one concurrent, and the other not? I suppose, my main question is, what prevents parallelism from not being non-deterministic?
- scott_s 14y agoConcurrency is a statement about a duration of time. Parallelism is a statement about a moment in time. During a one second window, did both of the tasks execute? If yes, then they are concurrent. If no, then they are not concurrent. Was there any moment in time when both tasks executing simultaneously? If yes, then they executed in parallel. If no, then they did not execute in parallel. From this, it's easy to see that if something is parallel, it must also be concurrent - in order for two tasks to execute during the same moment in time, they must also both have executed during a window of time. Concurrency without parallelism happens on machines with a single core. Processes and threads must time-share the only core. Frequently, some of these processes will have multiple threads, so the threads need to synchronize with each other, even though they don't execute at the same time. The definitions of concurrency and parallelism have nothing to do with determinism, so I don't know why others have brought it up. Concurrency and parallelism implies non-deterministic interleavings of threads and processes, but whether or not the result is deterministic is up to how we program.
- jberryman 14y ago> 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.