I think that Wikipedia claim is predicated on 'same result' for originally partially ordered results. Even a sequential implementation can produce different results if the requests arrive in different order.
> Parallel tasks cooperate towards a common goal. Concurrent tasks compete for access to common resources.
This definition is interesting, but I think it lack descriptive power: are web server tasks parallel as they are all contributing at fulfilling the incoming client request queue? Are threads of a matrix multiplication process concurrent as they compete for access to the cpu?
It also misses the whole reason for parallelism which is speed-up (by a constant) of execution.
Anyway, to go full circle, I stand by my assertion that async can be all about parallelism.
[BTW, this has been a great conversation, sometimes one need to put their thought in writing to actually fully understand them]
> Even a sequential implementation can produce different results if the requests arrive in different order.
I never said that the withdrawal requests must be served in the same exact order they were received. This may or may not be the case.
> are web server tasks parallel as they are all contributing at fulfilling the incoming client request queue?
At the highest level of abstraction, they're concurrent. The client request queue is a low-level implementation detail, and a high-level language could well hide it from you. (Yes, this means that people often do unnecessarily low-level programming, even when using so-called “high-level languages”.)
>> Parallel tasks cooperate towards a common goal. Concurrent tasks compete for access to common resources.
> This definition is interesting, but I think it lack descriptive power
Those particular sentences weren't definitions. The actual definitions were what I said a few comments earlier: “Parallelism and concurrency are fundamentally different things. Parallelism is running independent computations simultaneously. Concurrency control is managing the use of shared resources by temporarily granting exclusive access to them to individual computations.”
> It also misses the whole reason for parallelism which is speed-up (by a constant) of execution.
It doesn't. If there is only one goal, then the only possible point to splitting a computation into parallel subcomputations can be to speed up the global computation.
>> Even a sequential implementation can produce different results if the requests arrive in different order.
>I never said that the withdrawal requests must be served in the same exact order they were received. This may or may not be the case.
My point is if there is no ordering in the first place, there is no ordering to be preserved.
> Parallelism is running independent computations simultaneously. Concurrency control is managing the use of shared resources by temporarily granting exclusive access to them to individual computations.”
Concurrency is simply the situation where two or more processes need exclusive access to a shared resource, so it's fair to say that, whenever there's concurrency, there's a need for concurrency control.
> Parallel tasks cooperate towards a common goal. Concurrent tasks compete for access to common resources.
This definition is interesting, but I think it lack descriptive power: are web server tasks parallel as they are all contributing at fulfilling the incoming client request queue? Are threads of a matrix multiplication process concurrent as they compete for access to the cpu?
It also misses the whole reason for parallelism which is speed-up (by a constant) of execution.
Anyway, to go full circle, I stand by my assertion that async can be all about parallelism.
[BTW, this has been a great conversation, sometimes one need to put their thought in writing to actually fully understand them]