> Even a sequential implementation can produce different results if the requests arrive in different order. I never said that the withdrawal requests must be s

> 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.