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

David Holmes dcholmes at optusnet.com.au
Tue Jul 25 06:09:39 EDT 2006


Peter,

I'm opposed to this kind of transparency - I don't think it can be done. The
programming model is either synchronous or asynchronous you can't
arbitrarily switch between them unless you always assume asynchronous. But
then whenever you have an asynchronous call you ultimately need some kind of
synchronous method to "rendezvous" with the object again.

So my answer is: don't do this. It isn't an implementation detail it is part
of the specification of the API - after this method returns what do I know
about what should have happend to the object.

Now there are languages that allow things to happen asynchronously but they
also synchronize again when needed ie "wait by necessity".

Cheers,
David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> Veentjer
> Sent: Tuesday, 25 July 2006 7:53 PM
> To: concurrency-interest at cs.oswego.edu
> Subject: [concurrency-interest] is choice beteen asynchrone/synchrone
> methodan implementation detail?
>
>
> 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:
>
> WaterCooker cooker = new WaterCooker();
> Cup cup = new Cup();
> cooker.cook();
> cooker.fill(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?
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list