The "parallelism vs concurrency" distinction is one of those pedantic distinctions that confuses people. It's right up there with "A Monad is Like A Burrito" or an old definition of object oriented programming that still exists on programming splogs and the occasional job interview.
It's not unusual for a parallel job to be done by slicing a job into a large set of tasks and then farming it out to some execution framework that concurrently runs those tasks. That framework could be also concurrently running tasks that come from other jobs, parallel or not. The key thing is that the task runner has no idea and needs to have no idea about which tasks are part of which parallel job. (e.g. this is the case with feeding tasks into an executor, Hadoop, dask, and many different frameworks)
When you look at a real system you tend to find parallel and concurrent concepts working hand-in-hand.
1 comment
[ 2.5 ms ] story [ 9.4 ms ] threadThe "parallelism vs concurrency" distinction is one of those pedantic distinctions that confuses people. It's right up there with "A Monad is Like A Burrito" or an old definition of object oriented programming that still exists on programming splogs and the occasional job interview.
It's not unusual for a parallel job to be done by slicing a job into a large set of tasks and then farming it out to some execution framework that concurrently runs those tasks. That framework could be also concurrently running tasks that come from other jobs, parallel or not. The key thing is that the task runner has no idea and needs to have no idea about which tasks are part of which parallel job. (e.g. this is the case with feeding tasks into an executor, Hadoop, dask, and many different frameworks)
When you look at a real system you tend to find parallel and concurrent concepts working hand-in-hand.