[concurrency-interest] is choice beteen asynchrone/synchrone method an implementation detail?

Peter Veentjer alarmnummer at gmail.com
Tue Jul 25 05:52:45 EDT 2006

I have a question about synchrone and asynchrone methods being an
implementation detail.

If you have an interface:

interface WaterCooker{
   void cook();

You could create different implementations. It is easy to make it a
synchronous call (the default approach) but it is also quite easy to
make it asynchrone (if the call has no return value). So it is
possible to let the implementation determine what kind of call you
get: synchrone or asynchrone.

Personally I'm not too happy with this 'transparancy'. I think it is
better that this behaviour is part of your interface definition. Why?
-of you don't know if  a call is asynchrone, some condition don't have
to success when you go to the next statement. In case of the

WaterCooker cooker = new WaterCooker();
Cup cup = new Cup();

if you don't know the cook call is asynchrone, it could be you get
cold water in your cup.

-you don't know if you need to worry about concurrency control issues.
If some data is shared between the two threads, you system could be
subject to data corruption and other nasty stuff. This is something
you have to be aware of, and this means that it is part of the
definition of your interface (and not an implementation detail).

And there are other issues (bigger chance of deadlocks for example).

The reason why I'm asking this:
with modern frameworks like Spring it is very easy to 'enhance'
objects. You could wrap a synchronous call within a asynchronous
wrapper and inject the wrapper in every components that requires it.
The component itself is not aware that the call is asynchronone. So it
is very easy to make the choice between synchronous and asynchronous
evaluation just an implementation/configuration detail.

What are your thought about  the synchronous/asynchronous behaviour of
methods totally transparent?

More information about the Concurrency-interest mailing list