Jump to content
Sign in to follow this  
Guest sky.sanders

Synchronous vs Asynchronous - which is better?

Recommended Posts

Guest sky.sanders

The City Index JsonClient exposes both synchronous (Request) and asynchronous query methods (BeginRequest,EndRequest) and while I would hesitate to assign a higher ‘value’ to one over the other, there are definitely use cases that are more suited to one over the other.

Synchronous (blocking)

In general, a synchronous blocking method is better suited for headless (console or server app) applications that do not present a UI. Blocking your UI while making synchronous network calls is bad form.

This is not to say that there is not a valid use for synchronous methods in a consumer app with a UI. Consider a workflow that requires multiple requests with sequential dependency.

Accomplishing this using async methods is entirely possible but the plumbing required to do so can quickly get out of hand.

Perhaps a better solution would be to use consecutive sync calls but do so on a background thread, essentially rendering multiple consecutive sync calls as a single async call.

For some platforms such as JavaScript and Silverlight (insert more) the choice is made for you. Synchronous calls are simply not on the menu, whether you are on (or even have) the UI thread or not. JsonClient, on most platforms except JavaScript, provides a qualified work-around for this limitation by wrapping the asynchronous methods in a single blocking call. You will still want to refrain from calling such a method on the main thread if the app presents a UI.

Asynchronous (non-blocking)

JsonClient implements a standard asynchronous patter that utilizes async callbacks and async results. The workflow is as follows:

  1. Begin a request by calling BeginRequest and provide a callback that accepts a class of type ApiAyncResult that will be executed when the request completes (or errors out)
  2. In the callback, pass the ApiAsyncResult input parameter to EndRequest to receive the response.

Share this post


Link to post
Guest mrdavidlaing

In practise, I find myself only caring about async when writing UI code.

In all other cases (server side code, batch scripts, unit tests), I’m thinking synchronously (ie, I have to wait until I get the data before executing the next statement anyway); so I prefer to use the sync calls because they are conceptually simpler.

From a maintenance perspective, when a new person is reading the code, the sync calls are much easier to follow & understand.

After consideration (I’m doing a U-turn on an earlier opinion) I think there is a strong argument for only exposing sync calls; but including some examples showing how to fire these off on a background thread for UI work.

Share this post


Link to post

It has already been stated that none is necessarily better, rather depending on the particular use case, i.e. headless vs. UI scenarios, which are both prevalent in web programming environments. Consequently I’d hesitate to favor one over the other for the API as well, expose both query methods and stress use cases by sample within the documentation instead (i.e. UI bound client oriented samples via asynchronous requests and headless server oriented samples via synchronous requests).

Here are some arguments for retaining asynchronous requests as first class citizens:

  • Asynchronous patterns have well known and justified use cases and should be available for developers who are inclined and capable to master them.
  • As mentioned already, JavaScript and Silverlight only support asynchronous requests by default, and while this change from Silverlight 1.0 has been very controversial, it is currently a fact of life developers are used to deal with (though some workarounds do exist: see Making Silverlight Emulate Synchronous Requests for a short summary in favor of the asynchronous pattern and one workaround still, and Silverlight: Prefer synchronous web service calls for the converse argument including a more elaborate workaround).
  • The .NET Framework 4 features the Task Parallel Library (TPL) with the stated goal thattasks are the preferred API for writing multi-threaded, asynchronous, and parallel code; I currently share the enthusiasm about the simplification of multithreaded scenarios and resulting productivity gains offered by this library (but have yet to use it within a larger real world project, admittedly). Specifically, the TPL exposes dedicated wrappers for the asynchronous programming model (APM), amongst others, so it should be easy to use CIAPI.CS asynchronous requests with the TPL immediately in case (see TPL and Traditional .NET Asynchronous Programming for details) – I think it would be a pity being unable to use this functionality.
  • Since Sky selected to only use asynchronous request internally anyway, there appear to be no significant cost attached to surface this functionality (in fact it would be kinda funny to use async internally, emulate sync and only support sync externally thereafter … – not an argument of course ;)

Share this post


Link to post

It’s impossible to answer without some context. For example:

Given that the Java API will be used heavily on an Android or GAE platform, and those platforms limit a person’s ability to handle multiple threads, I will focus on the development of a Synchronous version first. On both of those platforms, you are unable to create new threads. This means that all of my API calls must block.

Share this post


Link to post
Guest sky.sanders

In practise, I find myself only caring about async when writing UI code.

In all other cases (server side code, batch scripts, unit tests), I’m thinking synchronously (ie, I have to wait until I get the data before executing the next statement anyway); so I prefer to use the sync calls because they are conceptually simpler.

From a maintenance perspective, when a new person is reading the code, the sync calls are much easier to follow & understand.

After consideration (I’m doing a U-turn on an earlier opinion) I think there is a strong argument for only exposing sync calls; but including some examples showing how to fire these off on a background thread for UI work.

IIRC – the reversed opinion was regarding the value of implementing and exposing sync as well as async, not that we should expose ONLY sync methods. no?

Share this post


Link to post
Guest mrdavidlaing

It’s impossible to answer without some context. For example:

Given that the Java API will be used heavily on an Android or GAE platform, and those platforms limit a person’s ability to handle multiple threads, I will focus on the development of a Synchronous version first. On both of those platforms, you are unable to create new threads. This means that all of my API calls must block.

I don’t think we’re going to be able to support a platform that doesn’t allow threading. Specifically, the streaming portion of the client libraries is based on a Lightstreamer client library, and that is threaded.

Android does have threading support – http://developer.android.com/reference/java/lang/Thread.html – and there is a demo of the Lightstreamer client running on Android –http://www.lightstreamer.com/demos.htm#AndroidDemo

If GAE doesn’t allow threading, then we’re going to have to depreciate it as a supported platform.

Share this post


Link to post

It’s impossible to answer without some context. For example:

Given that the Java API will be used heavily on an Android or GAE platform, and those platforms limit a person’s ability to handle multiple threads, I will focus on the development of a Synchronous version first. On both of those platforms, you are unable to create new threads. This means that all of my API calls must block.

@mrdavidlaing Ah yes, my mistake. I accidentally lumped android in with GAE. I don’t think we will be able to support GAE then. It doesn’t allow for spawning threads.

Share this post


Link to post

It’s impossible to answer without some context. For example:

Given that the Java API will be used heavily on an Android or GAE platform, and those platforms limit a person’s ability to handle multiple threads, I will focus on the development of a Synchronous version first. On both of those platforms, you are unable to create new threads. This means that all of my API calls must block.

GAE has task-queues which can be distributed to one or multiple servers as a secure alternative to spawning threads. http://code.google.com/appengine/docs/python/taskqueue/ And GAE datastore ( GQL based ) has the Twig Object Datastore for asynchronous non-blocking queries.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
×