This situation is called a race condition. If that happens and some other code changed the counter during the interruption, your shared counter will probably not behave as you intended. This means that even code like sharedCounter++ can lead to unexpected behavior in programs using concurrency, as it's possible that the execution is interrupted after the current value is read but before the new value is written. In Java, for example, concurrency is achieved using threads which could be interrupted (preempted) at any moment. In a lot of languages, things are quite different. Basically, that means that the execution of a piece of code will never be interrupted unless the code itself asks for it. Non-preemptive (run-to-completion) Īnother important thing about JavaScript concurrency is that it is non-preemptive. Note that, although the JavaScript code runs in a single thread, the engine might use several threads for performing asynchronous operations like retrieving data from a server. The part of the engine responsible for determining what code to run when is the Event Loop, which in essence constantly checks if there is something ready to be executed and also determines what to execute first in case there are multiple candidates. But while the engine was waiting for the data, other pieces of JavaScript that are triggered by other events can already be run. When the engine has retrieved the data, it can then execute the program starting from the function it received. The task in question could be something like retrieving data from a URL. When making asynchronous calls, JavaScript code tells the JavaScript engine something like "ok, I'm done for now, but please perform this task for me and pass the resulting data to this function I'm giving you". JavaScript is able to accomplish this using a combination of asynchronous calls and the Event Loop.Example: while a part of the JavaScript code is getting some data from the backend to update the page with, another part of the code might be creating some visual effects whenever the user hovers over a button.This does not prevent JavaScript from making it seem like multiple things are going on at the same time!.This means that, at any point in time, at most one code path is executing.Hopefully this clarifies the way around the non-deterministic behaviour of setTimeout and setImmediate when both are called from within the main module.A high-level overview of how JavaScript handles concurrency using its Event Loop JavaScript and concurrency Single-threaded Ī JavaScript program typically executes inside a single thread (let's ignore some less common cases where code spawns child processes, Web Workers, Worker Threads or similar) If it’s is less than 1ms Event-loop continues to next phase and runs the setImmediate callback in check phase of the loop and setTimeout in the next tick of the loop. If the preparation before the first loop took more than 1ms then the Timer Phase calls the callback associated with it. Also as the hr_time return time in Nanoseconds, this behaviour as shown by the timeout_vs_immediate.js becomes more explanatory now. One more important things to note is setTimeout when set to 0 is internally converted to 1. The callback in the Timer phase is run if the current time of loop is greater than the timeout. If we see the code closely before the loop goes to timer phase, it calls uv_update_time(loop) to initialize the loop time. Yes there is more than just the phases in the event loop.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |