Hacker News Reader

Comment by vvcephei | Hacker News Reader

I hope this isn't too pedantic, but I wish the author would stay away from calling Node "concurrent". The whole point of Node is that it's asynchronous but not concurrent: there is a single thread of execution for your whole program, which is what lets you ignore locking, etc.

In fact, when you program for Node it's really important to keep this in mind, since (contrary to another statement from the article) not all libraries are asynchronous. If you select a synchronous db driver or write a long-running loop, it will block the rest of your program.

In general, though, I thought it was a good piece. I'm sure many heads have exploded on first introduction to node (and JS in general).

View on HN

You're confusing concurrency and parallelism. Concurrency describes having several tasks or operations that contend on resources or events. They may or may not execute in parallel, and certainly don't in Node. In contrast, Netty provides a thread pool for executing events and thus provides concurrency and parallelism.

I certainly don't like to go around spouting nonsense, so I spent some time looking for formal definitions of concurrency. I wasn't able to find any support for the description you provided, though. Do you have a source?

FWIW, Wikipedia seems to believe that "concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other".

Regardless, sorry if sloppy (or poorly defined) terminology obscured my point.

If you quote the Wikipedia definition with a bit more context you'll see it matches mine:

"In computer science, concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors."

As far as I know, by definition (coming from someone with a predominately Java background) concurrency requires multi-core processors, or, for example, a distributed application with at least 2 nodes that communicate with the same central server / "hub" (which would still require a multi-core processor, as far as I know, on the server). The central tenet mentioned with concurrency is often that of "race conditions" where it cannot be predicted which thread or node will access a resource first. If a task isn't executed in parallel, such as it has to wait for the other to finish before it starts / proceeds, I don't see how it could cause a race condition. Admittedly though, I don't have deep knowledge of how high level code translates to actual CPU instructions so it could be possible, or even likely, that if the processor is switching between tasks in such a way that each line of code, so to speak, that is run is from a different method that concurrency issues would occur even on a single-core processor. A language like Java has robust and mature aspects of the language to deal with this so I would be wary of using something like node.Js if this wasn't well documented. Concurrency issues are nasty and I have seen firsthand the mayhem they can cause in legacy applications I've worked on.

Concurrency doesn't require multi-core. Parallelism requires multi-core.

Node.js is concurrent - you can have multiple paths of execution at the same time. It's just that Node.js concurrency has non-preemptive context switch at well defined points - function boundary, thus no need for lock, whereas preemptive concurrency can context switch at any point and thus needs lock.

_That_ I did not know. Thanks!

There are multiple paths of execution your code but they are never running concurrently. Only the underlying I/O is really executing concurrently with your code.

Multiple paths of execution is concurrency. I guess what you intended to mean was parallelism, which is different from concurrency.

A multi-threaded program running on a single core system has only one path executed at any given time, but we still call it a concurrent program.

Concurrency is a superset and includes parallelism. What we both really mean is that it uses at most one core at a time to execute your code.

http://en.wikipedia.org/wiki/Concurrency_(computer_science)

Node is concurrent. libuv spawns threads and uses unix and windows APIs to read files, and pass messages back to the main JS thread when tey're done. So while your JavaScript code only runs in one thread, threads are used under the hood, making it concurrent.

> If you select a synchronous db driver

There is no such thing for node, unless you use a compiled addon. Node has no blocking networking facilities.

And even compiled add-ons use the thread pool to be async.

Reply on news.ycombinator.com