4 ms·
In my opinion the article is somewhere between missing the point and plain wrong. Concurrency is a property of a set of tasks describing dependencies among the
by danbruc 14y ago
In my opinion the article is somewhere between missing the point and plain wrong.
Concurrency is a property of a set of tasks describing dependencies among these tasks. Think of it as a graph with a vertex for each task and an directed edge between two tasks if one task depends on the other tasks result. Two tasks are concurrent if there is no dependency between them. Concurrent task can be executed in parallel, but do not have to. Two non-concurrent tasks can not be executed in parallel,
Parallelism occurs during runtime when independent task are actually executed at the same time (no matter if you do this on two cores or if you are just interleaving the execution of both tasks on one core). Executing two tasks in parallel requires that these two tasks are concurrent.
Example
Two (read-only) web requests are concurrent because there are no dependencies between them. Each web request consists of some subtasks like parsing the request, querying the database, performing some business logic and building and sending the response. These subtasks are not concurrent because each one depends on the result of the one before.
There are now (at least) two options for processing these both web requests - one after the other or both in parallel. In the first case you ignore the concurrency between both web request, in the second case you exploit the concurrency between both web request by parallelizing their execution.
So IMHO there is no choice between concurrency and parallelism. Concurrency is a property of the system you are building (and there is not much you can do in order to add or remove concurrency). You then have a choice to introduce parallelism to exploit concurrency or you just ignore cocurreny, but that's it.
- CodyBoppert 14y agoWonderful explanation. Thanks.
- _yosefk 14y agoOK, so how come Rob Pike calls his own Sawzall language parallel but not concurrent? I presented your way of looking at it in the article more than once and I said it was valid, just not the only one; then several comment threads emerge reiterating that view, more or less wrongly, and arguing that it's got to be the one and only way of looking at it. Sigh.
- danbruc 14y agoIMHO - and I may of course be wrong - there are (widely) accepted definitions for concurrency and parallelism in the computer science community and in my comment I tried to present them as good as I could (but the comment is far from being flawless). Assuming I am correct with the previous sentence, there is no way of interpreting concurrency and parallelism this way or another because the terms are fixed by their definition. You can of course look at their relationship from different angels and highlight or ignore different aspects in different situations but this does not change their basic relationship or even definition. I can think of two reasons why one would call a language parallel but no concurrent. First this could obviously happen because somebody is not aware of the meaning of the concepts or uses the words in a non-standard way but I think this is probably not the case - I would be surprised if one designs a concurrent/parallel language and does not know the distinction. My best guess is that the intended meaning of the statement is, that the language is no good for general concurrent task but well suited for SIMD-like concurrent tasks, that is running the some operations on multiple different inputs in parallel. (I have to admit that I know nothing about Sawzall and did not invest any time to figure this out, just guessing.)