3

I've read that Node.js offers concurrency based on the event loop. But doesn't concurrency mean that something is happening simultaneously? The event loop is there because it processes bits of code to execute one after the other and not concurrently.

For instance Alexandru writes this in his tutorial on Node.js (https://www.airpair.com/javascript/node-js-tutorial)

Node is single-threaded and uses a concurrency model based on an event loop. It is non-blocking, so it doesn't make the program wait, but instead it registers a callback and lets the program continue. This means it can handle concurrent operations without multiple threads of execution, so it can scale pretty well.

Is there or is there no concurrency in JavaScript? My thought was that only Web Workers enable concurrency in JavaScript, is it possible by other means on the frontend or backend?

Larry Lawless
  • 613
  • 6
  • 11
  • 2
    There is a subtle, yet important distinction between *concurrent* and *parallel*. Javascript is traditionally concurrent but not parallel. – JonSG Nov 14 '16 at 13:37
  • @JonSG - what is the distinction between parallel and concurrent? – Ben Aston Nov 14 '16 at 13:38
  • 1
    @BenAston check out http://stackoverflow.com/questions/1050222/concurrency-vs-parallelism-what-is-the-difference – JonSG Nov 14 '16 at 13:40
  • 1
    Web Workers are a separate browsing context from the page that spawns them. In terms of simultaneous execution, workers are no different from running scripts in two different tabs in your browser. (To what degree that will actually result in parallel execution depends on how your browser handles multiple pages running scripts all at once.) – apsillers Nov 14 '16 at 13:40

2 Answers2

1

Userland program control flow is single-threaded in JavaScript.

If concurrency is having two tasks cooperatively move towards completion within the same time period, then yes, you can achieve this in JavaScript by implementing your own scheduler.

To leverage native functionality you can use generators to create co-routines.

Some asynchronous activities can be offloaded via APIs provided by the host environment (e.g. setTimeout/window.fetch). In this way the host environment is supporting concurrent behavior, but this functionality is not part of the JavaScript language specification.

Finally, the language spec defines Promise behavior which might define some asynchronous behavior (I haven't read the spec closely, I know implementations do use "microtasks") thus enabling native concurrency.

But your userland code remains single threaded, and continuations are merely scheduled for execution on the single thread of execution at the appropriate time.

If parallelism is a subset of concurrency in which the running tasks are "more independent and non-cooperating", then this is achievable by via WebWorkers and the spinning up of other JS runtimes IIUC.

Ben Aston
  • 53,718
  • 65
  • 205
  • 331
0

If you look at the wiki definition of "concurrency":

In computer science, concurrency is the decomposability property of a program, algorithm, or problem into order-independent or partially-ordered components or units.

it actually is concurrent, because concurrency is only the "decomposability" property of a program.

But probably you mean if you can execute code in a parallel fashion.

Let's ignore the various parallel extensions (WebWorkers, ...).

The answer is that the JS code is only single threaded and so there is no "concurrency" (as per your meaning), but the code called by js api can be multithreaded/async. For example the XmlHttpRequests requests run in their own thread and they are triggered from JS code and they could run at the same time as your JS code.

aghidini
  • 2,855
  • 5
  • 29
  • 32