I'm of the opinion that we chose the wrong term for concurrency. Concurrency means multiple things going on simultaneously, which is not what's happening with our version of it. Only one thing is happening at any given time, but the tasks are being multiplexed on a shared resource. Parallelism = concurrency, "concurrency" = multiplexing.
Maybe there's a more appropriate term than multiplexing, but I think that's certainly better than concurrency at describing it.
Yes that's true the terms are confusing but nevertheless it's important. For example having read through some of this book it's still not clear if this book involves parallelism, especially since the book compares itself to Python, which does not involve parallelism without running C extensions.
Data races and other race conditions are still present in concurrent systems without parallelism (of the actually executing at the same time sense, like with multiple cores). If they weren't, we wouldn't need most uses of mutexes and semaphores on single core processors. As the book gets into, concurrency is about multiple tasks that are arbitrarily interleaved with each other. That interleaving is why you can have data races and other errors even in a single core system.
Yes that's true and I was wrong to say otherwise. A data race can happen with preemptive multithreading on data whose size exceeds what the platform guarantees to access atomically, typically the word size.
A more accurate statement would be that parallelism introduces additional possibilities for data races than those possible from concurrent execution (without parallelism).
Robert van Renesse is a hugely respected distributed systems researcher with decades of influential publications, and is highly respected as a mentor in the community.
I'm sorry that you feel his contributions are meaningless because he hasn't caught up with the way that devops people talk about these things.
These docs fail to separate concurrency from parallelism. I would have expected more from something that comes out of a university.
How would a distinction between concurrency and parallelism benefit the modeling of program logic?
The programming language incorporates thread+locking mechanisms.
Parallelism introduces additional hazards such as data races, which are not present in concurrent code that lacks parallelism.
I'm of the opinion that we chose the wrong term for concurrency. Concurrency means multiple things going on simultaneously, which is not what's happening with our version of it. Only one thing is happening at any given time, but the tasks are being multiplexed on a shared resource. Parallelism = concurrency, "concurrency" = multiplexing.
Maybe there's a more appropriate term than multiplexing, but I think that's certainly better than concurrency at describing it.
Yes that's true the terms are confusing but nevertheless it's important. For example having read through some of this book it's still not clear if this book involves parallelism, especially since the book compares itself to Python, which does not involve parallelism without running C extensions.
Data races and other race conditions are still present in concurrent systems without parallelism (of the actually executing at the same time sense, like with multiple cores). If they weren't, we wouldn't need most uses of mutexes and semaphores on single core processors. As the book gets into, concurrency is about multiple tasks that are arbitrarily interleaved with each other. That interleaving is why you can have data races and other errors even in a single core system.
Data races are not possible on a single core system.
they are entirely possible assuming preemptive scheduling
Yes that's true and I was wrong to say otherwise. A data race can happen with preemptive multithreading on data whose size exceeds what the platform guarantees to access atomically, typically the word size.
A more accurate statement would be that parallelism introduces additional possibilities for data races than those possible from concurrent execution (without parallelism).
Robert van Renesse is a hugely respected distributed systems researcher with decades of influential publications, and is highly respected as a mentor in the community.
I'm sorry that you feel his contributions are meaningless because he hasn't caught up with the way that devops people talk about these things.
[dead]