CODEWITHSUNDEEP
node.jsconcurrency
Raekye
Raekye

Reputation: 5131

Does nodejs carry the "single thread" (no multithreaded locking code) benefit when run on multiple cores?

As I understand, one of the benefits of NodeJS is that it's one thread per process; in the standard case, you don't need to worry about concurrency.

I also read about NodeJS scaling on multi core machines (Node.js on multi-core machines):

Workers will compete to accept new connections, and the least loaded process is most likely to win. It works pretty well and can scale up throughput quite well on a multi-core box.

In this case, will multiple threads execute in parallel? If so, doesn't that mean we do have to write multithreaded code (if we want to use multiple cores) - and if so, how do I do that?

Or if they don't execute in parallel... where is the boost/benefit of multiple cores coming from?

Edit: My current understanding

So there may be multiple processes on multiple cores but each process only has a single thread.

For example:

var io = require('socket.io').listen(81);

var connections = [];

io.sockets.on('connect', function (socket) {
    console.log('connected...');
    connections.push(socket);

    socket.on('disconnect', function () {
        console.log('disconnected');
        connections.remove(socket);
    });
});

There aren't race connections; there's a single thread, there won't be concurrent accesses of connections. When you have different processes, each process has its own copy of connections. So if you had a massive chatroom you couldn't balance the load with multiple processes; each process would be its own chatroom.

In this aspect, it's not any different from PHP, in that each PHP script has its own copy of the variables so you don't write locking code. Of course, the rest of it is completely different, but as far as I can see the argument "you don't have to write thread-locking code" isn't much of a plus because most data will be saved elsewhere anyways (not as in-memory variables).

Upvotes: 0

Views: 1775

Answers (3)

Evan P
Evan P

Reputation: 1817

As the nature of javascript is, running code can only be executed in a single Thread. That means in every internal resource of the running Node each resource is accessible by only one running function, parallelism can't happen. An example:

var car = {
    velocity: 100,
};

function speedUpTo150() {
    car.velocity = 150;
}

function slowDownTo80() {
    car.velocity = 80;
}

speedUpTo150();
slowDownTo80();
setTimeout(function() {
    speedUpTo150();
},1000);

setTimeout(function() {
    slowDownTo80();
},1000);

By this example it should be clear that race condition can not happen as on any time access to car can only have one function.

Yet nodejs as you mentioned can have a multicore execution mode. This can happen either by clustering (forking) the Javascript code into various nodeJS processes, or by spawing child Processes. Again in each individual processes (either cluster or child processes) race condition can not happen in their internal resources. Neither can happen as they exchange resources, as at any time at both sides only one piece of code is executed and apply the exchange.

But you also mentioned external resources, such as MongoDB. NodeJS can not be agnostic of what MongoDB is serving at any time rather than its own calls. So in that case race condition (I am not completely sure how mongoDB serves this case, it's just a hypothesis) can happen as at any time MongoDB can serve any process, either that second process is a fork instance of NodeJS or any other. In such cases you should implement a locking mechanism.

You Should note that same case is also applied to the Actor pattern where each actor is an individual thread and have a really similar way to handle race condition to its thread internal resources. But when it comes to external resources by Actor's nature it is not possible to be aware of external resource's state.

Just food for thought, why don't you check for an immutable mechanism?

Cheers!

Upvotes: 2

Alan
Alan

Reputation: 46813

The answer to:

Does nodejs carry the “single thread” (no multithreaded locking code) benefit when run on multiple cores?

Is yes, node still prevents locking code, as each process is still single threaded.

There are no multi-threads in node (javascript is designed to be a single thread). Scaling to multi-cores involves multiple processes, each with a single thread.

So, you have multiple process that execute in parallel, but since they're separate processes, with their own process space, you don't have the same issues with locks as you would with a multi-threaded process. Communicating between processes uses IPC via handles. Since all IO is non-blocking in Node, while child processes are waiting for I/O other processes can continue to execute, and receive data.

Upvotes: 2

Tomas Kirda
Tomas Kirda

Reputation: 8413

JavaScript always runs in a single thread. There is no such thing as multithreaded code in JavaScript. It is not good for heavy computing, but it's good for IO based operations, because it's event based, e.g. when IO access is in progress the thread is free to handle other requests/operation. That's why it can handle well many "simultaneous" connections.

Upvotes: 0

Related Questions