4 Answers
4

No. It means literally what it means-- asynchronous. Understanding the difference between asynchronous programming and thread-based programming is critical to your success as a programmer.

In a traditional, non-threaded environment, when a function must wait on an external event (such as a network event, a keyboard or mouse event, or even a clock event), the program must wait until that event happens.

In a multi-threaded environment, many individual threads of programming are running at the same time. (Depending upon the number of CPUs and the support of the operating system, this may be literally true, or it may be an illusion created by sophisticated scheduling algorithms). For this reason, multi-threaded environments are difficult and involve issues of threads locking each other's memory to prevent them from overrunning one another.

In an asychronous environment, a single process thread runs all the time, but it may, for event-driven reasons (and that is the key), switch from one function to another. When an event happens, and when the currently running process hits a point at which it must wait for another event, the javascript core then scans its list of events and delivers the next one, in a (formally) indeterminate (but probably deterministic) order, to the event manager.

For this reason, event-driven, asynchronous programming avoids many of the pitfalls of traditional, multi-threaded programming, such as memory contention issues. There may still be race conditions, as the order in which events are handled is not up to you, but they're rare and easier to manage. On the other hand, because the event handler does not deliver events until the currently running function hits an idle spot, some functions can starve the rest of the programming. This happens in Node.js, for example, when people foolishly do lots of heavy math in the server-- that's best shoved into a little server that node then "waits" to deliver the answer. Node.js is a great little switchboard for events, but anything that takes longer than 100 milliseconds should be handled in a client/server way.

In the browser environment, DOM events are treated as automatic event points (they have to be, modifying the DOM delivers a lot of events), but even there badly-written Javascript can starve the core, which is why both Firefox and Chrome have these "This script is has stopped responding" interrupt handlers.

What about ajax calls in jQuery , the server side code do its stuff while my browser keeps do other functions.....?
–
Royi NamirJan 22 '12 at 20:00

3

Those aren't threads, though. You've sent a message in your browser-side code to the server. When the call returns is an event, and your code is expected to pick it up and do something with it. While it's waiting, the eventloop goes to handle other events. When your event returns, the eventloop gives your callback complete control over the single process thread until you give it up by reaching the end of the callback, doing something that causes the eventloop to progress, or creating a new event.
–
Elf SternbergJan 22 '12 at 22:46

1

a great answer, thanks for explaining that in a reasonably jargon-free manner
–
JasonJan 23 '12 at 7:37

Why "anything that takes longer than 100 milliseconds should be handled in a client/server way"? Ajax calls take more than 100 ms sometimes, and my browser doesn't give me the "This script is has stopped responding" message.
–
trusktrFeb 11 '14 at 21:01

Trusktr: Because node is single-threaded, you shouldn't use the process you're using to handle requests, to also do heavy programmatic lifting; you shouldn't use the same process to do natural language processing, or image processing; you should do that in child processes. Each process will take time; every other process will be blocked until its done. If you do it in child processes, you free your "switchboard" process to handle I/O.
–
Elf SternbergFeb 11 '14 at 23:45

A single threaded event loop is a good example of being asynchronous in a single threaded language.

The concept here is that you attach doLater callback handlers to the eventLoop. Then the eventLoop is just a while(true) that checks whether the specific timestamp for each doLater handler is met, and if so it calls the handler.

If there is a callback, something has to call it. The units of execution are threads & so, yes, some other thread has to call the callback, either directly or by queueing up some asynchronous procedure call to the initiating thread.

It's perfectly possible for the same single thread to call the callback later.
–
RaynosJan 22 '12 at 18:07

@Raynos how? If one thread directly calls a function, it's just called a 'call'. If the callback is signaled into the thread on some input loop, something must have queued the callback. A driver could do this directly, but it's usually a kernel thread.
–
Martin JamesJan 22 '12 at 18:26

By having the entire event loop live in the single thread. Note that the thread can't do any IO then, it can only do asynchronous communication with itself and anything within the single thread. This might be pedantry.
–
RaynosJan 22 '12 at 18:30

It's not pedantry, Raynos. You're right. It's a single thread of execution, the program pointer is a singleton. Learning to visualize the event queue and the functions hanging off of it-- and learning to respect that, in event-driven programming the function does not return to where it left off-- was the single biggest key to my understanding node.js.
–
Elf SternbergJan 22 '12 at 18:55

I think we're all arguing the same point from different ends. From the OS side, there has to be something loading the events onto the queue. In that respect, 'Does Async programming means - multi Threading ? ( in some way ) ?' the answer has to be yes. From the js side, things look different.
–
Martin JamesJan 22 '12 at 19:00