Models of concurrency in nodejs

Question

Does anyone know what the memory and threading models are in nodejs?

In particular, is ii++ atomic? Does it behave as if ii were volatile in Java 1.5, in Java 1.4, in C, or not at all?

Bonar

For all you care node.js is single threaded. – Dose

@Raynos: Not exactly. Javascript runs on a single thread, but blocking IO is done on a separate thread pool. "Of course, on the backend, there are threads and processes for DB access and process execution." Citation: blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop – Antimasque

Correction: for all you care node.js is single threaded. – Immesh

Answer 1

It is useful to understand how node and V8 interact. Node handles waiting for I/O or timers from the operating system. When node wakes up from I/O or a timer, it generally has some JavaScript callbacks to invoke. When node runs these callbacks, control is passed into V8 until V8 returns back to node.

So, if you do var ii = 1; ii++;, you will never find that ii is anything other than 2. All JavaScript runs until completion, and then control is passed back to node. If you do doSomething(); doSomething(); that will always run doSomething twice, and it will not return to node's event loop until the second invocation of doSomething returns. This means you can completely lock up node from a simple error like this:

for (var i=0 ; i >= 0 ; i++) {}

It doesn't mater how many I/O callbacks you have registered, timers set to go off, or sockets waiting to be read. Until V8 returns from that infinite loop, node does no more work.

This is part of what makes programming in node so nice. You never have to worry about locking. There are no race conditions or critical sections. There is only one thread where your JavaScript code runs.

Salicin

I had a stupid moment and for a second didn't realize why that was an infinite loop. For anybody slow like me, remember that the second condition in the for loop is the condition for continuation, not termination. I.e. the standard for loop that terminates is "for (var i = 0; i < 0; i++) {}" – Footing

is it really infinite? won't i wrap around at some point and become negative? – Simone

Try this: 9007199254740992 + 1 – Hipolitohipp

@stu, all numbers in JavaScript are double precision floating point type. They can't do this by definition. – Glebe

"You never have to worry about locking. There are no race conditions or critical sections." I hear this a lot about Node. Just because it's single threaded doesn't mean you can't have the above problems. The classic "bank account example" where two requests do balance += 10 could just as easily fail in a single-threaded asynchronous environment if the two requests happen to result in database operations being called in the order "read, read, write, write". – Normannormand

but then it's not locking of threads (like in java). It more relates to a DB atomicity stuff. No? @Normannormand – Taipan

Yes, of course. It's not about thread synchronization per se, but still concepts like atomicity, critical sections, mutex etc are relevant. However, I quite often hear people saying there are no concurrency aspects to worry about because of the single threaded model. The only system void of concurrency issues is a single threaded system where requests are handled strictly sequentially, and that obviously wouldn't suit a web server. – Normannormand

Answer 2

There's only one thread (the event loop) and your code is never interrupted unless you perform an asynchronous action like I/O. You can't do any parallel code execution. Therefore ii++ is atomic.

Larrabee

Would have been nice if you addressed the grey area. For instance, what about this: dosomething(); doanotherthing(); ??? – Kayekayla

@Michael There's no gray area. doanotherthing() is always executed after dosomething() without the possibility to switch control in between (with the exception that dosomething() raises an exception). See also the answer of @Matt, which explains this in more detail. – Larrabee

The grey area is that two function calls are sequential unless they do I/O and that is not always clear when you use 3rd party code. – Kayekayla

Answer 3

A good article that explains what is, and is not, asynchronous in node.js is Understanding the node.js Event Loop. If you can understand that you will be able to identify where your application has async behavior and where it doesn't. By understanding this you can explicitly write sequential code when you need it. EventEmitters are key.

Singlethreadedness sounds at odds with the idea that node.js is high performance and scalable so have a look at this article from Yahoo on Multicore.

Kayekayla