I am a bit confused as to why a synchronous call is different to an asynchronous call, as there is never an "immediate" response, it still takes some nano or milliseconds?
views:
171answers:
1
+8
A:
A synchronous call returns to its caller after finishing its job (or reaching timeout). An asynchronous call returns immediately after starting some other activity.
This means that, for a synchronous call, the caller waits - is completely blocked - while the called activity happens; an asynchronous call returns almost immediately to the caller although all that's happened is that the activity was started. As a result, after an asynchronous call, the called activity runs in parallel to the calling activity.
There's often some mechanism for the asynchronously started activity to "report back" that it's finished, or the calling activity may poll or otherwise look for evidence of completion of the asynchronous task.
Carl Smotricz
2010-03-17 09:18:55
Is this the only difference then?
Zubair
2010-03-17 09:20:24
I've added a bit more detail. "The only difference" sounds like you're not fully capturing the impact - synchronous and asynchronous calls are hugely different.
Carl Smotricz
2010-03-17 09:22:49
But can't any synchronous call be emulated by an asynchonous call by simple providing a callback to continue to the next statement. I'm wondering if the synchonous call is just syntactic sugar aorund an asynchronous call?
Zubair
2010-03-17 09:29:57
No, it is in fact not easy to simulate a synchronous call with an asynchronous one. How would you get your calling activity to stop dead in its tracks (without busy-looping!) while the called activity runs?
Carl Smotricz
2010-03-17 09:33:39
Synchronous calls are actually by far the simpler of the two: Essentially every call to a method/function/subroutine/whatever-it's-called is a synchronous call. An asynchronous call means starting up a new thread of execution, i.e. increasing the number of activities your program is performing at the same time. The earliest "operating systems" such as MS-DOS weren't even able to do this, and starting up background tasks required considerable trickery.
Carl Smotricz
2010-03-17 09:37:27
Can you explain this some more please, as I have often seen synchronous calls which end up spawning new threads and processes. For example, if I put a message on a message queue, I often get a return code which has been generated by a totally new thread.
Zubair
2010-03-17 10:02:05
Also, aren't closures used to store the state of calling activities?
Zubair
2010-03-17 10:03:35
The case you mention is an exception rather than the rule: Normally, queues are a classic and common mechanism for decoupling callee from caller, i.e. making a called activity asynchronous. Some message queueing systems give you an option of waiting for the result of processing, which may take place on a different machine.
Carl Smotricz
2010-03-17 10:14:52
Some of the more modern languages, especially functional languages, will let you capture some of the state of a process in a "real" first-class object that you can pass around like any other; that would be a closure. In more classic languages, the caller's state exists just as a set of values on a stack, and is not directly accessible to the program until the callee returns.
Carl Smotricz
2010-03-17 10:18:19
Thanks for your answers @carl. It has given me alot to think about! I may be back to ask some more soon :)
Zubair
2010-03-17 10:48:31