4 ms·

Hmm, that's a fair point. Thinking about it a bit more, I think my definitions fit closer with the idea of concurrent or parallel programs rather than the abstr

by 14113 12y ago

Hmm, that's a fair point. Thinking about it a bit more, I think my definitions fit closer with the idea of concurrent or parallel programs rather than the abstract ideas of concurrency or parallelism themselves. In any case, I completely disagree with your idea that parallel systems must be concurrent. Concurrency arises completely due to the interactions between separate threads of execution, whether they be executing at the same time on separate processors, or scheduled one after the other on a single processor. This is why we have various process calculii (csp, pi-calculus etc), and things such as session types, in order to try and reason about it and manage it. Parallelism assumes nothing about the interactions between processes, only that they are assumed to be running on separate hardware. As another poster mentioned, this fits fairly well with what the Haskell, Go, and general programming language research community considers to be the definitions of concurrency and parallelism. Look at any paper that focusses on concurrency, and you'll see it's about managing and making safe communication between separate processes. Look at a paper on parallelism, and it'll be on accelerating a parallelisable program on multicore or distributed hardware.

scott_s 12y ago
As someone who works in parallel and distributed systems (which means I write and read papers on parallelism), I find your distinction an empty one. Actually getting good performance from parallelism requires careful consideration of the synchronization between the parallel parts - and in my work, the "careful consideration" is usually done by me. My goal is often to make abstractions so that users don't have to implement or even reason about such synchronization themselves, but it's still a central part of the work. I also disagree with your assertion that the programming language research community disagrees with my definitions - I'm more of a systems person, but I do end up in their playground sometimes.

by 14113 12y ago

scott_s 12y ago

As someone who works in parallel and distributed systems (which means I write and read papers on parallelism), I find your distinction an empty one. Actually getting good performance from parallelism requires careful consideration of the synchronization between the parallel parts - and in my work, the "careful consideration" is usually done by me. My goal is often to make abstractions so that users don't have to implement or even reason about such synchronization themselves, but it's still a central part of the work. I also disagree with your assertion that the programming language research community disagrees with my definitions - I'm more of a systems person, but I do end up in their playground sometimes.