node.js - How does NodeJS handle multi-core concurrency? -

currently working on database updated java application, need nodejs application provide restful api website use. maximize performance of nodejs application, clustered , running in multi-core processor.

however, understanding, clustered nodejs application has own event loop on each cpu core, if so, mean, cluster architect, nodejs have face traditional concurrency issues in other multi-threading architect, example, writing same object not writing protected? or worse, since multi-process running @ same time, not threads within process blocked another...

i have been searching internet, seems nobody cares @ all. can explain cluster architect of nodejs? much

add on:
clarify, using express, not running multiple instances on different ports, listening on same port, has 1 process on each cpus competing handle requests...

the typical problem wondering is: request update object base on given object b(not finish), request update object again given object c (finish before first request)...then result base on object b rather c, because first request finishes after second one.
not problem in real single-threaded application, because second 1 executed after first request...

the core of question is:

nodejs have face traditional concurrency issues in other multi-threading architect, example, writing same object not writing protected?

the answer that scenario not possible because node.js processes don't share memory. objecta, objectb , objectc in process different objecta, objectb , objectc in process b. , since each process single-threaded contention cannot happen. main reason find there no semaphore or mutex modules shipped node.js. also, there no threading modules shipped node.js

this explains why "nobody cares". because assume can't happen.

the problem node.js clusters 1 of caching. because objecta in process , objecta in process b different objects, have different data. traditional solution of course not store dynamic state in application store them in database instead (or memcache). it's possible implement own cache/data synchronization scheme in code if want. that's how database clusters work after all.

of course node, being program written in c, can extended in c , there modules on npm implement threads, mutex , shared memory. if deliberately choose go against node.js/javascript design philosophy responsibility ensure nothing goes wrong.

---

additional answer:

a request update object base on given object b(not finish), request update object again given object c (finish before first request)...then result base on object b rather c, because first request finishes after second one. not problem in real single-threaded application, because second 1 executed after first request...

first of all, let me clear misconception you're having. not problem real single-threaded application. here's single-threaded application in pseudocode:

function main () {     timeout = forever     readfd = []     writefd = []      databasesock1 = socket(database_ip,database_port)     send(databasesock1,update_object_b)      databasesock2 = socket(database_ip,database_port)     send(databasesock2,update_opject_c)      push(readfd,databasesock1)     push(readfd,databasesock2)      while(1) {         event = select(readfd,writefd,timeout)         if (event) {             (i=0; i<length(readfd); i++) {                 if (readable(readfd[i]) {                     data = read(readfd[i])                      if (data == object_b_updated) {                         update(objecta,objectb)                     }                     if (data == object_c_updated) {                         update(objecta,objectc)                     }                 }             }         }     } } 

as can see, there's no threads in program above, asynchronous i/o using select system call. program above can translated directly single-threaded c or java etc. (indeed, similar @ core of javascript event loop).

however, if response update_object_c arrives before response update_object_b final state objecta updated based on value of objectb instead of objectc.

no asynchronous single-threaded program immune in language , node.js no exception.

note don't end in corrupted state (though end in unexpected state). multithreaded programs worse off because without locks/semaphores/mutexes call update(objecta,objectb) can interrupted call update(objecta,objectc) , objecta corrupted. don't have worry in single-threaded apps , won't have worry in node.js.

if need strict temporally sequential updates still need either wait first update finish, flag first update invalid or generate error second update. typically web apps (like stackoverflow) error returned (for example if try submit comment while else have updated comments).