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?

Solution 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.

Solution 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.

Solution 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.

Comments

[Michael Dillon]

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

[alienhard]

@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.

[Michael Dillon]

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.

[everybody]

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++) {}"

[stu]

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

[maletor]

Try this: 9007199254740992 + 1

[weaknespase]

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

[JHH]

"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".

[beNerd]

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

[JHH]

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.