4 ms·

> "concurrency", nowadays, refers to the apparatus and overhead involved in coordinating parallel activity Are you saying "highly concurrent" would mean "lots

> "concurrency", nowadays, refers to the apparatus and overhead involved in coordinating parallel activity Are you saying "highly concurrent" would mean "lots of unnecessary overhead"? I strongly dispute that is the widely accepting meaning. My understanding of concurrency vs parallelism (this is also the definition implicit in the article): * Parallel: n processes running on n physical processors * Concurrent: n processes running on m≤n (possibly m=1) physical processors due to preemptive or cooperative multitasking (the latter is common in async frameworks). (Edit: Changed m<n to m≤n. To be clear: parallelism is a type of concurrency.) A system with a lot of concurrency might not have any parallelism but still have less overhead than a parallel system e.g. in the case the processes are IO bound rather than CPU bound and need to communicate between each other a lot.

deleted 6y ago
[deleted]
loopz 6y ago
Concurrency - computer science: In computer science, concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome. This allows for parallel execution of the concurrent units, which can significantly improve overall speed of the execution in multi-processor and multi-core systems. - Wikipedia If you start delving into how, you quickly lose the overall meaning of the concept over to specific implementations.
- kqr 6y ago
  This is indeed it. Concurrency is a design/architecture concern. It's a property of the code: are parts of it independent of time with respect to each other so that they can execute out of order (including interleaved in time slices.) Parallelism is a run-time concern. Are parts of the code executing literally simultaneously?
- quietbritishjim 6y ago
  That confirms my point that "concurrency" doesn't mean anything close to what the grandparent comment says, which claimed the concurrency is to do with overhead of parallelisation. What's more, it all mostly agrees with what I was saying. Look at this bit in particular: > This allows for parallel execution of the concurrent units Notice how it uses "parallel" to mean that the concurrent units (to use the quoted terminology) are actually executing at the same time, exactly as my previous comment says. OK, it avoided talking about "physical processors" or "cores", but that's what this boils down to on practical digital computers. Maybe the wording in my last comment wasn't 100% perfect, and there are some slight differences on details (e.g. the quoted Wikipedia text only seems concerned with processing-bound units of execution, not IO-bound waiting) but it's clearly talking about the same two definitions.
ncmncm 6y ago
Terminology is often not adopted universally and immediately. But different concepts need different terms. Yours also need different terms. We will find out eventually what the world decides things will be called.
- quietbritishjim 6y ago
  I absolutely get that (and get that not everyone does). Meanings evolve over time. Or are understood to mean different things to different people (an example I like is the almost opposing meanings of "implies" between mathematicians and mainstream English speakers). You can even use words to mean something different from the usually-accepted meaning, so long as you're clear about your own definitions up front. But you specifically claimed that your definition of "concurrency" is the main accepted one: > "concurrency", nowadays, refers to ... > ... it appears to have stabilized This is the part I disagree with. My understanding of the word "concurrency", the Wikipedia definition that someone quoted, and the meaning in the article all align, and are all different from the meaning you gave (if I haven't misunderstood it, which admittedly is very possible). So it seems very unlikely to me that we all hold the minority understanding while yours is the mainstream.
  - ncmncm 6y ago
    I am just reporting what I observe in usage in, e.g. SG1 working group of the ISO C++ Standard committee. Parallelism is an abstract behavior to be sought for, but concurrency is about code or apparatus to manage, enable, or coordinate it.
amelius 6y ago
> cooperative multitasking (the latter is common in async frameworks) ... and is also how Windows 3.1 worked.
- guenthert 6y ago
  Or MacOS before OSX or Oberon or Amiga OS or how multitasking was typically implemented in FORTH or ...
  - gpderetta 6y ago
    Actually Amiga OS was fully preemptive. What it did lack was memory protection and any clear distinction between kernel and userspace.
    - guenthert 6y ago
      You're right. I do remember now having discussed that more than 30 years ago with someone who actually owned an Amiga then. I also remember my puzzlement when I learned that Oberon chose to support only cooperative scheduling which seemed like a step back then already.
  - amelius 6y ago
    Yes, since then we've moved away from cooperative multitasking, especially in cases where we needed low latency, such as in UIs. It is therefore a bit strange that the pattern has resurfaced lately, and has been heavily used in the implementation of UIs and webservers ... You could argue that in small systems (compared to OSes), you can keep latency under control, but systems tend to grow, and modularity of the systems works against this (modules don't need to know what other modules do or how long they take to finish their tasks).
    - imtringued 6y ago
      Cooperative multithreading has lower overhead and latency than preemptive multithreading. I don't know what you are talking about. The problem with cooperative multithreading is that you have to yield manually which is a disaster for scheduling random applications but not a problem when used inside a single application where it is isolated from everything else.

