5 ms·

Can you explain more instead of linking a paper? I felt like the definitions were alright. > Asynchrony: the possibility for tasks to run out of order and stil

by tines 1y ago

Can you explain more instead of linking a paper? I felt like the definitions were alright. > Asynchrony: the possibility for tasks to run out of order and still be correct. > Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching. > Parallelism: the ability of a system to execute more than one task simultaneously at the physical level.

deleted 1y ago
[deleted]
threatofrain 1y ago
Concurrency is the property of a program to be divided into partially ordered or completely unordered units of execution. It does not describe how you actually end up executing the program in the end, such as if you wish to exploit these properties for parallel execution or task switching. Or maybe you're running on a single thread and not doing any task switching or parallelism. For more I'd look up Rob Pike's discussions for Go concurrency.
- tines 1y ago
  The article understands this.
  - threatofrain 1y ago
    > Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching. Okay, but don't go with this definition.
    - michaelsbradley 1y ago
      Is the hang up on "at a time"? What if that were changed to something like "in a given amount of time"? For single threaded programs, whether it is JS's event loop, or Racket's cooperative threads, or something similar, if Δt is small enough then only one task will be seen to progress.
andsoitis 1y ago
> Asynchrony: the possibility for tasks to run out of order and still be correct. Asynchrony is when things don't happen at the same time or in the same phase, i.e. is the opposite of Synchronous. It can describe a lack of coordination or concurrence in time, often with one event or process occurring independently of another. The correctness statement is not helpful. When things happy asynchronously, you do not have guarantees about order, which may be relevant to "correctness of your program".
- w10-1 1y ago
  > The correctness statement is not helpful But... that's everything, and why it's included. Undefined behavior from asynchronous computing is not worth study or investment, except to avoid it. Virtually all of the effort for the last few decades (from super-scalar processors through map/reduce algorithms and Nvidia fabrics) involves enabling non-SSE operations that are correct. So yes, as an abstract term outside the context of computing today, asynchrony does not guarantee correctness - that's the difficulty. But the only asynchronous computing we care about offers correctness guarantees of some sort (often a new type, e.g., "eventually consistent").
Lichtso 1y ago
Concurrency is parallelism and/or asynchrony, simply the superset of the other two. Asynchrony means things happen out of order, interleaved, interrupted, preempted, etc. but could still be just one thing at a time sequentially. Parallelism means the physical time spent is less that the sum of the total time spent because things happen simultaneously.
- jrvieira 1y ago
  careful: in many programming contexts parallelism and concurrency are exclusive concepts, and sometimes under the umbrella of async, which is a term that applies to a different domain. in other contexts these words don't describe disjoint sets of things so it's important to clearly define your terms when talking about software.
  - merb 1y ago
    Yeah concurrency is not parallelism. https://go.dev/blog/waza-talk https://go.dev/blog/waza-talk
    - Lichtso 1y ago
      That is compatible with my statement: Not all concurrency is parallelism, but all parallelism is concurrency.
      - OkayPhysicist 1y ago
        What people mean by "concurrency is not parallelism" is that they are different problems. The concurrency problem is defining an application such that it has parts that are not causally linked with some other parts of the program. The parallelism problem is the logistics of actually running multiple parts of your program at the same time. If I write a well-formed concurrent system, I shouldn't have to know or care if two specific parts of my system are actually being executed in parallel. In ecosystems with good distributed system stories, what this looks like in practice is that concurrency is your (the application developers') problem, and parallelism is the scheduler designer's problem.
jkcxn 1y ago
Not the OP, but in formal definitions like Communicating Sequential Processes, concurrency means the possibility for tasks to run out of order and still be correct, as long as other synchronisation events happen
- gowld 1y ago
  Concurrency implies asynchrony (two systems potentially doing work at the same time withut waiting for each other), but the converse is not true. A single process can do work in an unordered (asynchronous) way.
  - Zambyte 1y ago
    Parallelism implies concurrency but not does not imply asynchrony.
ryandv 1y ago
They're just different from what Lamport originally proposed. Asynchrony as given is roughly equivalent to Lamport's characterization of distributed systems as partially ordered, where some pairs of events can't be said to have occurred before or after one another. One issue with the definition for concurrency given in the article would seem to be that no concurrent systems can deadlock, since as defined all concurrent systems can progress tasks. Lamport uses the word concurrency for something else: "Two events are concurrent if neither can causally affect the other." Probably the notion of (a)causality is what the author was alluding to in the "Two files" example: saving two files where order does not matter. If the code had instead been "save file A; read contents of file A;" then, similarly to the client connect/server accept example, the "save" statement and the "read" statement would not be concurrent under Lamport's terminology, as the "save" causally affects the "read." It's just that the causal relationship between two tasks is a different concept than how those tasks are composed together in a software model, which is a different concept from how those tasks are physically orchestrated on bare metal, and also different from the ordering of events..
- kazinator 1y ago
  The definition of asynchrony is bad. It's possible for asynchronous requests to guarantee ordering, such that if a thread makes two requests A and B in that order, asynchronously, they will happen in that order. Asynchrony means that the requesting agent is not blocked while submitting a request in order to wait for the result of that request. Asynchronous abstractions may provide a synchronous way wait for the asynchronously submitted result.
  - ryandv 1y ago
    > The definition of asynchrony is bad. It's possible for asynchronous requests to guarantee ordering, such that if a thread makes two requests A and B in that order, asynchronously, they will happen in that order. It's true that it's possible - two async tasks can be bound together in sequence, just as with `Promise.then()` et al. ... but it's not necessarily the case, hence the partial order, and the "possibility for tasks to run out of order". For example - `a.then(b)` might bind tasks `a` and `b` together asynchronously, such that `a` takes place, and then `b` takes place - but after `a` has taken place, and before `b` has taken place, there may or may not be other asynchronous tasks interleaved between `a` and `b`. The ordering between `a`, `b`, and these interleaved events is not defined at all, and thus we have a partial order, in which we can bind `a` and `b` together in sequence, but have no idea how these two events are ordered in relation to all the other asynchronous tasks being managed by the runtime.
amelius 1y ago
> Asynchrony: the possibility for tasks to run out of order and still be correct. Can't we just call that "independent"?
- skydhash 1y ago
  Not really. There may be some causal relations.
  - amelius 1y ago
    Can you give an example?
    - skydhash 1y ago
      Locks, scheduling,... That introduce some synchronicity and so some kind of order. But it's enforced on the system and not a required mechanism.
      - amelius 1y ago
        But if I run "ls" on a machine, and another user runs "ls" on the same machine, wouldn't you consider them independent, even though the OS uses all kinds of locks and what not under the hood?
ninetyninenine 1y ago
Doesn't multiple tasks at the same time make it simultaneous? I think there needs to be a stricter definition here. Concurrency is the ability of a system to chop a task into many tiny tasks. A side effect of this is that if the system chops all tasks into tiny tasks and runs them all in a sort of shuffled way it looks like parallelism.
sriram_malhar 1y ago
The phrase "multiple tasks at a time" is ill-defined, according to Lamport, because whose clock are you trusting. For lamport concurrent does not mean what it means to us colloquially or informally (like, "meanwhile"). Concurrency in Lamport's formal definition is only about order. If one task is dependent or is affected by another, then the first is ordered after the second one. Otherwise, they are deemed to be "concurrent", even if one happens years later or before.

by tines 1y ago

deleted 1y ago

[deleted]

threatofrain 1y ago

Concurrency is the property of a program to be divided into partially ordered or completely unordered units of execution. It does not describe how you actually end up executing the program in the end, such as if you wish to exploit these properties for parallel execution or task switching. Or maybe you're running on a single thread and not doing any task switching or parallelism. For more I'd look up Rob Pike's discussions for Go concurrency.

tines 1y ago
The article understands this.
- threatofrain 1y ago
  > Concurrency: the ability of a system to progress multiple tasks at a time, be it via parallelism or task switching. Okay, but don't go with this definition.
  - michaelsbradley 1y ago
    Is the hang up on "at a time"? What if that were changed to something like "in a given amount of time"? For single threaded programs, whether it is JS's event loop, or Racket's cooperative threads, or something similar, if Δt is small enough then only one task will be seen to progress.

andsoitis 1y ago

> Asynchrony: the possibility for tasks to run out of order and still be correct. Asynchrony is when things don't happen at the same time or in the same phase, i.e. is the opposite of Synchronous. It can describe a lack of coordination or concurrence in time, often with one event or process occurring independently of another. The correctness statement is not helpful. When things happy asynchronously, you do not have guarantees about order, which may be relevant to "correctness of your program".

w10-1 1y ago
> The correctness statement is not helpful But... that's everything, and why it's included. Undefined behavior from asynchronous computing is not worth study or investment, except to avoid it. Virtually all of the effort for the last few decades (from super-scalar processors through map/reduce algorithms and Nvidia fabrics) involves enabling non-SSE operations that are correct. So yes, as an abstract term outside the context of computing today, asynchrony does not guarantee correctness - that's the difficulty. But the only asynchronous computing we care about offers correctness guarantees of some sort (often a new type, e.g., "eventually consistent").

Lichtso 1y ago

Concurrency is parallelism and/or asynchrony, simply the superset of the other two. Asynchrony means things happen out of order, interleaved, interrupted, preempted, etc. but could still be just one thing at a time sequentially. Parallelism means the physical time spent is less that the sum of the total time spent because things happen simultaneously.

