What is the difference between Asynchronous calls and Callbacks

I'm bit confused to understand the difference between Asynchronous calls and Callbacks.

I read this posts which teach about CallBacks but none of the answers addresses how it differs from Asynchronous calls.

Is this Callbacks = Lambda Expressions?

Callbacks are running in a different thread?

Can anyone explains this with plain simple English?

Very simply, a callback needn't be asynchronous.

http://docs.apigee.com/api-baas/asynchronous-vs-synchronous-calls

1. Synchronous:

   If an API call is synchronous, it means that code execution will block (or wait) for the API call to return before continuing. This means that until a response is returned by the API, your application will not execute any further, which could be perceived by the user as latency or performance lag in your app. Making an API call synchronously can be beneficial, however, if there if code in your app that will only execute properly once the API response is received.

2. Asynchronous:

   Asynchronous calls do not block (or wait) for the API call to return from the server. Execution continues on in your program, and when the call returns from the server, a "callback" function is executed.

In Java, C and C#, "callbacks" are usually synchronous (with respect to a "main event loop").

In Javascript, on the other hand, callbacks are usually asynchronous - you pass a function that will be invoked ... but other events will continue to be processed until the callback is invoked.

If you don't care what Javascript events occur in which order - great. Otherwise, one very powerful mechanism for managing asynchronous behavior in Javascript is to use "promises":

http://www.html5rocks.com/en/tutorials/es6/promises/

PS: To answer your additional questions:

1. Yes, a callback may be a lambda - but it's not a requirement.

   In Javascript, just about every callback will be an "anonymous function" (basically a "lambda expression").

2. Yes, callbacks may be invoked from a different thread - but it's certainly not a requirement.

3. Callbacks may also (and often do) spawn a thread (thus making themselves "asynchronous").

'Hope that helps

====================================================================

Hi, Again:

Q: @paulsm4 can you please elaborate with an example how the callback and asynchronous call works in the execution flow? That will be greatly helpful

1. First we need to agree on a definition for "callback". Here's a good one:

   https://en.wikipedia.org/wiki/Callback_%28computer_programming%29

   In computer programming, a callback is a piece of executable code that is passed as an argument to other code, which is expected to call back (execute) the argument at some convenient time. The invocation may be immediate as in a synchronous callback, or it might happen at a later time as in an asynchronous callback.

2. We must also define "synchronous" and "asynchronous". Basically - if a callback does all it's work before returning to the caller, it's "synchronous". If it can return to the caller immediately after it's invoked - and the caller and the callback can work in parallel - then it's "asynchronous".

3. The problem with synchronous callbacks is they can appear to "hang". The problem with asynchronous callbacks is you can lose control of "ordering" - you can't necessarily guarantee that "A" will occur before "B".

4. Common examples of callbacks include:

   a) a button press handler (each different "button" will have a different "response"). These are usually invoked "asynchronousy" (by the GUI's main event loop).

   b) a sort "compare" function (so a common "sort()" function can handle different data types). These are usually invoked "synchronously" (called directly by your program).

5. A CONCRETE EXAMPLE:

   a) I have a "C" language program with a "print()" function.

   b) "print()" is designed to use one of three callbacks: "PrintHP()", "PrintCanon()" and "PrintPDF()".

   c) "PrintPDF()" calls a library to render my data in PDF. It's synchronous - the program doesn't return back from "print()" until the .pdf rendering is complete. It usually goes pretty quickly, so there's no problem.

   d) I've coded "PrintHP()" and "PrintCanon()" to spawn threads to do the I/O to the physical printer. "Print()" exits as soon as the thread is created; the actual "printing" goes on in parallel with program execution. These two callbacks are "asynchronous".

Q: Make sense? Does that help?

They are quite similar but this is just mho.

When you use callbacks you specify which method should you should be called back on and you rely on the methods you call to call you back. You could specify your call back to end up anywhere and you are not guaranteed to be called back.

In Asynchronous programming, the call stack should unwind to the starting position, just as in normal synchronous programming.

Caveat: I am specifically thinking of the C# await functionality as there are other async techniques.