4
u/AffectionateWork8 May 02 '20
I think they are mixing up "asynchronous" and "parallel."
You can wrap normal code in a setTimeout or Promise and it will become asynchronous. It still won't run at the same time, though.
You need separate threads to run async code at the same time
In Javascript, you could do this with Web Workers
In the browser, stuff like network IO is handled by a thread pool under the hood. That stuff truly runs at the same time.
But if you make 3 requests, and then each fetch takes a callback that maps over some data, those callbacks will not execute at the same time despite being "asynchronous." They will be popped off the message queue and processed synchronously, one by one.
I think this article gives a better understanding of what "asynchronous" means within the context of JS:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop
1
u/golovatuy May 02 '20
Think on the task as server request which takes some time, this picture don’t mean the small milliseconds tasks
2
u/AffectionateWork8 May 02 '20
I agree with you that network/file IO would use a thread pool. But any other long-running asynchronous task would not, unless you manually configured it to be.
75
u/ramsncardsfan7 May 01 '20 edited May 01 '20
This is only one specific perspective that could be misleading. You can have the same graph using only asynchronous calls. On the left you could have synchronous asynchronous (one promise after another) and on the right you could have asynchronous asynchronous (Promise.all).
What I’m trying to say is that just because your calls are asynchronous doesn’t mean they are happening at the same time. You have to do that purposefully.
4
u/MrEscobarr May 01 '20
Thats why I was so confused about the async/await. Like the name is async but you wait for it to finish so it didnt make sense to me
3
u/NoStranger6 May 02 '20
Well you wait for it to complete the rest of your function. Meanwhile, the browser is free to execute whatever it has queued.
0
May 01 '20
[deleted]
2
u/u1g0ku May 02 '20
I came here to write this point.
I learned this after I started to use threads in java6
u/cannabis_detox_ May 01 '20
its not multithreaded
0
May 02 '20
[deleted]
-14
May 02 '20
You don't control it though. The operating system does. So it definitely may not be and a lot of people don't trust web workers. https://youtu.be/cN_DpYBzKso
So please stop saying it runs in parallel. It's not.
13
u/HeinousTugboat May 02 '20
You, uh, just gonna skip over the first example they gave? Node can definitely spawn threads you control.
So.. yeah. Sometimes it's multihtreaded.
1
May 03 '20
No you don't control them. You control how they use buffers to bind to the os pthreads but you don't control how they start, how they communicate, their memory, how many, pretty much anything besides the binding.
1
u/HeinousTugboat May 03 '20
You just bored and decide to reply again?
0
May 03 '20
No just really tired of tutorials and many many devs thinking JavaScript is multithreaded or parallel. This needs to stop. JavaScript never was and can't be more then single threaded. Stop saying it is. At most with the browser/pthreads you get is the ability to lob logic on another thread whenever you use up too much memory..... That's it. That's all it is and that's all it should be called. Otherwise you get all these people saying it's something it's completely not and never will be.
2
u/HeinousTugboat May 03 '20
So, pthreads aren't multithreaded? Node doesn't use V8 for threading, it uses libuv which has its own threading API that Node interfaces with. I, admittedly, have no idea what you're referring to when you say that "at most you get the ability to lob logic whenever you use up too much memory".
If pthreads aren't multithreaded, then what do you mean when you say multithreading in a language? I can write a short node program that will run on four cores on my processor. Full stop. That, to most people I imagine, is multithreading. So what's missing from that definition to you?
Anyway, all of this is also ignoring the fact that you can
forkyour heart out in node. Does this mean it's still not multithreaded? Because at that point is there any language that's multithreaded on a POSIX system?→ More replies (0)-6
May 02 '20 edited May 02 '20
No you don't control it. The operating system does. It's single threaded. The only way it can be multithreaded is if the os runs out of resources for those threads. Nothing more and nothing less. Again nothing to do with parallelism. Which infers different hardware (i.e. different cpu not different thread.
Much like if you open the program twice, it's still not concurrent or parallel.
The v8 engine doesn't allow multithreaded processes. It can spawn child processes that start on a different cpu.... But that's like saying php is. There's 0 state shared and 0 communication. It's just lobbing a process on a different thread for a whole another instance just like php. You don't control anything. https://nodeaddons.com/automating-a-c-program-from-a-node-js-web-app/
Can you use c++ to do multithreaded processes ... Sure about as much as you can with c to php. Again no one does it, it's not safe, and any language nowadays can talk to another one but it's always advised against for obvious reasons.
So no it's not multithreaded, it's not controllable, it's not parallel, it's not communicating, it's not sharing memory, and all you are doing is waiting for the os to run out of resources or starting a completely new instance that has nothing to do with the original.
The link you shared (nodejs docs) also advised against using web workers. Why? Because they are whole new instances of the program. That do what? Run out of memory quickly... Why would spawning child processes of a whole new instance be bad? Because it does nothing to help your program. Its a new instance. Nothing more and nothing less. Might as well have another program running. If you call that control... Then sure why not.
3
u/HeinousTugboat May 02 '20
advised against using web workers. Why?
..... because node supports regular workers that run in separate threads with shared memory..
-1
May 02 '20
Nodejs web workers again you don't control. You create pthreads differently on each operating system. Why? Because you don't control them. The operating system does. Why shouldn't you use them? because again you don't control them. They do whatever the os tells them to do. A thread is how the cpu deals with processes. But when it needs more memory, it lobs it to another thread. So you don't control the starting of it, you don't control the memory of it, you don't control what the is does with it. Again not something part of ecma
3
2
u/lungfisk May 02 '20
Do worker threads (as opposed to child processes) not share memory? And don't they run on the same process (have the same PID...)? That was my understanding.
Unlike child_process or cluster, worker_threads can share memory. They do so by transferring ArrayBuffer instances or sharing SharedArrayBuffer instances.
-1
May 02 '20
A web worker is part of the browser not JavaScript. They are the browser program running outside of JavaScript. JavaScript just can access this process of the browser. Again you can't control it and as far as processes, you can't have them communicate with each other. It's apart of whenever your code runs, not a process in JavaScript that channels data between processes. It's a browser feature and not even across most browsers and they even say not to even use it.
Stop calling JavaScript multithreaded or parallel cause it's not!
3
u/lungfisk May 02 '20
To clarify, I'm talking about Node.js's worker_threads module, not web workers in the browser.
My understanding is that you have the ability to control multiple threads within the same process using worker_threads, and share memory between these threads. Is this inaccurate?
38
u/NoStranger6 May 01 '20
Except that’s not necessarly true for javascript.
JavaScript is not multi-threaded. So if your task 1 a for loop that last 20 seconds, tasks 2-3-4 are not ran concurently.
So really what happens is that each function calls are queued one after another and the execution of the response of async functions are only added when the promise is completed or the callback is called.
Which allows the program to keep executing other functions while it “waits” for the async function.
And this is why I love NodeJs for a server. It is very easy to write async code in JavaScript.
3
1
u/JayTh3King May 02 '20
Except you're not exactly correct either. Nodejs is a multithreaded language/runtime. 1 for the event loop and N threads for the execution of your code. Under the hood libuv manages a thread pool of executing code fetched from a queue
22
u/mhgl May 01 '20
Unfortunately, all the saved time was wasted on how long it took me to figure out asynchronous programming.
6
u/croc_socks May 01 '20
Somewhere in this diagram I am hearing whispers of, "Concurrency is not parallelism, but it enables parallelism". It's a subtlety that's being missed. https://medium.com/@k.wahome/concurrency-is-not-parallelism-a5451d1cde8d https://www.youtube.com/watch?v=cN_DpYBzKso
1
u/liaguris May 01 '20
Since javascript is single threaded and since I only know js , do I really need to know these things? Yes if I want to learn other non single threaded languages or am I really missing something in javascript?
edit : by the way I thought that concurrency is the same as parallelism , but after I saw your comment I am beginning to doubt that I know the strict definition of them .
1
u/croc_socks May 02 '20
It's one of those things you won't know you need it until you do. Eventually you're going to wander away from the shallow end of javascript. Without a good mental model of what's going on it's very easy to introduce subtle bugs, you'll get frustrated because this dumb code isn't doing what you expected it to do.
To me concurrency is the ability to complete any given tasks and perhaps switch between them. Parallelism is the ability to do all the tasks at the same time.
1
u/liaguris May 02 '20
By the way , a little bit off topic question , but does js on its own scale , from your experience ?
1
u/croc_socks May 02 '20
For front end work you don't have any choice. For servers we have a number of services in different languages. The node farm is able to hold its own. But most of the heavier stuff is handled by java & php.
1
u/liaguris May 02 '20
I have no clue with backend. Are you saying that java and php are used together?
I think in front end with MVC if you are careful how you do it then js can scale in front end although I think I need more experience to validate this statement .
1
u/wickedsight May 02 '20
No, what they're saying is that Java and PHP are examples of languages that are used for heavy lifting in the backend. There are way more than that, like Go, Ruby, etc. It's not impossible that in large enterprise applications, there are parts written in different languages though. That happens through legacy and all kinds of corporate politics.
Node.js is a great option for backend, but it has its limits and it's important to understand those. If you need real-time processing of large amounts of data, than Node is probably not the best option, for example.
Finally, in the frontend you don't have a choice of anything but javascript, if you're talking web applications. For apps, you once again get to choose between many languages, but through frameworks like Electron and React Native, JS is finding its way into apps on mobile and desktop.
1
u/croc_socks May 02 '20
We have different backend servers. Most were originally written in php. Newer services are written in Java and node. I am not sure what you mean by scaling the front end with MVC. I can’t tell if you mean the classic scaling definition of being able to handle very large traffic or being able to build complex web application. The answer to both is yes. The former is a hardware solution, throw or spin up more server as you need them behind load balancers. The latter you use good libraries or framework.
13
u/NobodyIsUsingThis May 01 '20
Thank you for this simple but very clear representation of asynchronous programming. Sadly some resources explain asynchronicity unclearly (in particular eloquent javascript), and this image is a confirmation that I understood the concept right
11
May 01 '20 edited May 01 '20
The graph above would be more suited to explain the difference between sequential and parallel execution. The tasks on the left portion could be asynchronous as well, albeit executed in a sequential manner (i.e. one after the other). The baseline benefit of asynchronous tasks is that you can leave them and carry on with something else while they complete. A common analogy is asking a question to somebody on the phone or on a messaging app. While on the phone you cannot do anything else while you wait for the response and you need to be actively listening, this is synchronous. On a messaging app instead, you can ask the question, forget about it, go make yourself a coffee and then, when you get notified that you received a response, decide what to do next, this is asynchronous.In a javascript application, executing tasks asynchronously (usually network I/O) means you can continue executing other logic (e.g. reacting to user clicks or showing a loader) while these tasks complete. Executing these tasks in sequence or in parallel, as the graph above illustrates, is a matter of performance optimisation and use case.
EDIT:
It is worth pointing out that the word "concurrent" is more correct than the word "parallel"
5
u/AnonymousThugLife May 01 '20
Tip: This representation is called "Gantt chart".
4
2
u/badbrownie May 02 '20
Is that right? I have only heard Gantt Charts in relation to project plans and dependency tracking. Is it a more general term to describe any horizontal based chart showing start and stop times?
2
u/AnonymousThugLife May 02 '20
Ah yes. You're right but Gantt chart is quite general term. I've seen it being used in Operating System texts also (specifically for Process start and end time, scheduling).
1
u/NoStranger6 May 01 '20
Not quite though, the graph on the left would be right if your program is multi-thread or does nothing else than pure async functions i.e. Api calls or database requests.
2
2
u/0xdead0x May 02 '20
This is true in ideal circumstances, but it’s not why you should use asynchronous functions in JavaScript. You could get results like that. You could also be on a real machine running multiple tasks that doesn’t actually have enough hardware threads to run all of your asynchronous calls in true concurrency. In JavaScript, asynchronous functions are more important as a matter of user experience. If you synchronously wait for a REST API then your app can’t respond to user input at all until it gets a response or times out. But if you do it asynchronously, then even if your machine doesn’t have a spare hardware thread, your VM’s scheduler will make sure that you’re constantly checking for a response and checking for user input such that it looks like both are happening at once.
2
1
May 01 '20
Can u do that with single core plox ?
1
May 02 '20
Sort of, but not entirely. You can wait for multiple things at once, but not do multiple thing at once. If you had 3 web requests that each take 1 second, with little to no processing involved, you can be done in 1 second with asynchronous code by waiting for the 3 1-seconds at the same time. If you have some calculation that takes 1 second to finish, then it take 3 seconds to do them all, no matter how you write your code.
1
u/liaguris May 01 '20
Wait a second here . I am confused . How is the right chart possible in a single threaded language like javascript?
2
May 02 '20
If the overlapping bits are spent waiting for something, like hard drive, network, timeout, etc.
1
u/liaguris May 02 '20 edited May 02 '20
Ok I get it now.
For the network case maybe we have non-single thread-like behavior in the server who is processing the requests .
I think it is the same about hard drive also , where the computer can have multiple cpu cores.
I can imagine something like this for
setTimeoutout :while (true) { //microtasks //.... //macrotasks for (let { timeout, cb, timeoutId } in obj) { if (--timeout === 0) { cb(); delete obj[timeoutId]; } } //animationFrame? //... }which is single thread behavior.
What is the y axis supposed to represent?That chart is really misleading.
The whole story about asynchronicity in javascript is doing stuff in a single thread after the whole synchronous code has executed . The asynchronous chunk are done one after the other and they never overlap their cpu usage (= single thread).
Correct if I am wrong but I think an exception might be workers where we can have multi-threaded (parallel?) behavior if the computer has many cpu cores.
1
u/IzeroI May 02 '20 edited May 02 '20
The figure is generally misleading even though its idea is close. You need multiple cpus and a multithreaded process to achive what you are suggesting. What async does depends on the browser implementation. And, asynchronous does not mean parallel. It means it is not continuous like regular code. Like "first line of code can be paused and move to second line etc, return and finish first line later etc". Not syncrhonous.
1
1
u/t0pz May 02 '20
Layman here, i feel like this is misleading? From what i understand from this graph is that 4 tasks are executed at the same time, instead of one after another, which to me means more processing power & memory used in the right scenario. But i don't think that's necessarily the case. Can someone attempt an ELI5 on the real difference and benefit of async vs sync?
1
u/saito200 May 02 '20
Javascript tasks can run concurrently, but Javascript events are serialized, not parallelized. Only one event at a time.
I think this image can be misleading.
1
1
u/thuva04 May 02 '20
This is only true for ideal scenarios, where all 4 tasks are independent and not CPU heavy. Still, Javascript(Node JS) is a single thread ecosystem, So everything will happen in a sequential order where i/o or network related tasks are handled by OS thread.
This is not true for multi-thread languages. Software parallelism is depended on the hardware resources. You can't create more threads than the hardware limit. If you create more thread will start to work sequentially.
Also, Only hardware resources won't achieve the expected speedup. Amdahl's Law[1] used in parallel computing, it can predict the actual benefit of increasing the number of processors, which is limited by the parallelizability of the program.
1
u/Mises2Peaces May 02 '20
*assuming no hardware bottlenecks running more calculations at the same time.
1
0
u/eggn00dles May 01 '20
yeah but async/await > nested callbacks/thens
1
u/NoStranger6 May 01 '20
Async/await is just sugarcoated callbacks/ promises.
Simply on a speed PoV callbacks are more performant.
Async/await is easier to read.
0
0
May 01 '20
[deleted]
2
u/NoStranger6 May 01 '20
Nope, JavaScript is mono threaded. NodeJs has ways to to use multi-threads but they are mostly base on launching multiple processes.
2
u/0xdead0x May 02 '20
Sort of yes, but this depends on the VM your code is running on. If it’s in Node, then you will in some ways have 1,000 threads but they will be implemented as separate processes that your operating system’s scheduler has to make run concurrently or pseudoconcurrently. Your speed always depends on your hardware. If your processor does not have 1,000 hardware threads to spare (it doesn’t), then each thread gets scheduled in to run for a certain amount of time on an available hardware thread and your scheduler is constantly switching out which thread gets to run so that they appear to be running concurrently, when in reality they are not. Increasing the amount of hardware threads you have will definitely give you better net performance for highly concurrent tasks.
1
May 01 '20
Javascript is strictly single threaded and uses a model called event loop to achieve concurrency.
9
u/zbluebirdz May 01 '20
If you had each task dependent on the previous task's results/outcome, can you still run it in Asynchronous mode?