jrvieira 1y ago
careful: in many programming contexts parallelism and concurrency are exclusive concepts, and sometimes under the umbrella of async, which is a term that applies to a different domain. in other contexts these words don't describe disjoint sets of things so it's important to clearly define your terms when talking about software.
- merb 1y ago
  Yeah concurrency is not parallelism. https://go.dev/blog/waza-talk https://go.dev/blog/waza-talk
  - Lichtso 1y ago
    That is compatible with my statement: Not all concurrency is parallelism, but all parallelism is concurrency.
    - OkayPhysicist 1y ago
      What people mean by "concurrency is not parallelism" is that they are different problems. The concurrency problem is defining an application such that it has parts that are not causally linked with some other parts of the program. The parallelism problem is the logistics of actually running multiple parts of your program at the same time. If I write a well-formed concurrent system, I shouldn't have to know or care if two specific parts of my system are actually being executed in parallel. In ecosystems with good distributed system stories, what this looks like in practice is that concurrency is your (the application developers') problem, and parallelism is the scheduler designer's problem.

jkcxn 1y ago

Not the OP, but in formal definitions like Communicating Sequential Processes, concurrency means the possibility for tasks to run out of order and still be correct, as long as other synchronisation events happen

gowld 1y ago
Concurrency implies asynchrony (two systems potentially doing work at the same time withut waiting for each other), but the converse is not true. A single process can do work in an unordered (asynchronous) way.
- Zambyte 1y ago
  Parallelism implies concurrency but not does not imply asynchrony.

ryandv 1y ago

They're just different from what Lamport originally proposed. Asynchrony as given is roughly equivalent to Lamport's characterization of distributed systems as partially ordered, where some pairs of events can't be said to have occurred before or after one another. One issue with the definition for concurrency given in the article would seem to be that no concurrent systems can deadlock, since as defined all concurrent systems can progress tasks. Lamport uses the word concurrency for something else: "Two events are concurrent if neither can causally affect the other." Probably the notion of (a)causality is what the author was alluding to in the "Two files" example: saving two files where order does not matter. If the code had instead been "save file A; read contents of file A;" then, similarly to the client connect/server accept example, the "save" statement and the "read" statement would not be concurrent under Lamport's terminology, as the "save" causally affects the "read." It's just that the causal relationship between two tasks is a different concept than how those tasks are composed together in a software model, which is a different concept from how those tasks are physically orchestrated on bare metal, and also different from the ordering of events..

kazinator 1y ago
The definition of asynchrony is bad. It's possible for asynchronous requests to guarantee ordering, such that if a thread makes two requests A and B in that order, asynchronously, they will happen in that order. Asynchrony means that the requesting agent is not blocked while submitting a request in order to wait for the result of that request. Asynchronous abstractions may provide a synchronous way wait for the asynchronously submitted result.
- ryandv 1y ago
  > The definition of asynchrony is bad. It's possible for asynchronous requests to guarantee ordering, such that if a thread makes two requests A and B in that order, asynchronously, they will happen in that order. It's true that it's possible - two async tasks can be bound together in sequence, just as with `Promise.then()` et al. ... but it's not necessarily the case, hence the partial order, and the "possibility for tasks to run out of order". For example - `a.then(b)` might bind tasks `a` and `b` together asynchronously, such that `a` takes place, and then `b` takes place - but after `a` has taken place, and before `b` has taken place, there may or may not be other asynchronous tasks interleaved between `a` and `b`. The ordering between `a`, `b`, and these interleaved events is not defined at all, and thus we have a partial order, in which we can bind `a` and `b` together in sequence, but have no idea how these two events are ordered in relation to all the other asynchronous tasks being managed by the runtime.

amelius 1y ago

> Asynchrony: the possibility for tasks to run out of order and still be correct. Can't we just call that "independent"?

skydhash 1y ago
Not really. There may be some causal relations.
- amelius 1y ago
  Can you give an example?
  - skydhash 1y ago
    Locks, scheduling,... That introduce some synchronicity and so some kind of order. But it's enforced on the system and not a required mechanism.
    - amelius 1y ago
      But if I run "ls" on a machine, and another user runs "ls" on the same machine, wouldn't you consider them independent, even though the OS uses all kinds of locks and what not under the hood?

ninetyninenine 1y ago

Doesn't multiple tasks at the same time make it simultaneous? I think there needs to be a stricter definition here. Concurrency is the ability of a system to chop a task into many tiny tasks. A side effect of this is that if the system chops all tasks into tiny tasks and runs them all in a sort of shuffled way it looks like parallelism.

sriram_malhar 1y ago

The phrase "multiple tasks at a time" is ill-defined, according to Lamport, because whose clock are you trusting. For lamport concurrent does not mean what it means to us colloquially or informally (like, "meanwhile"). Concurrency in Lamport's formal definition is only about order. If one task is dependent or is affected by another, then the first is ordered after the second one. Otherwise, they are deemed to be "concurrent", even if one happens years later or before.