deleted 6y ago

[deleted]

loopz 6y ago

Concurrency - computer science: In computer science, concurrency is the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome. This allows for parallel execution of the concurrent units, which can significantly improve overall speed of the execution in multi-processor and multi-core systems. - Wikipedia If you start delving into how, you quickly lose the overall meaning of the concept over to specific implementations.

kqr 6y ago
This is indeed it. Concurrency is a design/architecture concern. It's a property of the code: are parts of it independent of time with respect to each other so that they can execute out of order (including interleaved in time slices.) Parallelism is a run-time concern. Are parts of the code executing literally simultaneously?
quietbritishjim 6y ago
That confirms my point that "concurrency" doesn't mean anything close to what the grandparent comment says, which claimed the concurrency is to do with overhead of parallelisation. What's more, it all mostly agrees with what I was saying. Look at this bit in particular: > This allows for parallel execution of the concurrent units Notice how it uses "parallel" to mean that the concurrent units (to use the quoted terminology) are actually executing at the same time, exactly as my previous comment says. OK, it avoided talking about "physical processors" or "cores", but that's what this boils down to on practical digital computers. Maybe the wording in my last comment wasn't 100% perfect, and there are some slight differences on details (e.g. the quoted Wikipedia text only seems concerned with processing-bound units of execution, not IO-bound waiting) but it's clearly talking about the same two definitions.

ncmncm 6y ago

Terminology is often not adopted universally and immediately. But different concepts need different terms. Yours also need different terms. We will find out eventually what the world decides things will be called.

quietbritishjim 6y ago
I absolutely get that (and get that not everyone does). Meanings evolve over time. Or are understood to mean different things to different people (an example I like is the almost opposing meanings of "implies" between mathematicians and mainstream English speakers). You can even use words to mean something different from the usually-accepted meaning, so long as you're clear about your own definitions up front. But you specifically claimed that your definition of "concurrency" is the main accepted one: > "concurrency", nowadays, refers to ... > ... it appears to have stabilized This is the part I disagree with. My understanding of the word "concurrency", the Wikipedia definition that someone quoted, and the meaning in the article all align, and are all different from the meaning you gave (if I haven't misunderstood it, which admittedly is very possible). So it seems very unlikely to me that we all hold the minority understanding while yours is the mainstream.
- ncmncm 6y ago
  I am just reporting what I observe in usage in, e.g. SG1 working group of the ISO C++ Standard committee. Parallelism is an abstract behavior to be sought for, but concurrency is about code or apparatus to manage, enable, or coordinate it.

amelius 6y ago

> cooperative multitasking (the latter is common in async frameworks) ... and is also how Windows 3.1 worked.

guenthert 6y ago
Or MacOS before OSX or Oberon or Amiga OS or how multitasking was typically implemented in FORTH or ...
- gpderetta 6y ago
  Actually Amiga OS was fully preemptive. What it did lack was memory protection and any clear distinction between kernel and userspace.
  - guenthert 6y ago
    You're right. I do remember now having discussed that more than 30 years ago with someone who actually owned an Amiga then. I also remember my puzzlement when I learned that Oberon chose to support only cooperative scheduling which seemed like a step back then already.
- amelius 6y ago
  Yes, since then we've moved away from cooperative multitasking, especially in cases where we needed low latency, such as in UIs. It is therefore a bit strange that the pattern has resurfaced lately, and has been heavily used in the implementation of UIs and webservers ... You could argue that in small systems (compared to OSes), you can keep latency under control, but systems tend to grow, and modularity of the systems works against this (modules don't need to know what other modules do or how long they take to finish their tasks).
  - imtringued 6y ago
    Cooperative multithreading has lower overhead and latency than preemptive multithreading. I don't know what you are talking about. The problem with cooperative multithreading is that you have to yield manually which is a disaster for scheduling random applications but not a problem when used inside a single application where it is isolated from everything else.