I am willing to implement some server side code using node.js.
Does node.js (js) have any synchronization inbuilt.Like we have
synchronized key word in java?
Can i make some code block synchornized?so that at one time only on thread can execute it?
In Node, every code block is synchronized. Node uses cooperative multitasking; the only time another piece of code can run is when the first piece of code returns.
That's the driving force behind its event-driven design: you ask for something slow to be done for you (e.g. reading from a file), and then you specify another function to be run when that slow operation is done. The first function returns, and Node can run other functions while it's waiting for the I/O operation to be done. When the I/O is ready, and all other functions are done running, then your continuation will be called.
Synchronization isn't needed when you're in full control of when your code will yield. In effect, every function is synchronized.
Node does not use threads. It is based on an event machine...
So I think your question is a little off.. Maybe if you give a problem that you are trying to solve people here can guide you.
Yes You can do it with fibers, more details here http://alexeypetrushin.github.com/synchronize
Related
In python and js, there is often a problem associated with blocking the event loop, when the code is executed in one thread and only one synchronous operation can be performed at the same time, but I could not find this problem anywhere in C#, maybe this problem does not exist in C#, if not, then why? And what is the difference between asynchrony in C# and javascript
c# actually has multiple threads, so whenever asynchronous coding is used it should either run on a background thread, or use asynchronous IO provided by the OS, so no thread is actually used at all for the operation.
c# UI programs still have a UI thread with an event loop, and it is perfectly possible to deadlock if you use poor programming practices. As an example:
Task task = SomeAsynchronousOperation();
task.Wait(); // can deadlock if run on the UI thread
The reason is that SomeAsynchronousOperation might need to run something on the UI thread to complete, and this is obviously not possible if it is waiting a task.
But it is also fairly easy to solve in c#
Task task = SomeAsynchronousOperation();
await task; // No deadlock
By the magic of the compiler rewriting your method into a state machine the risk of deadlock is removed.
What is the point of doing setTimeout(fx, 0) in node?
This is not asynchronous or even non-blocking, as the async function is really the setTimeout, not your fx, and after setTimeout has run asynchronously, you will end up running fx which will block your code anyway.
Doing the setTimeout with 0 to call a function fx will just wait until the stack is empty to run fx, but then while fx is running you won't be able to accept any requests, right?
So is setTimeout(fx, 0) just a way of telling node 'hey, run this whenever you can'? Is there any way to trully run async functions in Node?
If your question is:
Can node run functions in parallel at the same time?
Then the answer is yes, but you have to use a web worker.
The paradigm of asynchronosity in node is different from traditional definitions. The expectation is that you don't run too many ultra-long running functions in node. This way, effective asynchronosity is achieved.
Node is good for some things, not for others, just like any environment.
For a more detailed answer, refer here
As for setTimeout(...,0) calls; sometimes giving a break during a time consuming task to allow calls in the queue have their share of processing can be required. Dividing tasks in different ways can save you from these; but still, this is not really a hack, it is just the way event queues work. Also, using process.nextTick for this aim is much better since when you use setTimeout, calculation and checks of the time passed will be necessary while process.nextTick is simply what we really want: "Hey task, go back to end of the queue, you have used your share!"
If I understand your question correctly the answer would be the following:
As JavaScript is a single threaded language it is still able to deal with two things separately.
Using setTimeout(fx, 0) allows you to push the function or operation within the setTimeout Function in a "waiting qeue". As soon as the Stack of operations is completed the function gets put onto the execution stack and gets executed.
More detailed information about that can be found in this video
This question is regarding the sinlge threaded model of JavaScript. I understand that javascript is non-block in nature cause of its ability to add a callbacks to the async event queue. But if the callback function does infact take a long time to complete, won't JavaScript then be blocking everything else during that time as it is single threaded? How does nodejs handle such a problem? And is this an unavoidable problem for developers on the front end? I'm asking this question cause I have read that its generally good practice to keep function tasks as small as possible. Is it really because long tasks in javascript will actually block other tasks?
But if the callback function does infact take a long time to complete, won't JavaScript then be blocking everything else during that time as it is single threaded?
Yes.
How does nodejs handle such a problem?
Node.js handles nothing. How you handle concurrency is up to you and your application. Now, Node.js does have a few tools available to you. The first thing you have to understand is that Node.js is basically V8 (JavaScript engine) with a lightweight library split between JavaScript and native code bolted on. While your JavaScript code is single-threaded by nature, the native code can and does create threads to handle your work.
For example, when you ask Node.js to load a file from disk, your request is passed off to native code where a thread pool is used, and your data is loaded from disk. Once your request is made, your JavaScript code continues on. This is the meaning of "non-blocking" in the context of Node.js. Once that file on disk is loaded, the native code passes it off to the Node.js JavaScript library, which then executes your callback with the appropriate parameters. Your code continued to run while the background work was going on, but when your callback is dealing with that data, other JavaScript code is indeed blocked from running.
This architecture allows you to get much of the benefit of multithreaded code without having to actually write any multithreaded code, keeping your application straightforward.
I'm asking this question cause I have read that its generally good practice to keep function tasks as small as possible. Is it really because long tasks in javascript will actually block other tasks?
My philosophy is always to use what you need. It's true that if a request comes in to your application and you have a lot of JavaScript processing of data that is blocking, other requests will not be processed during this time. Remember though that if you are doing this sort of work, you are likely CPU bound anyway and doing double the work will cause both requests to take longer.
In practice, the majority of web applications are IO bound. They shuffle data from a database, reformat it, and send it out over the network. The part where they handle data is actually not all that time consuming when compared to the amount of time the application is simply waiting to hear back from the upstream data source. It is in these applications where Node.js really shines.
Finally, remember that you can always spawn child processes to better distribute the load. If your application is that rare application where you do 99% of your work load in CPU-bound JavaScript and you have a box with many CPUs and/or cores, split the load across several processes.
Your question is a very large one, so I am just going to focus on one part.
if the callback function does infact take a long time to complete, won't JavaScript then be blocking everything else during that time as it is single threaded? (...) Is it really because long tasks in javascript will actually block other tasks?
Non-blocking is a beautiful thing XD
The best practices include:
Braking every function down into its minimum functional form.
Keep CallBacks asynchronies, THIS is an excellent post on the use of CallBacks
Avoid stacking operations, (Like nested Loops)
Use setTimeout() to brake up potentially blocking code
And many other things, Node.JS is the gold standard of none blocking so its worth a look.
--
--
setTimeout() is one of the most important functions in no-blocking code
So lets say you make a clock function that looks like this:
function setTime() {
var date=new Date();
time = date.getTime()
document.getElementById('id').innerHTML = time;
}
while(true){setTime();}
Its quite problematic, because this code will happily loop its self until the end of time. No other function will ever be called. You want to brake up the operation so other things can run.
function startTime() {
var date=new Date();
time = date.getTime()
document.getElementById('id').innerHTML = time;
setTimeout(startTime(),1000);
}
'setTimeout();' brakes up the loop and executes it every 1-ish seconds. An infinite loop is a bit of an extreme example. The point is 'setTimeout();' is great at braking up large operation chains into smaller ones, making everything more manageable.
Javascript is single threaded. So does the callback function and it's containing function execute on the same thread as the main loop/event loop?
database.query("SELECT * FROM hugetable", function(rows) { // anonymous callback function
var result = rows;
console.log(result.length);
});
console.log("I am going without waiting...");
If query() method and its callback function executes on the same thread as the event loop does then the blocking will occur. If not why Javascript is called single-threaded?
Can anyone help verify that javascript(browser/node.js) is using multiple threads behind the scene in order to achieve non-blocking?
Friends,
I saw your comments and answers. Sorry I am very new to Javascript. I am confused in that single thread async call won't block. If there are 100 users request data from hugeTable which may take one minute each concurrently and the event loop dispatch these tasks in to a queue and execute them in turn how can the query() method execution not blocking the event loop since they are all on one single thread?
Brad answered this part.
Node.js native libraries (not the JavaScript portions) use separate threads all the time, but all of the data for your code gets shuffled back to a single JavaScript execution thread.
It's impossible to tell you if other threads in the background are working on this query, since you didn't specify what DB library you're using. However, that doesn't matter as much as you think.
Let's suppose you were to create a thread for handling your database connection. You fire off a query, and that thread takes care of getting the query to the database server. Then what? That thread sits around doing absolutely nothing until there's data to come back. You've effectively wasted resources keeping a thread around that doesn't do a whole lot. Node.js doesn't work this way. You have one thread for JavaScript execution.
If you are sending or receiving data (which is mostly what your DB connector is going to do), then this is handled out of a background thread pool for you automatically. It's also possible whatever DB connector you're using has a native extension that can do whatever it wants with threads.
See my post here for a more full explanation: https://stackoverflow.com/a/19324665/362536
Javascript is single threaded. So does the callback function and it's containing function execute on the same thread as the main loop/event loop?
Yes, you kind of answered your own question.
You are correct, JavaScript is single threaded. There is no other thread for a callback to execute on.
That said, external libraries written in C or C++ are free to spawn threads all they want.
Good question, javaScript is single-threaded yet asynchronous, that means for each asynchronous call it will perform a small pause on the main thread to execute the callback, at least that's for browsers and even there you will have web-workers that will spawn a new thread per worker.
What you're doing in your code is deferring the evaluation of the query (execution of the callback) until after the query has run and rows have been retrieved.
In modern browsers you can create two threads if desired using webworkers.
Node.js is a seperate story - you can create child processes which will run on a seperate thread when desired. See this post for further information.
or something else to queue up the rest of my function? and use callbacks or does node handle that automatically?
I imagine that I would need to start my code and if there are other things that need to occur I should be giving up my functions control to give other events control. Is this the case? Or can i be stingy and node will cut off my function when I have used enough time?
Thanks.
If your long-running function does a lot of I/O just make sure that you do this in a non-blocking way. This is how node.js achieves concurrency even though it only has a single thread: As soon as any task needs to wait for something, another task gets the CPU.
If your long-running function needs uninterrupted CPU time (or the I/O cannot be made asynchronously) , then you probably need to fork out a separate process, because otherwise every one else will have to wait until you are done.
Or can i be stingy and node will cut off my function when I have used enough time?
No. This is totally cooperative multi-tasking. Node cannot preempt you.
You should put your long running function or the code which takes long to execute into separate process because it can, for example, block other incoming requests while this code/function is executing. From node.js website:
But what about multiple-processor concurrency? Aren't threads
necessary to scale programs to multi-core computers? You can start new
processes via child_process.fork() these other processes will be
scheduled in parallel.
I would suggest to watch these articles/presentations in order to get a bigger picture on this topic:
Understanding the node.js event loop
Understanding event loops and writing great code for Node.js
YUI Theater — Tom Hughes-Croucher: “How to Stop Writing Spaghetti Code” (45 min.)