3 ms·

"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way t

"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. One really bad way to do this is to have the timeslicing granule be computations of unbounded length with no preemption. I agree with you that it's valid to refer to event loops as a kind of concurrency. I would call it a very primitive and low-quality kind of concurrency. But it's not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time. He's implying that if you run things at the same time then it's called parallelism. That's just not true. It's still called concurrency, even though it could also be called parallelism in the right circumstances. I think it's best to understand this terminology this way: Concurrency: the phenomenon of two things happening at the same time, or being made to appear that way. Parallelism: the study of how to make things run to completion in less time by using multiple CPUs or computers.

Jtsummers 9y ago
I'll generally agree with your definitions for concurrency and parallelism. Our parallelism definitions were essentially the same. But what you say about coldtea is not a fair interpretation of their post. millstone said this: The event loop doesn't allow you to do a computation concurrently with handling user events, so it's not at all a proper concurrency model. By this definition, concurrency is only occurring when two things happen simultaneously. coldtea is correct that that is parallelism. Parallelism, and coldtea's comment does not exclude this, is a special case of concurrency. It is the case where a program's components execute simultaneously. Whereas, generally, concurrency in CS does not require simultaneous action (as you state in your definition).
- millstone 9y ago
  That's not the definition I had in mind. What I meant is that JavaScript lacks an easy way to allow for computation that doesn't block the event loop. We can imagine an old school cooperative multithreading architecture: for (var i = 0; i < arr.length; i++) { someCalculation(arr[i]); yieldToNextEvent(); } but JavaScript does not support this. Instead you have to awkwardly re-structure your computation in CPS or an equivalent to do this sort of thing.
  - Sacho 9y ago
    I don't think that's the fault of JavaScript - it does not specify the event loop itself. ES6 has generators, so all you need is an enqueue(fn*(){}). There's already an enqueue in the browser - setTimeout(), and one in node - nextTick(), so all the functionality you need is there.
dragonwriter 9y ago
In the context of computing, I prefer to simplify to: Concurrency: Having more than one linear sequence of instructions logically active at the same time. Parallelism: Having more than one instruction physically being executed at the same time.
coldtea 9y ago
>"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. For one, the CS literature defines concurrency as not necessarily being at the same time. Second, timeslice, by definition, is not at the same time. Hence the need to use quotes there. Concurrently does not mean "at the same time" any more than "timeslice" implies. >But it's not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time. I never claimed that. I wrote that concurrency is not parallelism (which it isn't), not that it excludes parallelism. Basic timeslicing (baring any other mechanism) for example is concurrent but not parallel. Node's evented "cooperative" concurrency is also not parallel.
- pizlonator 9y ago
  Timeslicing makes it impossible for a program to accidentally discover that its threads or processes are not really running at the same time. For example, an infinite loop in one thread will not halt all other threads. To me, that’s concurrency. Event loops are not like that. They run tasks to completion before starting other tasks and indeed the whole point of how you leverage an event loop is to take advantage of the fact that other things don’t happen at the same time. I would prefer to say other things don’t happen concurrently, and you would have understood my meaning. It’s not correct to have used the word “parallel” in that context since my example only needs one CPU. I think it’s ok to think of event loop interleaving bugs as being concurrency bugs, but insisting that event loops are proper instance of concurrency is diluting the terminology too much IMO. Hence I much refer to use concurrency to mean the case where the interleaving granule is not under the programmer’s control.

Jtsummers 9y ago

I'll generally agree with your definitions for concurrency and parallelism. Our parallelism definitions were essentially the same. But what you say about coldtea is not a fair interpretation of their post. millstone said this: The event loop doesn't allow you to do a computation concurrently with handling user events, so it's not at all a proper concurrency model. By this definition, concurrency is only occurring when two things happen simultaneously. coldtea is correct that that is parallelism. Parallelism, and coldtea's comment does not exclude this, is a special case of concurrency. It is the case where a program's components execute simultaneously. Whereas, generally, concurrency in CS does not require simultaneous action (as you state in your definition).

millstone 9y ago
That's not the definition I had in mind. What I meant is that JavaScript lacks an easy way to allow for computation that doesn't block the event loop. We can imagine an old school cooperative multithreading architecture: for (var i = 0; i < arr.length; i++) { someCalculation(arr[i]); yieldToNextEvent(); } but JavaScript does not support this. Instead you have to awkwardly re-structure your computation in CPS or an equivalent to do this sort of thing.
- Sacho 9y ago
  I don't think that's the fault of JavaScript - it does not specify the event loop itself. ES6 has generators, so all you need is an enqueue(fn*(){}). There's already an enqueue in the browser - setTimeout(), and one in node - nextTick(), so all the functionality you need is there.

dragonwriter 9y ago

In the context of computing, I prefer to simplify to: Concurrency: Having more than one linear sequence of instructions logically active at the same time. Parallelism: Having more than one instruction physically being executed at the same time.

coldtea 9y ago

>"Concurrently" means "at the same time", both in English and in CS. One way to make it appear as if you have concurrency is to timeslice. For one, the CS literature defines concurrency as not necessarily being at the same time. Second, timeslice, by definition, is not at the same time. Hence the need to use quotes there. Concurrently does not mean "at the same time" any more than "timeslice" implies. >But it's not at all valid to claim, as @coldtea seems to be doing, that concurrency excludes the notion of two things happening at the same time. I never claimed that. I wrote that concurrency is not parallelism (which it isn't), not that it excludes parallelism. Basic timeslicing (baring any other mechanism) for example is concurrent but not parallel. Node's evented "cooperative" concurrency is also not parallel.

pizlonator 9y ago
Timeslicing makes it impossible for a program to accidentally discover that its threads or processes are not really running at the same time. For example, an infinite loop in one thread will not halt all other threads. To me, that’s concurrency. Event loops are not like that. They run tasks to completion before starting other tasks and indeed the whole point of how you leverage an event loop is to take advantage of the fact that other things don’t happen at the same time. I would prefer to say other things don’t happen concurrently, and you would have understood my meaning. It’s not correct to have used the word “parallel” in that context since my example only needs one CPU. I think it’s ok to think of event loop interleaving bugs as being concurrency bugs, but insisting that event loops are proper instance of concurrency is diluting the terminology too much IMO. Hence I much refer to use concurrency to mean the case where the interleaving granule is not under the programmer’s control.