Models of concurrency in nodejs

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.

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.

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.